AMD memory encryption on Ryzen 7 PRO 4750U

[motig]

Greetings,
I have been trying to get AMD secure memory encryption to work on my HP EliteBook 845 G7 with Ryzen 7 PRO 4750U but I have found conflicting information on how it is enabled and I (probably) cannot get it to work.

I have mostly followed the kernel documentation: https://www.kernel.org/doc/html/latest/ ... ption.html

I have tried enabling and disabling AMD secure memory encryption in BIOS to see if there is any change but I have not found any.
In either case, I have AMD_MEM_ENCRYPT=y in kernel config. According to the kernel documentation, "If the BIOS merely enables SME (sets bit 23 of the MSR_AMD64_SYSCFG), then memory encryption can be enabled by supplying mem_encrypt=on on the kernel command line." - so I passed mem_encrypt=on to the kernel via grub. However, when the system boots, I can see this parameter is not recognised by the kernel:

Code: Select all

[    0.054303] Unknown kernel command line parameters "BOOT_IMAGE=/vmlinuz-6.12.41-gr mem_encrypt=on", will be passed to user space.

When I check the memory encryption support and state, as described in the kernel documentation, I get this:

Code: Select all

$ cpuid -1 -l 0x8000001f
CPU:
   AMD Secure Encryption (0x8000001f):
      SME: secure memory encryption support    = true
      SEV: secure encrypted virtualize support = true
      VM page flush MSR support                = true
      SEV-ES: SEV encrypted state support      = true
      SEV-SNP: SEV secure nested paging        = false
      VMPL: VM permission levels               = false
      RMPQUERY instruction support             = false
      VMPL supervisor shadow stack support     = false
      Secure TSC supported                     = false
      virtual TSC_AUX supported                = false
      hardware cache coher across enc domains  = false
      SEV guest exec only from 64-bit host     = false
      restricted injection                     = false
      alternate injection                      = false
      full debug state swap for SEV-ES/SEV-SNP = false
      disallowing IBS use by host              = false
      VTE: SEV virtual transparent encryption  = true
      VMGEXIT parameter support                = false
      virtual TOM MSR support                  = false
      IBS virtual support for SEV-ES/SEV-SNP   = false
      PMC virtual support for SEV-ES/SEV-SNP   = false
      RMPREAD instruction                      = false
      guest intercept control support          = false
      segmented RMP support                    = false
      VMSA register protection support         = false
      SMT protection support                   = false
      secure AVIC support                      = false
      allowed SEV features support             = false
      SVSM communication page MSR support      = false
      VIRT_RMPUPDATE & VIRT_PSMASH MSR support = false
      write to hypervisor in-used allowed      = false
      IBPB on entry support                    = false
      encryption bit position in PTE           = 0x2f (47)
      physical address space width reduction   = 0x4 (4)
      number of VM permission levels           = 0x0 (0)
      number of SEV-enabled guests supported   = 0xe (14)
      minimum SEV guest ASID                   = 0x1 (1)

# rdmsr -f 23:23 0xc0010010
0

So looks like it is supported but not enabled. The result is the same whether I enable the feature in BIOS or not. Am I missing something?

[pingtoo]

...
I have tried enabling and disabling AMD secure memory encryption in BIOS to see if there is any change but I have not found any.
In either case, I have AMD_MEM_ENCRYPT=y in kernel config. According to the kernel documentation, "If the BIOS merely enables SME (sets bit 23 of the MSR_AMD64_SYSCFG), then memory encryption can be enabled by supplying mem_encrypt=on on the kernel command line." - so I passed mem_encrypt=on to the kernel via grub. However, when the system boots, I can see this parameter is not recognised by the kernel:

Code: Select all

[    0.054303] Unknown kernel command line parameters "BOOT_IMAGE=/vmlinuz-6.12.41-gr mem_encrypt=on", will be passed to user space.

...

This "BOOT_IMAGE=/vmlinuz-6.12.41-gr mem_encrypt=on" looks wrong to me. The double quote should NOT be surrounding the entire command line parameters. You should check your bootloader and modify accordingly so the "mem_encrypt=on" be a standalone parameter.

[Hu]

I think those quotes come from the kernel. The source that generates this message reads:

Code: Select all

