On Wed, Aug 14, 2019 at 03:00:32PM -0400, Paul Moore wrote: > On Wed, Aug 14, 2019 at 2:44 PM Peter Jones <pjones@xxxxxxxxxx> wrote: > > On Wed, Aug 14, 2019 at 08:35:57AM -0400, Paul Moore wrote: > > > On Tue, Aug 13, 2019 at 2:03 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > > > On 8/12/19 8:35 AM, Josh Boyer wrote: > > > > > On Mon, Aug 12, 2019 at 11:23 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > ... > > > > > May I ask why you want the cert? > > > > > > I'm working on extensions to tboot to support kernel signatures > > > instead of hashes. Not wanting to reinvent the wheel I figured I > > > would reuse the signed PECOFF format used by UEFI Secure Boot; the > > > Fedora kernels are one of the kernels I've been using for testing. > > > > Why? Just throw tboot into the sea already. It's completely > > incompatible with the concept of a real chain of trust for booting. > > I'm not using tboot/TXT for secure boot. I'm not assuming you are. I'm assuming you're running tboot, and then using its DRTM mechanism to secure something else later. > > > FWIW, once I have something that is working properly and suitable for > > > upstreaming (it is still a prototype) I plan to work on getting it > > > merged into the tboot upstream. > > > > Is there a broader goal here? It would seem to be academically > > interesting but fundamentally untrustable, because it's using tboot. > > This assumes I'm using tboot as a secure boot mechanism, I'm not. I'm not assuming this at all. > I don't have anything written up on the approach yet, but the > abstract/teaser for the LSS-NA talk is below. > > https://lssna19.sched.com/event/RHaB/securing-tpm-secrets-with-txt-and-kernel-signatures-paul-moore-cisco I don't intend to argue with you, or to say you're an idiot. That said, fundamentally the design of TXT enforces measurement, but adds a step in the middle of the boot chain that's not verifiable as part of Secure Boot. Intel claims it is verifiable by the hardware, which may well be true and meaningful, but we're still just running a binary blob on the main CPU after the firmware has gone away. Inside the measured VM, we're running it /before/ the firmware, which is actually even worse - it compromises the firmware verification. Anything relying on TXT is "trust the SINIT ACM instead of Secure Boot", both inside and outside of the VMs. That's the model. -- Peter _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
