On Thu, Jan 24, 2019 at 6:24 PM Julius Werner <jwer...@chromium.org> wrote:
> > What does that practically look like? Every time we have to re-walk we > have to reverify the integrity of the metadata. > > I mean, that is exactly what we're doing right now anyway (unless > something significantly changed in CBFS code since the last time I > checked). For every single CBFS file access we start at the root and > we walk the chain until we find the file we're trying to load (and all > of this are real SPI transfers, it's not cached anywhere). Hashing > times are generally insignificant compared to SPI access times IIRC > (especially since this should be a raw hash, not an RSA signature like > we use in current vboot). Validating the hash means we have to walk > the whole CBFS directory rather than stopping at the file when we find > it, but since we generally don't really pay attention for CBFS file > placement for performance right now that's presumably not a big deal > (would only double cost on average). > > And there are certainly still ways to improve this with the right > caching, and ways to do that in a safe way even if verification is > involved, which we could explore if we wanted to. I'm just saying as a > baseline that the cost of CBFS walks seems to have never bothered us > in the past, so the comparable cost of reverifying metadata probably > shouldn't be a major criterion to reject the per-file approach. > I wasn't considering just the perf costs. I was including the notion of re-checking and re-visiting the boot media repeatedly wit TOCTOU in mind. I think we're on the same page, though, with the two approaches on what both would entail. We collectively need to align on pros/cons of both and ultimately decide on an approach.
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
