On Thu, Aug 11, 2022 at 07:25:58PM +0930, Brendan Trotter wrote: > Hi, > > On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > > On Wed, Aug 10, 2022 at 06:37:18PM +0930, Brendan Trotter wrote: > > > > > [1] doesn't provide any useful information. How does a kernel know > > > that the callback provided by boot loader actually measures what it's > > > supposed to measure, or even does anything at all? > > > > The kernel has no way to know this - *any* code you've run before > > performing a measurement could tamper with the kernel such that it > > believes it's fine. This is just as true in DRTM as it is in SRTM. But > > you know what the expected measurements should be, so you're able to > > either seal secrets to those PCR values or rely on remote attestation. > > In this scenario the kernel has no idea what the measurement should > be, it only knows the measurement that a potentially malicious boot > loader felt like giving the kernel previously (e.g. when the kernel > was installed). > > > > [1] doesn't provide any useful information. Senter and skinit don't > > > provide a method for kernel to detect that (e.g.) a MiTM boot loader > > > has always measured a forgery and has changed unmeasured code in a > > > different way every time you boot. > > > > Measurements are not opaque objects. If you're not able to reconstruct > > the expected measurement then you're doing it wrong. > > OK; so to detect if boot loader has always given kernel a bad/forged > measurement; the kernel repeats all of the steps involved in creating > the measurement itself exactly the same as the boot loader should have > (but might not have) so that kernel can compare a "known > good/trustworthy" measurement with the useless measurement that the > boot loader created for no sane reason whatsoever? Could you tell us where exactly boot loader creates measurements for the DRTM? Daniel