Edward O'Callaghan has uploaded this change for review. ( https://review.coreboot.org/c/flashrom/+/37240 )
Change subject: cbtable.c: don't assume high addresses can fully map 1 MiB ......................................................................
cbtable.c: don't assume high addresses can fully map 1 MiB
Forward port the downstream `commit b17e9e41838`.
When using a forwarding table entry for finding the coreboot table don't assume one has access to a full 1 MiB where the forwarding table entry points to. The reason is that the 1 MiB may cover address regions that have differing cacheability type. As such the kernel will complain and the mapping will fail. Instead, check the header first then map in the bytes that it indicates after sanity validation. That way there is no attempt at requesting an invalid mapping that spans different memory cacheability attributes.
BUG=b:66681446 BRANCH=None TEST=Can successfully run 'flashrom -p host --wp-status' on kahlee without generating PAT errors.
Original-Change-Id: Ic6c5832b069300cced66e11f4ca4a0bbc6e496de Original-Signed-off-by: Aaron Durbin adurbin@chromium.org Original-Reviewed-on: https://chromium-review.googlesource.com/685608 Original-Reviewed-by: Martin Roth martinroth@chromium.org Original-Reviewed-by: Justin TerAvest teravest@chromium.org
Change-Id: I43705c19dd7c816098d03f528bde6f180c4c8f24 Signed-off-by: Edward O'Callaghan quasisec@chromium.org --- M cbtable.c 1 file changed, 61 insertions(+), 8 deletions(-)
git pull ssh://review.coreboot.org:29418/flashrom refs/changes/40/37240/1
diff --git a/cbtable.c b/cbtable.c index e566840..38a9f11 100644 --- a/cbtable.c +++ b/cbtable.c @@ -210,6 +210,66 @@ return NULL; }
+static struct lb_header *find_lb_table_remap(unsigned long start_addr, + uint8_t **table_area) +{ + size_t offset; + unsigned long addr, end; + size_t mapping_size; + void *base; + + mapping_size = getpagesize(); + offset = start_addr % getpagesize(); + start_addr -= offset; + + base = physmap_ro("high tables", start_addr, mapping_size); + if (ERROR_PTR == base) { + msg_perr("Failed getting access to coreboot high tables.\n"); + return NULL; + } + + for (addr = offset, end = getpagesize(); addr < end; addr += 16) { + struct lb_record *recs; + struct lb_header *head; + + /* No more headers to check. */ + if (end - addr < sizeof(*head)) + return NULL; + + head = (struct lb_header *)(((char *)base) + addr); + + if (!lb_header_valid(head, addr)) + continue; + + if (mapping_size - addr < head->table_bytes + sizeof(*head)) { + size_t prev_mapping_size = mapping_size; + mapping_size = head->table_bytes + sizeof(*head); + mapping_size += addr; + mapping_size += getpagesize() - + (mapping_size % getpagesize()); + physunmap(base, prev_mapping_size); + base = physmap_ro("high tables", start_addr, + mapping_size); + if (ERROR_PTR == base) { + msg_perr("Failed getting access to coreboot high tables.\n"); + return NULL; + } + } + + head = (struct lb_header *)(((char *)base) + addr); + recs = + (struct lb_record *)(((char *)base) + addr + sizeof(*head)); + if (!lb_table_valid(head, recs)) + continue; + msg_pdbg("Found coreboot table at 0x%08lx.\n", addr); + *table_area = base; + return head; + } + + physunmap(base, mapping_size); + return NULL; +} + static void find_mainboard(struct lb_record *ptr, unsigned long addr) { struct lb_mainboard *rec; @@ -283,15 +343,8 @@ (((char *)lb_table) + lb_table->header_bytes); if (forward->tag == LB_TAG_FORWARD) { start = forward->forward; - start &= ~(getpagesize() - 1); physunmap_unaligned(table_area, BYTES_TO_MAP); - // FIXME: table_area is never unmapped below, nor is it unmapped above in the no-forward case - table_area = physmap_ro_unaligned("high tables", start, BYTES_TO_MAP); - if (ERROR_PTR == table_area) { - msg_perr("Failed getting access to coreboot high tables.\n"); - return -1; - } - lb_table = find_lb_table(table_area, 0x00000, 0x1000); + lb_table = find_lb_table_remap(start, &table_area); } }
Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/37240 )
Change subject: cbtable.c: don't assume high addresses can fully map 1 MiB ......................................................................
Patch Set 1: Code-Review+2
Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/37240 )
Change subject: cbtable.c: don't assume high addresses can fully map 1 MiB ......................................................................
Patch Set 1: Code-Review+1
(3 comments)
Just some comments and nits. We allow up to 112 chars per line if it increases readability. I think that's the case for all the prematurely wrapped lines here.
https://review.coreboot.org/c/flashrom/+/37240/1/cbtable.c File cbtable.c:
https://review.coreboot.org/c/flashrom/+/37240/1/cbtable.c@231 PS1, Line 231: addr Can't we just use `offset`? It seems to be the better name. I was confused by `addr` in about every other line mentioning it below.
https://review.coreboot.org/c/flashrom/+/37240/1/cbtable.c@255 PS1, Line 255: return NULL; Why not continue with the original base?
It seems inconsistent because we continue searching if lb_header_valid() && !lb_table_valid() but not if lb_header_valid() && "bad length/mapping"?
https://review.coreboot.org/c/flashrom/+/37240/1/cbtable.c@259 PS1, Line 259: head = (struct lb_header *)(((char *)base) + addr); Move this inside the `if` so it becomes clear that it's for the updated `base`?
Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/37240 )
Change subject: cbtable.c: don't assume high addresses can fully map 1 MiB ......................................................................
Patch Set 1:
(1 comment)
https://review.coreboot.org/c/flashrom/+/37240/1/cbtable.c File cbtable.c:
https://review.coreboot.org/c/flashrom/+/37240/1/cbtable.c@260 PS1, Line 260: recs = This line break looks really odd.
Hello build bot (Jenkins), Nico Huber, Daniel Kurtz, Patrick Georgi, Stefan Reinauer, Aaron Durbin,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/flashrom/+/37240
to look at the new patch set (#2).
Change subject: cbtable.c: don't assume high addresses can fully map 1 MiB ......................................................................
cbtable.c: don't assume high addresses can fully map 1 MiB
Forward port the downstream `commit b17e9e41838`.
When using a forwarding table entry for finding the coreboot table don't assume one has access to a full 1 MiB where the forwarding table entry points to. The reason is that the 1 MiB may cover address regions that have differing cacheability type. As such the kernel will complain and the mapping will fail. Instead, check the header first then map in the bytes that it indicates after sanity validation. That way there is no attempt at requesting an invalid mapping that spans different memory cacheability attributes.
V.2: Incorperate Nico's and Angels comments from upstream.
BUG=b:66681446 BRANCH=None TEST=Can successfully run 'flashrom -p host --wp-status' on kahlee without generating PAT errors.
Original-Change-Id: Ic6c5832b069300cced66e11f4ca4a0bbc6e496de Original-Signed-off-by: Aaron Durbin adurbin@chromium.org Original-Reviewed-on: https://chromium-review.googlesource.com/685608 Original-Reviewed-by: Martin Roth martinroth@chromium.org Original-Reviewed-by: Justin TerAvest teravest@chromium.org
Change-Id: I43705c19dd7c816098d03f528bde6f180c4c8f24 Signed-off-by: Edward O'Callaghan quasisec@chromium.org --- M cbtable.c 1 file changed, 60 insertions(+), 8 deletions(-)
git pull ssh://review.coreboot.org:29418/flashrom refs/changes/40/37240/2
Edward O'Callaghan has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/37240 )
Change subject: cbtable.c: don't assume high addresses can fully map 1 MiB ......................................................................
Patch Set 1:
(4 comments)
https://review.coreboot.org/c/flashrom/+/37240/1/cbtable.c File cbtable.c:
https://review.coreboot.org/c/flashrom/+/37240/1/cbtable.c@231 PS1, Line 231: addr
Can't we just use `offset`? It seems to be the better name. I was confused […]
Done; This was just taken verbatim from the original patch. Thanks for the suggestions!
https://review.coreboot.org/c/flashrom/+/37240/1/cbtable.c@255 PS1, Line 255: return NULL;
Why not continue with the original base? […]
I was not sure of an adequate test to check that is ok or the best way to structure things to fallback without too much change. So I just left it as is atm.
https://review.coreboot.org/c/flashrom/+/37240/1/cbtable.c@259 PS1, Line 259: head = (struct lb_header *)(((char *)base) + addr);
Move this inside the `if` so it becomes clear that it's for the […]
Done
https://review.coreboot.org/c/flashrom/+/37240/1/cbtable.c@260 PS1, Line 260: recs =
This line break looks really odd.
Done
Hello build bot (Jenkins), Nico Huber, Daniel Kurtz, Patrick Georgi, Stefan Reinauer, Aaron Durbin,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/flashrom/+/37240
to look at the new patch set (#3).
Change subject: cbtable.c: don't assume high addresses can fully map 1 MiB ......................................................................
cbtable.c: don't assume high addresses can fully map 1 MiB
Forward port the downstream `commit b17e9e41838`.
When using a forwarding table entry for finding the coreboot table don't assume one has access to a full 1 MiB where the forwarding table entry points to. The reason is that the 1 MiB may cover address regions that have differing cacheability type. As such the kernel will complain and the mapping will fail. Instead, check the header first then map in the bytes that it indicates after sanity validation. That way there is no attempt at requesting an invalid mapping that spans different memory cacheability attributes.
V.2: Incorperate Nico's and Angels comments from upstream.
BUG=b:66681446 BRANCH=None TEST=Can successfully run 'flashrom -p host --wp-status' on kahlee without generating PAT errors.
Original-Change-Id: Ic6c5832b069300cced66e11f4ca4a0bbc6e496de Original-Signed-off-by: Aaron Durbin adurbin@chromium.org Original-Reviewed-on: https://chromium-review.googlesource.com/685608 Original-Reviewed-by: Martin Roth martinroth@chromium.org Original-Reviewed-by: Justin TerAvest teravest@chromium.org
Change-Id: I43705c19dd7c816098d03f528bde6f180c4c8f24 Signed-off-by: Edward O'Callaghan quasisec@chromium.org --- M cbtable.c 1 file changed, 59 insertions(+), 8 deletions(-)
git pull ssh://review.coreboot.org:29418/flashrom refs/changes/40/37240/3
Edward O'Callaghan has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/37240 )
Change subject: cbtable.c: don't assume high addresses can fully map 1 MiB ......................................................................
Patch Set 3:
(1 comment)
https://review.coreboot.org/c/flashrom/+/37240/1/cbtable.c File cbtable.c:
https://review.coreboot.org/c/flashrom/+/37240/1/cbtable.c@255 PS1, Line 255: return NULL;
I was not sure of an adequate test to check that is ok or the best way to structure things to fallba […]
Actually I saw the simple enough fix now so done.
Hello build bot (Jenkins), Nico Huber, Daniel Kurtz, Patrick Georgi, Stefan Reinauer, Aaron Durbin,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/flashrom/+/37240
to look at the new patch set (#4).
Change subject: cbtable.c: don't assume high addresses can fully map 1 MiB ......................................................................
cbtable.c: don't assume high addresses can fully map 1 MiB
Forward port the downstream `commit b17e9e41838`.
When using a forwarding table entry for finding the coreboot table don't assume one has access to a full 1 MiB where the forwarding table entry points to. The reason is that the 1 MiB may cover address regions that have differing cacheability type. As such the kernel will complain and the mapping will fail. Instead, check the header first then map in the bytes that it indicates after sanity validation. That way there is no attempt at requesting an invalid mapping that spans different memory cacheability attributes.
V.2: Incorperate Nico's and Angels comments from upstream.
BUG=b:66681446 BRANCH=None TEST=Can successfully run 'flashrom -p host --wp-status' on kahlee without generating PAT errors.
Original-Change-Id: Ic6c5832b069300cced66e11f4ca4a0bbc6e496de Original-Signed-off-by: Aaron Durbin adurbin@chromium.org Original-Reviewed-on: https://chromium-review.googlesource.com/685608 Original-Reviewed-by: Martin Roth martinroth@chromium.org Original-Reviewed-by: Justin TerAvest teravest@chromium.org
Change-Id: I43705c19dd7c816098d03f528bde6f180c4c8f24 Signed-off-by: Edward O'Callaghan quasisec@chromium.org --- M cbtable.c 1 file changed, 59 insertions(+), 8 deletions(-)
git pull ssh://review.coreboot.org:29418/flashrom refs/changes/40/37240/4
Attention is currently required from: Edward O'Callaghan. Sam McNally has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/37240 )
Change subject: cbtable.c: don't assume high addresses can fully map 1 MiB ......................................................................
Patch Set 4:
(2 comments)
File cbtable.c:
https://review.coreboot.org/c/flashrom/+/37240/comment/0b609d4b_5297f5f5 PS4, Line 248: mapping_size += getpagesize() - It looks like this shouldn't need to wrap.
https://review.coreboot.org/c/flashrom/+/37240/comment/07bb6caa_134f5f58 PS4, Line 251: base = physmap_ro("high tables", start_addr, Here too.
Attention is currently required from: Edward O'Callaghan. Hello Sam McNally, build bot (Jenkins), Nico Huber, Daniel Kurtz, Patrick Georgi, Stefan Reinauer, Aaron Durbin,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/flashrom/+/37240
to look at the new patch set (#5).
Change subject: cbtable.c: don't assume high addresses can fully map 1 MiB ......................................................................
cbtable.c: don't assume high addresses can fully map 1 MiB
Forward port the downstream `commit b17e9e41838`.
When using a forwarding table entry for finding the coreboot table don't assume one has access to a full 1 MiB where the forwarding table entry points to. The reason is that the 1 MiB may cover address regions that have differing cacheability type. As such the kernel will complain and the mapping will fail. Instead, check the header first then map in the bytes that it indicates after sanity validation. That way there is no attempt at requesting an invalid mapping that spans different memory cacheability attributes.
V.2: Incorperate Nico's and Angels comments from upstream.
BUG=b:66681446 BRANCH=None TEST=Can successfully run 'flashrom -p host --wp-status' on kahlee without generating PAT errors.
Original-Change-Id: Ic6c5832b069300cced66e11f4ca4a0bbc6e496de Original-Signed-off-by: Aaron Durbin adurbin@chromium.org Original-Reviewed-on: https://chromium-review.googlesource.com/685608 Original-Reviewed-by: Martin Roth martinroth@chromium.org Original-Reviewed-by: Justin TerAvest teravest@chromium.org
Change-Id: I43705c19dd7c816098d03f528bde6f180c4c8f24 Signed-off-by: Edward O'Callaghan quasisec@chromium.org --- M cbtable.c 1 file changed, 57 insertions(+), 8 deletions(-)
git pull ssh://review.coreboot.org:29418/flashrom refs/changes/40/37240/5
Attention is currently required from: Sam McNally. Edward O'Callaghan has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/37240 )
Change subject: cbtable.c: don't assume high addresses can fully map 1 MiB ......................................................................
Patch Set 5:
(2 comments)
File cbtable.c:
https://review.coreboot.org/c/flashrom/+/37240/comment/f2cc954e_c9dae50f PS4, Line 248: mapping_size += getpagesize() -
It looks like this shouldn't need to wrap.
Done
https://review.coreboot.org/c/flashrom/+/37240/comment/52bc468f_023b8a6d PS4, Line 251: base = physmap_ro("high tables", start_addr,
Here too.
Done
Attention is currently required from: Edward O'Callaghan. Sam McNally has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/37240 )
Change subject: cbtable.c: don't assume high addresses can fully map 1 MiB ......................................................................
Patch Set 5: Code-Review+2
Edward O'Callaghan has submitted this change. ( https://review.coreboot.org/c/flashrom/+/37240 )
Change subject: cbtable.c: don't assume high addresses can fully map 1 MiB ......................................................................
cbtable.c: don't assume high addresses can fully map 1 MiB
Forward port the downstream `commit b17e9e41838`.
When using a forwarding table entry for finding the coreboot table don't assume one has access to a full 1 MiB where the forwarding table entry points to. The reason is that the 1 MiB may cover address regions that have differing cacheability type. As such the kernel will complain and the mapping will fail. Instead, check the header first then map in the bytes that it indicates after sanity validation. That way there is no attempt at requesting an invalid mapping that spans different memory cacheability attributes.
V.2: Incorperate Nico's and Angels comments from upstream.
BUG=b:66681446 BRANCH=None TEST=Can successfully run 'flashrom -p host --wp-status' on kahlee without generating PAT errors.
Original-Change-Id: Ic6c5832b069300cced66e11f4ca4a0bbc6e496de Original-Signed-off-by: Aaron Durbin adurbin@chromium.org Original-Reviewed-on: https://chromium-review.googlesource.com/685608 Original-Reviewed-by: Martin Roth martinroth@chromium.org Original-Reviewed-by: Justin TerAvest teravest@chromium.org
Change-Id: I43705c19dd7c816098d03f528bde6f180c4c8f24 Signed-off-by: Edward O'Callaghan quasisec@chromium.org Reviewed-on: https://review.coreboot.org/c/flashrom/+/37240 Tested-by: build bot (Jenkins) no-reply@coreboot.org Reviewed-by: Sam McNally sammc@google.com --- M cbtable.c 1 file changed, 57 insertions(+), 8 deletions(-)
Approvals: build bot (Jenkins): Verified Sam McNally: Looks good to me, approved
diff --git a/cbtable.c b/cbtable.c index 6185f12..1424f45 100644 --- a/cbtable.c +++ b/cbtable.c @@ -210,6 +210,62 @@ return NULL; }
+static struct lb_header *find_lb_table_remap(unsigned long start_addr, + uint8_t **table_area) +{ + size_t offset; + unsigned long end; + size_t mapping_size; + void *base; + + mapping_size = getpagesize(); + offset = start_addr % getpagesize(); + start_addr -= offset; + + base = physmap_ro("high tables", start_addr, mapping_size); + if (ERROR_PTR == base) { + msg_perr("Failed getting access to coreboot high tables.\n"); + return NULL; + } + + for (end = getpagesize(); offset < end; offset += 16) { + struct lb_record *recs; + struct lb_header *head; + + /* No more headers to check. */ + if (end - offset < sizeof(*head)) + return NULL; + + head = (struct lb_header *)(((char *)base) + offset); + + if (!lb_header_valid(head, offset)) + continue; + + if (mapping_size - offset < head->table_bytes + sizeof(*head)) { + size_t prev_mapping_size = mapping_size; + mapping_size = head->table_bytes + sizeof(*head); + mapping_size += offset; + mapping_size += getpagesize() - (mapping_size % getpagesize()); + physunmap(base, prev_mapping_size); + base = physmap_ro("high tables", start_addr, mapping_size); + if (ERROR_PTR == base) + msg_perr("Failed getting access to coreboot high tables.\n"); + else + head = (struct lb_header *)(((char *)base) + offset); + } + + recs = (struct lb_record *)(((char *)base) + offset + sizeof(*head)); + if (!lb_table_valid(head, recs)) + continue; + msg_pdbg("Found coreboot table at 0x%08lx.\n", offset); + *table_area = base; + return head; + } + + physunmap(base, mapping_size); + return NULL; +} + static void find_mainboard(struct lb_record *ptr, unsigned long addr) { struct lb_mainboard *rec; @@ -283,15 +339,8 @@ (((char *)lb_table) + lb_table->header_bytes); if (forward->tag == LB_TAG_FORWARD) { start = forward->forward; - start &= ~(getpagesize() - 1); physunmap_unaligned(table_area, BYTES_TO_MAP); - // FIXME: table_area is never unmapped below, nor is it unmapped above in the no-forward case - table_area = physmap_ro_unaligned("high tables", start, BYTES_TO_MAP); - if (ERROR_PTR == table_area) { - msg_perr("Failed getting access to coreboot high tables.\n"); - return -1; - } - lb_table = find_lb_table(table_area, 0x00000, 0x1000); + lb_table = find_lb_table_remap(start, &table_area); } }