Understanding Configuration of SME on Linux

I was playing around today with SEV and SME on my Epyc 7713 in a ROMED8-2T, and I found a confusing situation with enabling SME that I think might be a (minor) bug in the Linux kernel (or at least the 6.1.0-21-amd64 kernel from Debian 6.1.90-1).

I have set the following firmware settings, with the goal of enabling SME, SEV (with SEV-ES, but not SEV-SNP, since it’s not supported by my kernel anyway), and maybe TSME:

CPU Configuration
└── SVM Mode
    └── Enabled
AMD CBS
├── CPU Common Options
│   ├── SEV ASID Count
│   │   └── 509 ASIDs (specifying the default for Space Limit value below)
│   ├── SEV-ES ASID Space Limit Control
│   │   └── Manual
│   ├── SEV-ES ASID Space Limit
│   │   └── 509
│   ├── SNP Memory (RMP Table) Coverage
│   │   └── Auto (i.e. Disabled)
│   └── SMEE
│       └── Enabled
├── UMC Common Options
│   └── DDR4 Common Options
│       └── Security
│           └── TSME
│               └── Enabled
└── NBIO Common Options
    └── SEV-SNP Support
        └── Disabled

With this configuration, I see kernel messages implying SEV is enabled and the test kernel module from GitHub - AMDESE/mem-encryption-tests: Tests related to Memory Encryption reports that TSME is enabled.

When I add mem_encrypt=on to the kernel command line, I get these log lines:

Jun 18 22:16:25 kernel: Unknown kernel command line parameters "BOOT_IMAGE=/vmlinuz-6.1.0-21-amd64 mem_encrypt=on", will be passed to user space.
Jun 18 22:16:25 kernel: Memory Encryption Features active: AMD SME

Without mem_encrypt=on, (I have not tried mem_encrypt=off or similar) these lines are absent.

Am I wrong, or is the “Unknown kernel command line parameters” message incorrect? Without passing the mem_encrypt parameter, the “Memory Encryption Features active” messages doesn’t appear, implying to me that the kernel is not applying SME in that configuration.

As a separate question: is there any advantage or disadvantage to using SME and TSME at the same time? It seems like they would be redundant, but it also appears that they don’t interfere with each other. Given that I don’t have any special application that partially-applies SME to only critical memory areas, it seems like the transparent TSME without OS involvement would work perfectly fine.

This is a very interesting thread. So far seems none appreciates it ?

I could be wrong but I don’t think transparent sme requires any kernel flags as the encryption happens in hardware, not software.

I agree. TSME doesn’t require the kernel flag and appears more compatible with applications.