On Wed, Aug 14, 2019 at 4:09 PM Peter Jones <pjones@xxxxxxxxxx> wrote: > On Wed, Aug 14, 2019 at 03:00:32PM -0400, Paul Moore wrote: > > 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. Your phrasing sent a different message. > That said, fundamentally the design of TXT enforces measurement ... Oddly enough, it really doesn't. TXT, and the SINIT ACM, at its basic level is really just about creating a clean environment where you have some guarantee (once again, assuming you trust Intel) that everything that happened before can not affect what you do next. It's the tboot implementation that enforces policy. > ... but adds a step in the middle of the boot chain that's not verifiable as part of Secure Boot. Not verifiable as part of the UEFI Secure Boot as currently implemented, yes. However, I don't believe that is an inherent limitation, with some work I believe tboot could be made to co-exist with UEFI Secure Boot, but I will admit that is beyond the scope of my initial effort. > 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. >From a practical perspective, the SINIT ACM and various bits of system firmware are all binary blobs that I really have no way of verifying. With UEFI Secure Boot I have to trust Microsoft, with TXT I have to trust Intel. -- paul moore www.paul-moore.com _______________________________________________ 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
