On 6/24/21 8:18 AM, Matt DeVillier wrote:
I don't see the problem here TBH. There's no issue, security or otherwise, with coreboot having fmap regions within the IFD BIOS region that are not contiguous. Alignment requirements (eg, 64k) for some regions practically guarantee this.
ifdtool complained here because a manually generated flashmap had a BIOS region that wasn't top-aligned with the IFD one.
On reflection, my initial comments appear a bit of a crazed rant, brought on by a lack of sleep. The flash memory content of unwritten areas of flash memory are no more or less secure than the content of those memory areas that have been specifically written. But the irony here is that "ROM" is not really "Read Only Memory" when it can be written and re-written, any more than a "BIOS" is actually a "Basic Input/Output System" when it does not actually hold Input/Output Subroutines to be called from a dependent Operating System. The colloquial use of these, and many other, misnomers promotes delusional thinking, since "ROM" is often being re-written, and the purpose of the "BIOS" is actually to reset the device hardware, and often, then also write updates to the "ROM".
Any protocol intended to validate nominally fixed areas of "ROM", then, *must* address also any undisclosed/undesignated areas of flash "ROM" expected to be in a "cleared"/"erased" state. If the coreboot FlashMap protocol fails to specifically designate these areas of flash memory, then how are they to otherwise be addressed or tracked? That appears to me to be a potential problem, since otherwise, no definite hash or CRC value can be used to "fingerprint" these memory regions, to assure that they have remained "fixed".
Regardless, it also seems reasonable and desirable that a bit more "sanity checking" should be included in, for instance, "cbfs validate -w", and especially, in the poorly documented, cryptic or silent, "ifdtool --validate", to plainly articulate specific areas of flash memory that have not otherwise been defined/designated, perhaps describing these regions as "GAP", "UN-MAPPED", or some such.
James
On Thu, Jun 24, 2021 at 7:37 AM James Feeney james@nurealm.net wrote:
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 james@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/+...
"... 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-leave@coreboot.org