Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1653299 > unrolled thread

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure  Memory Encryption Borislav Petkov <bp@alien8.de> - 2017-05-30 17:10 +0200
    Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure  Memory Encryption Borislav Petkov <bp@alien8.de> - 2017-05-31 10:50 +0200
      Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure  Memory Encryption Borislav Petkov <bp@alien8.de> - 2017-05-31 16:20 +0200

#1653299 — Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

On Tue, May 30, 2017 at 09:38:36AM -0500, Tom Lendacky wrote:
> In this case we're running identity mapped and the "on" constant ends up
> as kernel address (0xffffffff81...) which results in a segfault.

Would

	static const char *__on_str = "on";

	...

	if (!strncmp(buffer, __pa_nodebug(__on_str), 2))
		...

work?

__phys_addr_nodebug() seems to pay attention to phys_base and
PAGE_OFFSET and so on...

I'd like to avoid that rip-relative address finding in inline asm which
looks fragile to me.

Thanks.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [next] | [standalone]

#1654015

On Tue, May 30, 2017 at 10:37:03AM -0500, Tom Lendacky wrote:
> I can define the command line option and the "on" and "off" values as
> character buffers in the function and initialize them on a per character
> basis (using a static string causes the same issues as referencing a
> string constant), i.e.:
> 
> char cmdline_arg[] = {'m', 'e', 'm', '_', 'e', 'n', 'c', 'r', 'y', 'p', 't', '\0'};
> char cmdline_off[] = {'o', 'f', 'f', '\0'};
> char cmdline_on[] = {'o', 'n', '\0'};
> 
> It doesn't look the greatest, but it works and removes the need for the
> rip-relative addressing.

Well, I'm not thrilled about this one either. It's like being between a
rock and a hard place. :-\

On the one hand, we need the encryption mask before we do the fixups and
OTOH we need to do the fixups in order to access the strings properly.
Yuck.

Well, the only thing I can think of right now is maybe define
"mem_encrypt=" at the end of head_64.S and pass it in from asm to
sme_enable() and then do the "on"/"off" comparsion with local char
buffers. That could make it less ugly...

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [prev] | [next] | [standalone]

#1654290

On Wed, May 31, 2017 at 08:37:50AM -0500, Tom Lendacky wrote:
> I like keeping the command line option and the values together. It may
> not look the greatest but I like it more than defining the command line
> option in head_64.S and passing it in as an argument.
> 
> OTOH, I don't think the rip-relative addressing was that bad, I can
> always go back to that...

Yeah, no nice solution here. Having gone full circle, the rip-relative
thing doesn't look all that bad, all of a sudden. I'd let you decide
what to do...

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web