Actions
Bug #525
closedPotential clash when custom get_flash_region() called in erase_write
Start date:
02/05/2024
Due date:
% Done:
0%
Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
Affected OS:
Description
erase_write in erasure_layout.c makes a call to get_flash_region(). This call happens after erase layout is calculated, however get_flash_region() can potentially return smaller region.
Issue needs research (and fix if needed).
Originally reported by Vincent Fazio, copying the report below:
As part of looking over #1 and #2, I developed some slight concerns about the loop on line 314 which is separate from
this patchset. I don't know if it warrants an issue and further discussion, and I haven't spelunked into the erase function
selection logic, but the concern I have there is we've already pre-calculated what erase functions we're using but
`get_flash_region` could return a region with a shorter end range, meaning the selected erase block fn could erase part
of the next region. So if we had a 32k erase block fn, it seems like if region.end forces the length of the erasable region
to 4k, we don't actually select a 4k erase function and instead continue to use a 32k function. If the next region is write
protected it seems like we'd have verification errors.
I think this currently only affects masters that have get_region defined, so `opaque_master_ich_hwseq` is at risk here.
This may have been less of a risk with the legacy path because, from what I remember, it always used the smallest working
erase block function, however the new path adjusts the function used based on the amount of changed data and coalesces blocks
when possible (I think).
Actions