pr_notice("Unknown kernel command line parameters \"%s\", will be passed to user space.\n",

Notice the literal double quotes in the string, surrounding whatever the %s inserts.

[rab0171610]

Pingtoo, I could be wrong but I think that, for example, if:

Code: Select all

cat /proc/cmdline

returns:
BOOT_IMAGE=/vmlinuz-6.12.41-gr mem_encrypt=on
Then the message that the kernel is passing the parameters on to the environment for applications to be aware of
is generally placed in double quotes like so:

Code: Select all

Unknown kernel command line parameters "BOOT_IMAGE=/vmlinuz-6.12.41-gr mem_encrypt=on", will be passed to user space. 

I assume that it being placed in quotes in dmesg is very ordinary and expected. I suspect that the implementation of memory encryption (SME) is either not functioning correctly at the motherboard level, not set up fully or correctly, or is working as expected in the OS despite the message about the parameter being passed on to user space. There are some buggy implementations of SME and related settings in some motherboards and CPU combinations. I also question whether it would be more useful as a security feature on a server to help isolate multiple VM's rather than on a laptop. It may very well be that like many so called security features, i.e. memory encryption, Secure Boot, TPM, apparmor, SElinux, that not everyone that wants them actually needs them. Memory is cleared on shutdown or reboot, so for laptops SME may not always be providing as much additional security as the user might think.
There are several forum posts online of users reporting the same issues and similar unknown kernel parameters being passed to user space. It may be that OP needs to enable Transparent SME (TSME) in the motherboard settings. I am not familiar with that particular laptop motherboard.
Also, it may be that host is actually encrypting data in memory through the page table despite the unknown kernel parameter being passed to user space. So for the OP, is there a way to verify whether memory encryption is actually working or not?

[pingtoo]

OK, thanks for information.

I usually saw kernel command line parameters consumed will not show up in that message so I assume it is because quoting cause it misinterpreted.

From kernel command line document I see that spelling of "mem_encrypt=on" is correct so it is not misspelling error.

I don't know May be something else need to enable?

[motig]

I am aware of TSME but I could not find the option in the BIOS, there is just one option that says Secure Memory Encryption. It might be that it is actually TSME and the system thus has no way of knowing whether it is enabled. Unfortunately, the user manual does not explain the BIOS options.

However, according to the kernel documentation the bit 23 of MSR 0xc0010010 should indicate whether the encryption is active and it is always 0 regardless of the BIOS setting. It might not reflect TSME though. It is difficult to measure any difference in system performance since the impact is supposed to be low. There might be some memory benchmark that would make it more visible.

My reasoning for using this is that it could enhance the security of disk encryption since the keys need to be stored in memory when the system is running. I rarely shut the system down completely.

EDIT: /proc/cmdline shows the options without quotes so it is definitely not a problem of the bootloader passing them on in a wrong way. I have more options in the bootloader and they show up in the /proc/cmdline but not in the kernel message about them being unknown since the kernel correctly handles them.

[rab0171610]

So looks like it is supported but not enabled.

Forgive me if I am missing something obvious here, but even after looking at your cpuid output, I am still not sure how you are coming to this conclusion. Are you basing this solely on the 'unknown kernel command line parameters' message or something in your cpuid output which I have failed to notice. Please enlighten me . . .

https://www.amd.com/en/developer/sev.html

Code: Select all

AMD Secure Memory Encryption (SME)

Uses a single key to encrypt system memory. The key is generated by the AMD Secure Processor at boot. SME requires enablement in the system BIOS or operating system. When enabled in the BIOS, memory encryption is transparent and can be run with any operating system.

If this is accurate and I understand this correctly, I am going to assume since it is enabled in your bios that it is transparent and works at the machine level outside of the OS or Kernel. If that is the case, it would seem that SME only needs to be enabled in the BIOS. Maybe when SME is enabled in the BIOS, the kernel parameter should not even be needed?
If I had to hazard a guess, I would say that it is likely that memory encryption (AMD SME) is working as expected and the parameter being unknown has no bearing on whether or not SME is actually functioning correctly. Unless I am missing something in your cpuid output as I mentioned initially.

However, according to the kernel documentation the bit 23 of MSR 0xc0010010 should indicate whether the encryption is active and it is always 0 regardless of the BIOS setting.

Would you please detail for the record how you are able to determine this as it can help others who may read this and have similar concerns about whether or not SME is enabled.

[motig]

The commands used to determine the state of SME along with their output were in my first post:

Code: Select all

cpuid -1 -l 0x8000001f

rdmsr -f 23:23 0xc0010010

The first one should show whether encryption is supported at all. The second one Should display bit 23 of MSR 0xc00100010 (MSR_AMD64_SYSCFG) which should indicate whether the encryption is active.
The line from dmesg just seemed strange, as the kernel should recognise the parameter if it has been compiled with the support enabled.

Regarding HP and AMD SME I have found this page: https://portal-iam-ext-pro.it.hpe.com/h ... cale=en_US
It lists both SME and TSME but TSME is not specifically mentioned in my BIOS configuration. There is only one option for SME. Also this page is about HP Enterprise servers but AMD SME should be supported on "PRO" user-end processors.

I have CONFIG_X86_MEM_ENCRYPT=y and CONFIG_AMD_MEM_ENCRYPT=y in the active kernel config.
Looking at the kernel source, I can even see this code in arch/x86/boot/compressed/misc.c:

Code: Select all

/*
 * Set the memory encryption xloadflag based on the mem_encrypt= command line
 * parameter, if provided.
 */
static void parse_mem_encrypt(struct setup_header *hdr)
{
        int on = cmdline_find_option_bool("mem_encrypt=on");
        int off = cmdline_find_option_bool("mem_encrypt=off");

        if (on > off)
                hdr->xloadflags |= XLF_MEM_ENCRYPTION;
}

So one thing is whether the encryption is working but it seems that the kernel does not even parse the command line for it (or the support is not compiled in despite having been enabled via menuconfig).

[rab0171610]

Even though I had read that information in the kernel documentation link you provided:

Code: Select all

If support for SME is present, MSR 0xc00100010 (MSR_AMD64_SYSCFG) can be used to determine if SME is enabled and/or to enable memory encryption:

0xc0010010:
        Bit[23]   0 = memory encryption features are disabled
                  1 = memory encryption features are enabled

I did not correlate that with your rdmsr output as it was lumped in with and at the bottom of your cpuid output code block.
Thank you for the clarification.

https://docs.kernel.org/arch/x86/amd-me ... ption.html

Code: Select all

 Linux relies on BIOS to set this bit if BIOS has determined that the reduction in the physical address space as a result of enabling memory encryption (see CPUID information above) will not conflict with the address space resource requirements for the system. If this bit is not set upon Linux startup then Linux itself will not set it and memory encryption will not be possible.

Let's assume your kernel has all of the right options correctly enabled to support memory encryption. If the output of rdmsr is sound and accurate, then I think at this point you are at the mercy of your motherboard. I stated previously that there are some buggy implementations of SME support with regards to some motherboards and some motherboard/CPU combinations. Also, HP tends to offer more features in the BIOS as the price increases. After having HP and Dell products for several years due to economics, I now exclusively use Thinkpads and have never looked back. I personally have seen serious flaws and experienced limitations in some motherboard and laptop BIOS menus including missing supported features and features that do not always work when enabled. This is not unheard of. I am sure if the hardware was an Enterprise Server rather than an HP laptop, the support for SME and SVE would be complete and available. At that price point, you would likely have HP support if it was not working correctly. Also consider that other people have reported the anomaly that you describe, SME is enabled in the bios and the kernel, but is still not enabled at boot or mem_encrypt=on is reported as an unknown mem_encrypt=on.

Regardless, if 0xc0010010:Bit[23] is not truly set, then there is likely nothing you can do. You could A) reach out to HP for support and/or B) Update the BIOS if it is not already. The only other suggestion I have is to check if there is an option in the BIOS that can be toggled that would make visible previously hidden menu options. This might be a memory or memory encryption/memory isolation related setting such as SVE or something totally unrelated. Excluding all of that, I think you may have to accept that the motherboard does not implement SME correctly even when enabled in the BIOS.

[motig]

I have gone through the BIOS options both with the SME enabled and disabled. Nothing else seems to have changed. I am inclined towards thinking that this is in fact TSME and the OS will have no way of knowing whether it is enabled or disabled. I will try to find and run some memory benchmarks to see if I can see any performance impact between the two states. Otherwise, it seems that there is not much else I can do.

[pingtoo]

Wouldn't it make more sense to test what the option trying to protect than performance test?

By design security always cause inconvenience at best and bad performance at worst. but you choose the trade off. but the goal is to make sure it is did what it is design.

I wonder if reading /dev/mem gave any indication of if contents were encrypted or not.

And if at OS level not possible differential memory content protection then what is the point encrypt memory? is the design trying to protect when the machine while it is in power on state and somehow got pass on to some bad actor and the bad actor not able direct access at OS level therefor need to read memory content from side way?

[motig]

I have measured ~3% performance penalty on throughput with the option enabled for memory reads and no difference for memory writes. So I suppose it is working... although I am not sure why there would be no difference for writes. This means that the option would be TSME and thus I don't need to enable anything in the OS.

[rab0171610]

I have measured ~3% performance penalty on throughput with the option enabled for memory reads and no difference for memory writes. So I suppose it is working... although I am not sure why there would be no difference for writes. This means that the option would be TSME and thus I don't need to enable anything in the OS.

I suspect that is the case, it is transparently working at the machine level by simply being enabled in the BIOS. independent of the OS.
Please post any future developments or observations if they occur as thread is likely to be relevant to some users that might experience similar concerns about SME.