The Intel SGX technology enables creation of execution enclaves, whose memory is encrypted and thus protected from all other code running on the CPU, including SMM, firmware, kernel and userspace. This proposal is to introduce the SGX host software stack, architectural enclaves and development packages to Fedora, to enable future introduction applications and features which have a dependency on SGX technology.
The primary feature that will leverage SGX in a subsequent Fedora release is expected to be Intel TDX, which provides confidential virtual machines, and is in the process of being integrated with QEMU and Linux/KVM.
Owners, do not implement this work until the FESCo vote has explicitly ended. The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.
REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the Discourse discussion linked above. Additional discussion may happen on the Fedora Devel mailing list.
This one appears to have gotten lost during the holiday season.
I'm trying to read through the discussion, but I'm unsure about one thing. I know we previously rejected a similar Change because it wasn't possible to test the implementation without having things signed by the hardware vendor (and replacing the vendor's keys was impossible).
Is that the case with this SGX implementation as well?
+1
FWIW, I find the analysis that concludes that the sgx software can be qualified as firmware convincing. At the technical level, it'd be very cool if we had a reliable reproducible build to match the original signature. But apart from being a technical feat, it wouldn't give as any benefit, because we could always only rebuild the exact version that was already built and signed by upstream, precluding any patches or fixes.
I think reproducible build is already described as an extension? I also find the firmware argument reasonable
Let's add this to the agenda for today. Maybe we can resolve some of the questions in interactive discussion.
Metadata Update from @zbyszek: - Issue tagged with: meeting
This one appears to have gotten lost during the holiday season. I'm trying to read through the discussion, but I'm unsure about one thing. I know we previously rejected a similar Change because it wasn't possible to test the implementation without having things signed by the hardware vendor (and replacing the vendor's keys was impossible). Is that the case with this SGX implementation as well?
That is the case with this too.
I'm trying to read through the discussion, but I'm unsure about one thing. I know we previously rejected a similar Change because it wasn't possible to test the implementation without having things signed by the hardware vendor (and replacing the vendor's keys was impossible). Is that the case with this SGX implementation as well?
You can re-build everything, and sign them with your own keys. Some of the enclaves are still usable in this case, but specifically for the 'pce' enclave, you will no longer be able to request Intel provide a certificate authenticating your hardware as genuine Intel hardware. This is because removing the Intel signature has broken the chain of trust needed for Intel to verify the hardware, as a condition for them issuing the certificate.
In a production environment this is not a use case that matters. The design goal SGX is to establish a chain of trust to the hardware platform & its vendor, independent of the OS admin or OS vendor. If you just want to trust the OS vendor and/or OS admin, then a combination of SecureBoot + TPM measurements already gives you a suitable trusted software stack. IOW, using a OS vendor key or OS admin personal key for signing the SGX architectural enclaves serves no purpose and/or defeats the point of using SGX.
This was discussed in the meeting today: AGREED: APPROVED (+5, 3, -1)
Metadata Update from @zbyszek: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Metadata Update from @zbyszek: - Issue untagged with: meeting
Log in to comment on this ticket.