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


Groups > linux.kernel > #1645543 > unrolled thread

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

Started byBorislav Petkov <bp@alien8.de>
First post2017-05-19 13:40 +0200
Last post2017-05-19 22:40 +0200
Articles 3 — 2 participants

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-19 13:40 +0200
    Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure  Memory Encryption Josh Poimboeuf <jpoimboe@redhat.com> - 2017-05-19 22:20 +0200
      Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure  Memory Encryption Borislav Petkov <bp@alien8.de> - 2017-05-19 22:40 +0200

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

FromBorislav Petkov <bp@alien8.de>
Date2017-05-19 13:40 +0200
SubjectRe: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption
Message-ID<tIOqe-1ui-11@gated-at.bofh.it>
On Fri, Apr 21, 2017 at 01:56:13PM -0500, Tom Lendacky wrote:
> On 4/18/2017 4:22 PM, Tom Lendacky wrote:
> > Add support to check if SME has been enabled and if memory encryption
> > should be activated (checking of command line option based on the
> > configuration of the default state).  If memory encryption is to be
> > activated, then the encryption mask is set and the kernel is encrypted
> > "in place."
> > 
> > Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> > ---
> >  arch/x86/kernel/head_64.S |    1 +
> >  arch/x86/mm/mem_encrypt.c |   83 +++++++++++++++++++++++++++++++++++++++++++--
> >  2 files changed, 80 insertions(+), 4 deletions(-)
> > 
> 
> ...
> 
> > 
> > -unsigned long __init sme_enable(void)
> > +unsigned long __init sme_enable(struct boot_params *bp)
> >  {
> > +	const char *cmdline_ptr, *cmdline_arg, *cmdline_on, *cmdline_off;
> > +	unsigned int eax, ebx, ecx, edx;
> > +	unsigned long me_mask;
> > +	bool active_by_default;
> > +	char buffer[16];
> 
> So it turns out that when KASLR is enabled (CONFIG_RAMDOMIZE_BASE=y)
> the stack-protector support causes issues with this function because

What issues?

> it is called so early. I can get past it by adding:
> 
> CFLAGS_mem_encrypt.o := $(nostackp)
> 
> in the arch/x86/mm/Makefile, but that obviously eliminates the support
> for the whole file.  Would it be better to split out the sme_enable()
> and other boot routines into a separate file or just apply the
> $(nostackp) to the whole file?

Josh might have a better idea here... CCed.

-- 
Regards/Gruss,
    Boris.

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

[toc] | [next] | [standalone]


#1645892

FromJosh Poimboeuf <jpoimboe@redhat.com>
Date2017-05-19 22:20 +0200
Message-ID<tIWxs-7lL-17@gated-at.bofh.it>
In reply to#1645543
On Fri, May 19, 2017 at 01:30:05PM +0200, Borislav Petkov wrote:
> > it is called so early. I can get past it by adding:
> > 
> > CFLAGS_mem_encrypt.o := $(nostackp)
> > 
> > in the arch/x86/mm/Makefile, but that obviously eliminates the support
> > for the whole file.  Would it be better to split out the sme_enable()
> > and other boot routines into a separate file or just apply the
> > $(nostackp) to the whole file?
> 
> Josh might have a better idea here... CCed.

I'm the stack validation guy, not the stack protection guy :-)

But there is a way to disable compiler options on a per-function basis
with the gcc __optimize__ function attribute.  For example:

  __attribute__((__optimize__("no-stack-protector")))

-- 
Josh

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


#1645908

FromBorislav Petkov <bp@alien8.de>
Date2017-05-19 22:40 +0200
Message-ID<tIWQO-7ue-21@gated-at.bofh.it>
In reply to#1645892
On Fri, May 19, 2017 at 03:16:51PM -0500, Josh Poimboeuf wrote:
> I'm the stack validation guy, not the stack protection guy :-)

LOL. I thought you were *the* stacks guy. :-)))

But once you've validated it, you could protect it then too. :-)

-- 
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