arm64: Expand arm64 image header
Subsystems (2)
PATCH 1/1 arm64: Expand arm64 image header
Expand the arm64 image header to allow for co-existance with PE/COFF header required by the EFI stub. The PE/COFF format requires the "MZ" header to be at offset 0, and the offset to the PE/COFF header to be at offset 0x3c. The image header is expanded to allow 2 instructions at the beginning to accommodate a benign intruction at offset 0 that includes the "MZ" header, a magic number, and the offset to the PE/COFF header.
--- Documentation/arm64/booting.txt | 16 +++++++++++++--- arch/arm64/kernel/head.S | 8 ++++++++ 2 files changed, 21 insertions(+), 3 deletions(-)
Documentation/arm64/booting.txt +13 -3
@@ -68,13 +68,23 @@ Image target is available instead. Requirement: MANDATORY -The decompressed kernel image contains a 32-byte header as follows: +The decompressed kernel image contains a 64-byte header as follows: - u32 magic = 0x14000008; /* branch to stext, little-endian */ - u32 res0 = 0; /* reserved */ + u32 code0; /* Executable code */ + u32 code1; /* Executable code */ u64 text_offset; /* Image load offset */ + u64 res0 = 0; /* reserved */ u64 res1 = 0; /* reserved */ u64 res2 = 0; /* reserved */ + u64 res3 = 0; /* reserved */ + u64 res4 = 0; /* reserved */ + u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */ + u32 res5 = 0; /* reserved */ + + +Header notes: + +- code0/code1 are responsible for branching to stext. The image must be placed at the specified offset (currently 0x80000) from the start of the system RAM and called there. The start of the
arch/arm64/kernel/head.S +8 -0
@@ -112,6 +112,14 @@ .quad TEXT_OFFSET // Image load offset from start of RAM .quad 0 // reserved .quad 0 // reserved + .quad 0 // reserved + .quad 0 // reserved + .quad 0 // reserved + .byte 0x41 // Magic number, "ARM\x64" + .byte 0x52 + .byte 0x4d + .byte 0x64 + .word 0 // reserved ENTRY(stext) mov x21, x0 // x21=FDT
Signature · 1 line
1.7.10.4
PATCH 1/1 arm64: Expand arm64 image header
Quoted 34 lines · Roy Franz
Expand the arm64 image header to allow for co-existance with PE/COFF header required by the EFI stub. The PE/COFF format requires the "MZ" header to be at offset 0, and the offset to the PE/COFF header to be at offset
0x3c. The image header is expanded to allow 2 instructions at the beginning to accommodate a benign intruction at offset 0 that includes the "MZ" header, a magic number, and the offset to the PE/COFF header.Signed-off-by Roy Franz <[email protected]>--- Documentation/arm64/booting.txt | 16 +++++++++++++--- arch/arm64/kernel/head.S | 8 ++++++++ 2 files changed, 21 insertions(+), 3 deletions(-)Documentation/arm64/booting.txt +4
-3@@ -68,13 +68,23 @@ Image target is available instead. Requirement: MANDATORY -The decompressed kernel image contains a 32-byte header as follows: +The decompressed kernel image contains a 64-byte header as follows: - u32 magic = 0x14000008; /* branch to stext, little-endian */ - u32 res0 = 0; /* reserved */ + u32 code0; /* Executable code */ + u32 code1; /* Executable code */ u64 text_offset; /* Image load offset */ + u64 res0 = 0; /* reserved */ u64 res1 = 0; /* reserved */
Documentation/arm64/booting.txt Image target is available instead. · line 87
Quoted 10 lines
Documentation/arm64/booting.txt +9
-0u64 res2 = 0; /* reserved */ + u64 res3 = 0; /* reserved */ + u64 res4 = 0; /* reserved */ + u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */ + u32 res5 = 0; /* reserved */ + + +Header notes: + +- code0/code1 are responsible for branching to stext.
Do we really want to change the already documented image header? Any existing bootloaders which check the magic number would stop working. In my preliminary patches to add an efi stub, I avoid that by making an Image.efi which is an Image file with pe/coff header prepended. I could easily switch to using the above header change, but wanted to point out an alternative that doesn't change the already established header.
--Mark
PATCH 1/1 arm64: Expand arm64 image header
Quoted 54 lines · Mark Salter
Quoted 34 lines · Roy Franz
Expand the arm64 image header to allow for co-existance with PE/COFF header required by the EFI stub. The PE/COFF format requires the "MZ" header to be at offset 0, and the offset to the PE/COFF header to be at offset
0x3c. The image header is expanded to allow 2 instructions at the beginning to accommodate a benign intruction at offset 0 that includes the "MZ" header, a magic number, and the offset to the PE/COFF header.Signed-off-by Roy Franz <[email protected]>--- Documentation/arm64/booting.txt | 16 +++++++++++++--- arch/arm64/kernel/head.S | 8 ++++++++ 2 files changed, 21 insertions(+), 3 deletions(-)Documentation/arm64/booting.txt +4
-3@@ -68,13 +68,23 @@ Image target is available instead. Requirement: MANDATORY -The decompressed kernel image contains a 32-byte header as follows: +The decompressed kernel image contains a 64-byte header as follows: - u32 magic = 0x14000008; /* branch to stext, little-endian */ - u32 res0 = 0; /* reserved */ + u32 code0; /* Executable code */ + u32 code1; /* Executable code */ u64 text_offset; /* Image load offset */ + u64 res0 = 0; /* reserved */ u64 res1 = 0; /* reserved */Documentation/arm64/booting.txt Image target is available instead. · line 87
Quoted 10 lines
Documentation/arm64/booting.txt +9
-0u64 res2 = 0; /* reserved */ + u64 res3 = 0; /* reserved */ + u64 res4 = 0; /* reserved */ + u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */ + u32 res5 = 0; /* reserved */ + + +Header notes: + +- code0/code1 are responsible for branching to stext.Do we really want to change the already documented image header? Any existing bootloaders which check the magic number would stop working. In my preliminary patches to add an efi stub, I avoid that by making an Image.efi which is an Image file with pe/coff header prepended. I could easily switch to using the above header change, but wanted to point out an alternative that doesn't change the already established header.
Quoted 2 lines
--Mark
Hi Mark,
Yes, we do want to make the change, as one the goals is to have a
single binary format, not multiple formats. This was discussed fairly extensively at LCE, and I think my patch represents the consensus on how the EFI stub should be integrated.
Also, since it is early enough in the arm64 development this should be a relatively easy time to make it. I don't think that the current magic number is checked in the current UEFI loader, as the image boots fine with either header. If the current ARM64 loaders don't check the magic number, then they will work with either format, since the entry point is the same.
Roy
PATCH 1/1 arm64: Expand arm64 image header
Quoted 71 lines · Roy Franz
Quoted 54 lines · Mark Salter
Quoted 34 lines · Roy Franz
Expand the arm64 image header to allow for co-existance with PE/COFF header required by the EFI stub. The PE/COFF format requires the "MZ" header to be at offset 0, and the offset to the PE/COFF header to be at offset
0x3c. The image header is expanded to allow 2 instructions at the beginning to accommodate a benign intruction at offset 0 that includes the "MZ" header, a magic number, and the offset to the PE/COFF header.Signed-off-by Roy Franz <[email protected]>--- Documentation/arm64/booting.txt | 16 +++++++++++++--- arch/arm64/kernel/head.S | 8 ++++++++ 2 files changed, 21 insertions(+), 3 deletions(-)Documentation/arm64/booting.txt +4
-3@@ -68,13 +68,23 @@ Image target is available instead. Requirement: MANDATORY -The decompressed kernel image contains a 32-byte header as follows: +The decompressed kernel image contains a 64-byte header as follows: - u32 magic = 0x14000008; /* branch to stext, little-endian */ - u32 res0 = 0; /* reserved */ + u32 code0; /* Executable code */ + u32 code1; /* Executable code */ u64 text_offset; /* Image load offset */ + u64 res0 = 0; /* reserved */ u64 res1 = 0; /* reserved */Documentation/arm64/booting.txt Image target is available instead. · line 87
Quoted 10 lines
Documentation/arm64/booting.txt +9
-0u64 res2 = 0; /* reserved */ + u64 res3 = 0; /* reserved */ + u64 res4 = 0; /* reserved */ + u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */ + u32 res5 = 0; /* reserved */ + + +Header notes: + +- code0/code1 are responsible for branching to stext.Do we really want to change the already documented image header? Any existing bootloaders which check the magic number would stop working. In my preliminary patches to add an efi stub, I avoid that by making an Image.efi which is an Image file with pe/coff header prepended. I could easily switch to using the above header change, but wanted to point out an alternative that doesn't change the already established header.
Quoted 2 lines
--Mark
Hi Mark,
Yes, we do want to make the change, as one the goals is to have a
single binary format, not multiple formats. This was discussed fairly extensively at LCE, and I think my patch represents the consensus on how the EFI stub should be integrated.
Also, since it is early enough in the arm64 development this should be a relatively easy time to make it. I don't think that the current magic number is checked in the current UEFI loader, as the image boots fine with either header. If the current ARM64 loaders don't check the magic number, then they will work with either format, since the entry point is the same.
Quoted 1 line
Roy
That's fine. I wasn't at LCE, so I just wanted to avoid doubt and point out the alternative. Either way works for the main part of the efi stub so I'm okay with whatever uncompressed image header is used.
--Mark
PATCH 1/1 arm64: Expand arm64 image header
Quoted 72 lines · Mark Salter
Quoted 71 lines · Roy Franz
Quoted 54 lines · Mark Salter
Quoted 34 lines · Roy Franz
Expand the arm64 image header to allow for co-existance with PE/COFF header required by the EFI stub. The PE/COFF format requires the "MZ" header to be at offset 0, and the offset to the PE/COFF header to be at offset
0x3c. The image header is expanded to allow 2 instructions at the beginning to accommodate a benign intruction at offset 0 that includes the "MZ" header, a magic number, and the offset to the PE/COFF header.Signed-off-by Roy Franz <[email protected]>--- Documentation/arm64/booting.txt | 16 +++++++++++++--- arch/arm64/kernel/head.S | 8 ++++++++ 2 files changed, 21 insertions(+), 3 deletions(-)Documentation/arm64/booting.txt +4
-3@@ -68,13 +68,23 @@ Image target is available instead. Requirement: MANDATORY -The decompressed kernel image contains a 32-byte header as follows: +The decompressed kernel image contains a 64-byte header as follows: - u32 magic = 0x14000008; /* branch to stext, little-endian */ - u32 res0 = 0; /* reserved */ + u32 code0; /* Executable code */ + u32 code1; /* Executable code */ u64 text_offset; /* Image load offset */ + u64 res0 = 0; /* reserved */ u64 res1 = 0; /* reserved */Documentation/arm64/booting.txt Image target is available instead. · line 87
Quoted 10 lines
Documentation/arm64/booting.txt +9
-0u64 res2 = 0; /* reserved */ + u64 res3 = 0; /* reserved */ + u64 res4 = 0; /* reserved */ + u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */ + u32 res5 = 0; /* reserved */ + + +Header notes: + +- code0/code1 are responsible for branching to stext.Do we really want to change the already documented image header? Any existing bootloaders which check the magic number would stop working. In my preliminary patches to add an efi stub, I avoid that by making an Image.efi which is an Image file with pe/coff header prepended. I could easily switch to using the above header change, but wanted to point out an alternative that doesn't change the already established header.
Quoted 2 lines
--Mark
Hi Mark,
Yes, we do want to make the change, as one the goals is to have a
single binary format, not multiple formats. This was discussed fairly extensively at LCE, and I think my patch represents the consensus on how the EFI stub should be integrated.
Also, since it is early enough in the arm64 development this should be a relatively easy time to make it. I don't think that the current magic number is checked in the current UEFI loader, as the image boots fine with either header. If the current ARM64 loaders don't check the magic number, then they will work with either format, since the entry point is the same.
Quoted 9 lines
Quoted 1 line
Roy
That's fine. I wasn't at LCE, so I just wanted to avoid doubt and point out the alternative. Either way works for the main part of the efi stub so I'm okay with whatever uncompressed image header is used.
--Mark
Hi Catalin,
Have you had a chance to look at this? Please let me know if this
is acceptable or if you would like changes made.
Thanks,
Roy
Catalin Marinas
maintainerPATCH 1/1 arm64: Expand arm64 image header
In reply to Roy FranzQuoted 11 lines · Roy Franz
Expand the arm64 image header to allow for co-existance with PE/COFF header required by the EFI stub. The PE/COFF format requires the "MZ" header to be at offset 0, and the offset to the PE/COFF header to be at offset
0x3c. The image header is expanded to allow 2 instructions at the beginning to accommodate a benign intruction at offset 0 that includes the "MZ" header, a magic number, and the offset to the PE/COFF header.Signed-off-by Roy Franz <[email protected]>
The patch looks fine to me. I couldn't come up with a better magic number in 4 bytes (something that would suggest Linux kernel). If you have a better idea let me know before the merging window (LKA64 maybe?)
Thanks.
Signature · 1 line
Catalin