Nico Huber has uploaded this change for review. ( https://review.coreboot.org/c/flashrom/+/31068
Change subject: Fix erasing of unaligned regions ......................................................................
Fix erasing of unaligned regions
The erase (-E) feature is somehow a brute force method, but still, if we are given a region to erase, we should make sure to restore surrounding data if the erase block expands beyond the region.
Change-Id: I5fc35310f0b090f218cd1d660e27fb39dd05c3c5 Signed-off-by: Nico Huber nico.huber@secunet.com --- M flashrom.c 1 file changed, 66 insertions(+), 3 deletions(-)
git pull ssh://review.coreboot.org:29418/flashrom refs/changes/68/31068/1
diff --git a/flashrom.c b/flashrom.c index 7129a51..e141f2c 100644 --- a/flashrom.c +++ b/flashrom.c @@ -1732,17 +1732,80 @@ const struct walk_info *const info, const erasefn_t erasefn) { const unsigned int erase_len = info->erase_end + 1 - info->erase_start; + const bool region_unaligned = info->region_start > info->erase_start || + info->erase_end > info->region_end; + uint8_t *backup_contents = NULL, *erased_contents = NULL; + int ret = 2;
+ /* + * If the region is not erase-block aligned, merge current flash con- + * tents into a new buffer `backup_contents`. + */ + if (region_unaligned) { + backup_contents = malloc(erase_len); + erased_contents = malloc(erase_len); + if (!backup_contents || !erased_contents) { + msg_cerr("Out of memory!\n"); + ret = 1; + goto _free_ret; + } + memset(backup_contents, ERASED_VALUE(flashctx), erase_len); + memset(erased_contents, ERASED_VALUE(flashctx), erase_len); + + msg_cdbg("R"); + /* Merge data preceding the current region. */ + if (info->region_start > info->erase_start) { + const chipoff_t start = info->erase_start; + const chipsize_t len = info->region_start - info->erase_start; + if (flashctx->chip->read(flashctx, backup_contents, start, len)) { + msg_cerr("Can't read! Aborting.\n"); + goto _free_ret; + } + } + /* Merge data following the current region. */ + if (info->erase_end > info->region_end) { + const chipoff_t start = info->region_end + 1; + const chipoff_t rel_start = start - info->erase_start; /* within this erase block */ + const chipsize_t len = info->erase_end - info->region_end; + if (flashctx->chip->read(flashctx, backup_contents + rel_start, start, len)) { + msg_cerr("Can't read! Aborting.\n"); + goto _free_ret; + } + } + } + + ret = 1; all_skipped = false;
msg_cdbg("E"); if (erasefn(flashctx, info->erase_start, erase_len)) - return 1; + goto _free_ret; if (check_erased_range(flashctx, info->erase_start, erase_len)) { msg_cerr("ERASE FAILED!\n"); - return 1; + goto _free_ret; } - return 0; + + if (region_unaligned) { + unsigned int starthere = 0, lenhere = 0, writecount = 0; + /* get_next_write() sets starthere to a new value after the call. */ + while ((lenhere = get_next_write(erased_contents + starthere, backup_contents + starthere, + erase_len - starthere, &starthere, flashctx->chip->gran))) { + if (!writecount++) + msg_cdbg("W"); + /* Needs the partial write function signature. */ + if (flashctx->chip->write(flashctx, backup_contents + starthere, + info->erase_start + starthere, lenhere)) + goto _free_ret; + starthere += lenhere; + } + } + + ret = 0; + +_free_ret: + free(erased_contents); + free(backup_contents); + return ret; }
/**
Paul Menzel has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/31068 )
Change subject: Fix erasing of unaligned regions ......................................................................
Patch Set 1: Code-Review+1
Hello Paul Menzel, build bot (Jenkins),
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/flashrom/+/31068
to look at the new patch set (#2).
Change subject: Fix erasing of unaligned regions ......................................................................
Fix erasing of unaligned regions
The erase (-E) feature is somehow a brute force method, but still, if we are given a region to erase, we should make sure to restore surrounding data if the erase block expands beyond the region.
It shares a lot of code with the write path. Though, experiments with common functions have shown that it would make the whole function even harder to read. Maybe we could add some abstraction if we ever need similar code on a third path.
Change-Id: I5fc35310f0b090f218cd1d660e27fb39dd05c3c5 Signed-off-by: Nico Huber nico.huber@secunet.com --- M flashrom.c 1 file changed, 66 insertions(+), 3 deletions(-)
git pull ssh://review.coreboot.org:29418/flashrom refs/changes/68/31068/2
Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/31068 )
Change subject: Fix erasing of unaligned regions ......................................................................
Patch Set 3: Code-Review+1
Patrick Georgi has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/31068 )
Change subject: Fix erasing of unaligned regions ......................................................................
Patch Set 3:
(1 comment)
https://review.coreboot.org/#/c/31068/3/flashrom.c File flashrom.c:
https://review.coreboot.org/#/c/31068/3/flashrom.c@1806 PS3, Line 1806: free(erased_contents); since flashrom is building on everything under the sun: there are systems that strongly dislike free(NULL), so guard it? (for example, Solaris IIRC)
Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/31068 )
Change subject: Fix erasing of unaligned regions ......................................................................
Patch Set 3:
(1 comment)
https://review.coreboot.org/#/c/31068/3/flashrom.c File flashrom.c:
https://review.coreboot.org/#/c/31068/3/flashrom.c@1806 PS3, Line 1806: free(erased_contents);
since flashrom is building on everything under the sun: there are systems that strongly dislike free […]
Hmmm, it feels like the exception for free(NULL) has been in the standard forever. Are you sure there are still problematic implementations in the wild? I fear, I have planted many cases of that into flashrom by now.
Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/31068 )
Change subject: Fix erasing of unaligned regions ......................................................................
Patch Set 3:
How about risking it on master and guarding on the 1.0.x cherry-pick?
Patrick Georgi has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/31068 )
Change subject: Fix erasing of unaligned regions ......................................................................
Patch Set 3: Code-Review+2
Patch Set 3:
How about risking it on master and guarding on the 1.0.x cherry-pick?
I tried to find some source to support that recollection but I can't, so for what it's worth, feel free to do it.
At the point where these free()s happen (and a crash would occur), everything crucial has been done anyway.
Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/31068 )
Change subject: Fix erasing of unaligned regions ......................................................................
Patch Set 3:
Many thanks for the review! :)
How about risking it on master and guarding on the 1.0.x cherry-pick?
I'll do just that to be safe. Style doesn't matter on the branch.
I tried to find some source to support that recollection but I can't, so for what it's worth, feel free to do it.
At the point where these free()s happen (and a crash would occur), everything crucial has been done anyway.
That too.
Btw. do you know any easy way to test Solaris? some live image that you could just boot in qemu, maybe?
Hello Angel Pons, Arthur Heymans, David Hendricks, Paul Menzel, build bot (Jenkins), Patrick Georgi,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/flashrom/+/31068
to look at the new patch set (#4).
Change subject: Fix erasing of unaligned regions ......................................................................
Fix erasing of unaligned regions
The erase (-E) feature is somehow a brute force method, but still, if we are given a region to erase, we should make sure to restore surrounding data if the erase block expands beyond the region.
Slight alteration from `master` commit: Guard free() from NULL pointers to be regression safe even in case of broken libc.
Change-Id: I5fc35310f0b090f218cd1d660e27fb39dd05c3c5 Signed-off-by: Nico Huber nico.huber@secunet.com --- M flashrom.c 1 file changed, 68 insertions(+), 3 deletions(-)
git pull ssh://review.coreboot.org:29418/flashrom refs/changes/68/31068/4
Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/31068 )
Change subject: Fix erasing of unaligned regions ......................................................................
Patch Set 4:
meh, wrong push
Hello Angel Pons, Arthur Heymans, David Hendricks, Paul Menzel, build bot (Jenkins), Patrick Georgi,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/flashrom/+/31068
to look at the new patch set (#5).
Change subject: Fix erasing of unaligned regions ......................................................................
Fix erasing of unaligned regions
The erase (-E) feature is somehow a brute force method, but still, if we are given a region to erase, we should make sure to restore surrounding data if the erase block expands beyond the region.
It shares a lot of code with the write path. Though, experiments with common functions have shown that it would make the whole function even harder to read. Maybe we could add some abstraction if we ever need similar code on a third path.
Change-Id: I5fc35310f0b090f218cd1d660e27fb39dd05c3c5 Signed-off-by: Nico Huber nico.huber@secunet.com --- M flashrom.c 1 file changed, 66 insertions(+), 3 deletions(-)
git pull ssh://review.coreboot.org:29418/flashrom refs/changes/68/31068/5
Nico Huber has submitted this change and it was merged. ( https://review.coreboot.org/c/flashrom/+/31068 )
Change subject: Fix erasing of unaligned regions ......................................................................
Fix erasing of unaligned regions
The erase (-E) feature is somehow a brute force method, but still, if we are given a region to erase, we should make sure to restore surrounding data if the erase block expands beyond the region.
It shares a lot of code with the write path. Though, experiments with common functions have shown that it would make the whole function even harder to read. Maybe we could add some abstraction if we ever need similar code on a third path.
Change-Id: I5fc35310f0b090f218cd1d660e27fb39dd05c3c5 Signed-off-by: Nico Huber nico.huber@secunet.com Reviewed-on: https://review.coreboot.org/c/31068 Tested-by: build bot (Jenkins) no-reply@coreboot.org Reviewed-by: Angel Pons th3fanbus@gmail.com Reviewed-by: Patrick Georgi pgeorgi@google.com --- M flashrom.c 1 file changed, 66 insertions(+), 3 deletions(-)
Approvals: build bot (Jenkins): Verified Patrick Georgi: Looks good to me, approved Angel Pons: Looks good to me, but someone else must approve
diff --git a/flashrom.c b/flashrom.c index e82c32e..b9e2b41 100644 --- a/flashrom.c +++ b/flashrom.c @@ -1732,17 +1732,80 @@ const struct walk_info *const info, const erasefn_t erasefn) { const unsigned int erase_len = info->erase_end + 1 - info->erase_start; + const bool region_unaligned = info->region_start > info->erase_start || + info->erase_end > info->region_end; + uint8_t *backup_contents = NULL, *erased_contents = NULL; + int ret = 2;
+ /* + * If the region is not erase-block aligned, merge current flash con- + * tents into a new buffer `backup_contents`. + */ + if (region_unaligned) { + backup_contents = malloc(erase_len); + erased_contents = malloc(erase_len); + if (!backup_contents || !erased_contents) { + msg_cerr("Out of memory!\n"); + ret = 1; + goto _free_ret; + } + memset(backup_contents, ERASED_VALUE(flashctx), erase_len); + memset(erased_contents, ERASED_VALUE(flashctx), erase_len); + + msg_cdbg("R"); + /* Merge data preceding the current region. */ + if (info->region_start > info->erase_start) { + const chipoff_t start = info->erase_start; + const chipsize_t len = info->region_start - info->erase_start; + if (flashctx->chip->read(flashctx, backup_contents, start, len)) { + msg_cerr("Can't read! Aborting.\n"); + goto _free_ret; + } + } + /* Merge data following the current region. */ + if (info->erase_end > info->region_end) { + const chipoff_t start = info->region_end + 1; + const chipoff_t rel_start = start - info->erase_start; /* within this erase block */ + const chipsize_t len = info->erase_end - info->region_end; + if (flashctx->chip->read(flashctx, backup_contents + rel_start, start, len)) { + msg_cerr("Can't read! Aborting.\n"); + goto _free_ret; + } + } + } + + ret = 1; all_skipped = false;
msg_cdbg("E"); if (erasefn(flashctx, info->erase_start, erase_len)) - return 1; + goto _free_ret; if (check_erased_range(flashctx, info->erase_start, erase_len)) { msg_cerr("ERASE FAILED!\n"); - return 1; + goto _free_ret; } - return 0; + + if (region_unaligned) { + unsigned int starthere = 0, lenhere = 0, writecount = 0; + /* get_next_write() sets starthere to a new value after the call. */ + while ((lenhere = get_next_write(erased_contents + starthere, backup_contents + starthere, + erase_len - starthere, &starthere, flashctx->chip->gran))) { + if (!writecount++) + msg_cdbg("W"); + /* Needs the partial write function signature. */ + if (flashctx->chip->write(flashctx, backup_contents + starthere, + info->erase_start + starthere, lenhere)) + goto _free_ret; + starthere += lenhere; + } + } + + ret = 0; + +_free_ret: + free(erased_contents); + free(backup_contents); + return ret; }
/**