Regression: x86/mm: Add Secure Memory Encryption (SME) support

Regression: x86/mm: Add Secure Memory Encryption (SME) support

[Tj]

With 4.14.0rc2 on an Intel CPU with an Nvidia GPU the proprietary nvidia
driver (v340.102) fails to modpost due to:

FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
'sme_me_mask'

I think this is due to:

config ARCH_HAS_MEM_ENCRYPT
       def_bool y


I noticed that a grep of the built kernel for "sme_me_mask" shows the
symbol imported into more than 300 modules on an Ubuntu mainline build
of 4.14.0-041400rc2-lowlatency.

Should the new symbol be referenced so widely and how can it be
prevented from being included in proprietary modules on systems that
don't have SME even if the kernel is built with it enabled?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Regression: x86/mm: Add Secure Memory Encryption (SME) support

[Tom Lendacky]

On 9/30/2017 5:36 PM, Tj wrote:
> With 4.14.0rc2 on an Intel CPU with an Nvidia GPU the proprietary nvidia
> driver (v340.102) fails to modpost due to:
> 
> FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
> 'sme_me_mask'
> 
> I think this is due to:
> 
> config ARCH_HAS_MEM_ENCRYPT
>         def_bool y
> 

I think this is more likely because of CONFIG_AMD_MEM_ENCRYPT=y. If
CONFIG_AMD_MEM_ENCRYPT=n then sme_me_mask becomes a #define. I'm
assuming that changing the sme_me_mask in arch/x86/mm/mem_encrypt.c
from EXPORT_SYMBOL_GPL to EXPORT_SYMBOL fixes the issue?

Boris, is it a big deal to make this change if that's the issue?

Thanks,
Tom

> 
> I noticed that a grep of the built kernel for "sme_me_mask" shows the
> symbol imported into more than 300 modules on an Ubuntu mainline build
> of 4.14.0-041400rc2-lowlatency.
> 
> Should the new symbol be referenced so widely and how can it be
> prevented from being included in proprietary modules on systems that
> don't have SME even if the kernel is built with it enabled? >

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Regression: x86/mm: Add Secure Memory Encryption (SME) support

[Thomas Gleixner]

On Mon, 2 Oct 2017, Tom Lendacky wrote:
> On 9/30/2017 5:36 PM, Tj wrote:
> > With 4.14.0rc2 on an Intel CPU with an Nvidia GPU the proprietary nvidia
> > driver (v340.102) fails to modpost due to:
> > 
> > FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
> > 'sme_me_mask'
> > 
> > I think this is due to:
> > 
> > config ARCH_HAS_MEM_ENCRYPT
> >         def_bool y
> > 
> 
> I think this is more likely because of CONFIG_AMD_MEM_ENCRYPT=y. If
> CONFIG_AMD_MEM_ENCRYPT=n then sme_me_mask becomes a #define. I'm
> assuming that changing the sme_me_mask in arch/x86/mm/mem_encrypt.c
> from EXPORT_SYMBOL_GPL to EXPORT_SYMBOL fixes the issue?
> 
> Boris, is it a big deal to make this change if that's the issue?

It's a big deal.

And no, it's GPL and it stays that way. This discussion pops up every few
month when we add a new feature.

If people want to run the nviodit module, then they can set

   CONFIG_AMD_MEM_ENCRYPT=n

and be done with it.

The proprietaery nvidia driver is tolerated as is and it's operating in a
legal grey zone.  That tolerance does not include that the existance of
this driver can dictate our choice of licensing. Especially not if the
reason why it fails to compile or load can be disabled.

There is a choice, but the option for free lunch does not exist.

Thanks,

	tglx

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>