On 6/24/21 12:48 AM, James Feeney wrote: > On 6/23/21 8:59 PM, James Feeney wrote: >> On 6/23/21 6:51 PM, Matt DeVillier wrote: >>> On Wed, Jun 23, 2021 at 4:36 PM James Feeney <ja...@nurealm.net> wrote: >>>> >>>> On 6/23/21 1:40 PM, Matt DeVillier wrote: >>>>> I'm an idiot and made a stupid math error when I calculated the size >>>>> of the SI_BIOS region. 0xF7F000 - 0x1000 is 0xF7E000, not 0xF6F000. >>>>> >>>>> https://review.coreboot.org/c/coreboot/+/55815 fixes it >>>>> >>>> >>>> Ha! I was a little suspicious of the suggestive pattern, 0xF7F000 - >>>> 0x10000 = 0xF6F000 vs 0xF7F000 - 0x1000 = 0xF7E000. But, I missed the >>>> hard-coded "SI_BIOS@0x1000 0xf6f000". >>>> >>>> So, I see src/mainboard/google/octopus/default.fmd, specifically, is >>>> determining here. >>>> >>>> Still, many questions from those of us less familiar. What is the meaning >>>> of "SI"? Does "SI_BIOS" have the same usage as "BIOS"? Coreboot "BIOS" >>>> is not the same thing as original "BIOS". <rant>...</rant> >>> >>> coreboot's FMAP is a more finely grained map of the firmware image >>> than the IFD's, which is necessary for coreboot (and vboot, and other >>> utils) to locate things in the different regions. >>> >>> I'm not sure where the SI_BIOS nomenclature comes from, it's a Google >>> thing I think so one of those folks from the old days would have to >>> chime in. On older boards it did/does encapsulate all of the coreboot >>> FMAP regions which reside inside the IFD's BIOS region. >>>> >>>> Are there any "official" specifications for coreboot fmap format? >>> >>> https://doc.coreboot.org/lib/flashmap.html >>> >>>> Wish me luck. I should have a functional bootrom image now! >>> >>> well, it would have been functional before, as I've apparently been >>> using improperly sized images for quite some time :) >> >> https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/255031/11/util/cbfstool/README.fmaptool >> >> "... gaps are allowed ..." >> >> So then, your images are actually, technically, "proper", even though some >> rom space was wasted. >> >> But, this element of the specification strikes me as a waking big security >> problem waiting to happen. >> >> I don't see any substantive reason for the Flashmap Descriptor specification >> to allow gaps, and, as we have seen, allowing gaps can also lead to >> inadvertant errors being introduced into the resulting flashmap descriptor >> files. >> >> I believe, instead, that gaps should specifically be *prohibited* in the >> Flashmap Descriptor specification. >> >> I suggest that the question of allowing gaps in the flashmap descriptor >> should receive wider discussion, particularly as having - I would think >> obvious - security implications, if not simply to avoid inadvertant errors. >> >> >> James >> > > Hmm - on second thought, I suppose that there are *always* going to be > "gaps", since the rom is never "full", and the actual space taken by some > random mix of files will not be known in advance. > > Maybe the only alternative, simply for the sake of consistency and error > checking, is to require and define certain "contiguous" regions of rom, > within which gaps would not be allowed. That way, errors would be disclosed, > while gaps might be "forced" into defined regions, which could be > specifically "locked", if desired. > > Other people have thought about this? > > > James
Or, a simpler idea that could be useful - cbfstool layout could just autogenerate "GAP" regions in the output, to make these more apparent. James _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
