Latest SUSE Linux Enterprise Goes All in With Confidential Computing 7
SUSE's latest release of SUSE Linux Enterprise 15 Service Pack 5 (SLE 15 SP5) has a focus on security, claiming it as the first distro to offer full support for confidential computing to protect data. From a report: According to SUSE, the latest version of its enterprise platform is designed to deliver high-performance computing capabilities, with an inevitable mention of AI/ML workloads, plus it claims to have extended its live-patching capabilities. The release also comes just weeks after the community release openSUSE Leap 15.5 was made available, with the two sharing a common core. The Reg's resident open source guru noted that Leap 15.6 has now been confirmed as under development, which implies that a future SLE 15 SP6 should also be in the pipeline.
SUSE announced the latest version at its SUSECON event in Munich, along with a new report on cloud security issues claiming that more than 88 percent of IT teams have reported at least one cloud security incident over the the past year. This appears to be the justification for the claim that SLE 15 SP5 is the first Linux distro to support "the entire spectrum" of confidential computing, allowing customers to run fully encrypted virtual machines on their infrastructure to protect applications and their associated data. Confidential computing relies on hardware-based security mechanisms in the processor to provide this protection, so enterprises hoping to take advantage of this will need to ensure their servers have the necessary support, such as AMD's Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) and Intel's Trust Domain Extensions (TDX).
SUSE announced the latest version at its SUSECON event in Munich, along with a new report on cloud security issues claiming that more than 88 percent of IT teams have reported at least one cloud security incident over the the past year. This appears to be the justification for the claim that SLE 15 SP5 is the first Linux distro to support "the entire spectrum" of confidential computing, allowing customers to run fully encrypted virtual machines on their infrastructure to protect applications and their associated data. Confidential computing relies on hardware-based security mechanisms in the processor to provide this protection, so enterprises hoping to take advantage of this will need to ensure their servers have the necessary support, such as AMD's Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) and Intel's Trust Domain Extensions (TDX).
what it is: (Score:3)
The technology protects data in use by performing computations in a hardware-based trusted execution environment (TEE).[3] Confidential data is released to the TEE only once it is assessed to be trustworthy.
Thanks wikipedia.
Re: (Score:3)
Re: (Score:2)
in a hardware-based trusted execution environment
Unless the "owner" of the encrypted data is the sole holder of the private key used by the TPM, this is nothing but BS trust theater. There are software packages that allow this, but I'd imagine the expectation is that you'll use a Trusted Computing Group provided key.
The other issue is the fact that even with a owner owned private key setup, you're still completely dependent on the willingness of the hardware provider to keep the system secure and up-to-date enough that they can't peek or poke into your
How about allowing the TPM to unlock LUKS? (Score:3)
How about just being the first mainstream distribution to allow an easy way (not this way [opensuse.org]) to use the TPM at boot, so LUKS can encrypt the root filesystem, with a recovery password in another slot for recovery in case the TPM doesn't work? This would be easy to do with clevis/tang, but no mainstream distribution makes this easy to do at install time. At best, it will prompt for a password on the console, you could use clevis with a network key server, or you can configure the RAM image so you can SSH into it, run cryptoroot-unlock... and neither of those are really solutions for a lot of server applications.
As for Secure UEFI, that isn't as relevant, as Secure UEFI and the TPM are different mechanisms (and the TPM can use Secure UEFI values with PCRs).
Re: (Score:3)
As for Secure UEFI, that isn't as relevant
Of course it is. Why would you accept just any old firmware image from the hardware provider if your entire point of using a TPM is to intentionally hide data from them???
Answer: You wouldn't. Otherwise the hardware vendor could just as easily install a fTPM (software TPM) hook at boot time that looks OK to your remote tool stack, but in reality accepts commands from the hardware owner to unlock and dump any image it "protects." The only way that this scheme works is for both parties (the data owner and