4 comments:
Patch Set #4, Line 24: known
Some of those are only known by way of Kconfig check. I also think allowing leaking all over because the API is not clear of the semantics allows for abuse. The omission of stranded cbfs_map() calls w/o a cbfs_unmap() pairing will likely be copy/pasted which leads to truly leaking resources.
Patch Set #4, Line 27: often
"can't". Without knowing which rdev the mapping is connected to then things fall over. Remember you have an ro as well as rw cbfs_boot_device objects.
Patch Set #4, Line 96: cares about which chained subregion something was mapped from. */
I don't think this is always true in practice. I think more commentary covering the diligence of this assumption is warranted.
e.g. src/drivers/spi/boot_device_rw_nommap.c provides rdev ops which do not allow any mmap()ing, but boot_device_ro() using src/arch/x86/mmap_boot.c does allow it. I believe that's the only combination that is potentially problematic, but the assumption above still holds.
File src/security/vboot/ec_sync.c:
Why wouldn't we unamp here?
To view, visit change 39304. To unsubscribe, or for help writing mail filters, visit settings.