kexec segments: align + dedup of strange segments blows up #1845
Comments
Previously, it was assumed that all adjacent segments would have directly adjoining buffers in the virtual space. Fixes u-root#1845 and aids in EFI kexec. Signed-off-by: Chris Koch <chrisko@google.com>
Previously, it was assumed that all adjacent segments would have directly adjoining buffers in the virtual space. Fixes u-root#1845 and aids in EFI kexec. Signed-off-by: Chris Koch <chrisko@google.com>
Previously, it was assumed that all adjacent segments would have directly adjoining buffers in the virtual space. Fixes u-root#1845 and aids in EFI kexec. Signed-off-by: Chris Koch <chrisko@google.com>
Previously, it was assumed that all adjacent segments would have
directly adjoining buffers in the virtual space.
Merging only worked on segments that were directly adjoining, but not
aligned to page size, and where the image address was in lockstep with
the physical addresses, e.g.
virt: [0xff1000, 0xff1234] phys: [0x1000, 0x1234]
virt: [0xff1234, 0xff2000] phys: [0x1234, 0x2000]
However, non-aligned addresses with holes and non-linear continuation
are also valid, e.g. in the case where an image wants to padding with
zeros:
virt: [0xff1000, 0xff1234] phys: [0x1000, 0x1234]
virt: [0xff1234, 0xff2234] phys: [0x2000, 0x2234]
Also, holes in the image that are not linear with the physical address
space are valid:
virt: [0xff1000, 0xff1234] phys: [0x1000, 0x1234]
virt: [0xff1e00, 0xff2000] phys: [0x1aaa, 0x1caa]
Aligning would make all these physical ranges overlap, and it was
assumed that `append(section1Buf, section2Buf)` would be an accurate
merging of these segments. This only worked in some small set of cases,
which ESXi's `b.b00` and our test multibooot kernel happened to fit.
Fixes u-root#1845 and aids in EFI kexec.
Signed-off-by: Chris Koch <chrisko@google.com>
Previously, it was assumed that all adjacent segments would have
directly adjoining buffers in the virtual space.
Merging only worked on segments that were directly adjoining, but not
aligned to page size, and where the image address was in lockstep with
the physical addresses, e.g.
userspace: [0xff1000, 0xff1234] phys: [0x1000, 0x1234]
userspace: [0xff1234, 0xff2000] phys: [0x1234, 0x2000]
However, non-aligned addresses with holes and non-linear continuation
are also valid, e.g. in the case where an image wants to padding with
zeros:
userspace: [0xff1000, 0xff1234] phys: [0x1000, 0x1234]
userspace: [0xff1234, 0xff2234] phys: [0x2000, 0x2234]
Also, holes in the image that are not linear with the physical address
space are valid:
userspace: [0xff1000, 0xff1234] phys: [0x1000, 0x1234]
userspace: [0xff1e00, 0xff2000] phys: [0x1aaa, 0x1caa]
Aligning would make all these physical ranges overlap, and it was
assumed that `append(section1Buf, section2Buf)` would be an accurate
merging of these segments. This only worked in some small set of cases,
which ESXi's `b.b00` and our test multibooot kernel happened to fit.
Fixes u-root#1845 and aids in EFI kexec.
Signed-off-by: Chris Koch <chrisko@google.com>

Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.

the dedup'd set of segments makes no sense.
The text was updated successfully, but these errors were encountered: