On Tue, Jan 22, 2019 at 6:21 PM Julius Werner <jwer...@chromium.org> wrote:
> > FWIW, it's my opinion I think we'll need to start splitting cbfs into > smaller ones. This isn't specific to this situation, but splitting slots > into multiple cbfses (rw-a-1, rw-a-2, etc) allows one to chain/group > resources as they are used along with more flexibility for > signing/verification methods. What you wrote above seems sane, but I think > you'll run into build limitations that don't allow one to target fmap > regions for different assets. It's a lot of Make w/ some special casing > currently which is because people didn't want another tool at the time -- > however, once you need more cbfs regions of different granularity I think > having better tooling around targeting final destination for assets is > required. > > Are we abandoning the idea to verify individual files instead (once > someone has time to implement it) then? I'd still think that would be > a nicer solution to get more flexible verification. > I'm just expressing my opinion on how I think we should move forward. I'm a little concerned about multiple things when it comes to doing per-file signature/hashing: 1. Time of Check and Time of Use issues. 2. Passing metadata forward for validation. 3. Complexity For 1, this is attempting to protect physical attack. Obviously this particular problem can't be solved in isolation, but it's something to think about. When discussing 2 from a practical matter, we need to pass on the metadata information across stages to help mitigate 1 and ensure integrity of the hashes are correct. Similarly, limiting complexity is also important. If we can group the assets together that are tied to the boot flow then it's conceptually easier to limit access to regions that haven't been checked yet or shouldn't be accessed. I do think per-file metadata hashing brings a lot of complications in implementation. When in limited resource environments chunking cbfs into multiple regions lends itself well to accomplishing that while also restricting access to data/regions that aren't needed yet when thinking about limiting #1. -Aaron
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
