These patches have been in my personal queue for about two years, and have already been incorporated into the Ubuntu packaged version of sbsigntool.
Patch #1 and #2 fixes some generic issues, and patch #3 introduces the ARM and AArch64 magic values in the PE/COFF header check, which is all that is needed to get sbsign to sign ARM images.
Ard Biesheuvel (3): sbsigntool: remove doubly defined IMAGE_FILE_MACHINE_AMD64 sbsigntool: fix handling of zero sized sections sbsigntool: add support for ARM and Aarch64 PE/COFF images
src/coff/pe.h | 2 +- src/image.c | 48 +++++++++++--------- 2 files changed, 27 insertions(+), 23 deletions(-)
Signed-off-by: Ard Biesheuvel ard.biesheuvel@linaro.org --- src/coff/pe.h | 1 - 1 file changed, 1 deletion(-)
diff --git a/src/coff/pe.h b/src/coff/pe.h index 601a68e8f113..3a43174ecfff 100644 --- a/src/coff/pe.h +++ b/src/coff/pe.h @@ -151,7 +151,6 @@ #define IMAGE_FILE_MACHINE_THUMB 0x01c2 #define IMAGE_FILE_MACHINE_TRICORE 0x0520 #define IMAGE_FILE_MACHINE_WCEMIPSV2 0x0169 -#define IMAGE_FILE_MACHINE_AMD64 0x8664
#define IMAGE_SUBSYSTEM_UNKNOWN 0 #define IMAGE_SUBSYSTEM_NATIVE 1
The loop that iterates over the PE/COFF sections correctly skips zero sized sections, but still increments the loop index 'i'. This results in subsequent iterations poking into unallocated memory.
Signed-off-by: Ard Biesheuvel ard.biesheuvel@linaro.org --- src/image.c | 35 ++++++++++---------- 1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/src/image.c b/src/image.c index 9fdeecdc19e7..5285fbd0d7c3 100644 --- a/src/image.c +++ b/src/image.c @@ -309,6 +309,7 @@ static int image_find_regions(struct image *image) /* add COFF sections */ for (i = 0; i < image->sections; i++) { uint32_t file_offset, file_size; + int n;
file_offset = pehdr_u32(image->scnhdr[i].s_scnptr); file_size = pehdr_u32(image->scnhdr[i].s_size); @@ -316,39 +317,39 @@ static int image_find_regions(struct image *image) if (!file_size) continue;
- image->n_checksum_regions++; + n = image->n_checksum_regions++; image->checksum_regions = talloc_realloc(image, image->checksum_regions, struct region, image->n_checksum_regions); regions = image->checksum_regions;
- regions[i + 3].data = buf + file_offset; - regions[i + 3].size = align_up(file_size, + regions[n].data = buf + file_offset; + regions[n].size = align_up(file_size, image->file_alignment); - regions[i + 3].name = talloc_strndup(image->checksum_regions, + regions[n].name = talloc_strndup(image->checksum_regions, image->scnhdr[i].s_name, 8); - bytes += regions[i + 3].size; + bytes += regions[n].size;
- if (file_offset + regions[i+3].size > image->size) { + if (file_offset + regions[n].size > image->size) { fprintf(stderr, "warning: file-aligned section %s " "extends beyond end of file\n", - regions[i+3].name); + regions[n].name); }
- if (regions[i+2].data + regions[i+2].size - != regions[i+3].data) { + if (regions[n-1].data + regions[n-1].size + != regions[n].data) { fprintf(stderr, "warning: gap in section table:\n"); fprintf(stderr, " %-8s: 0x%08tx - 0x%08tx,\n", - regions[i+2].name, - regions[i+2].data - buf, - regions[i+2].data + - regions[i+2].size - buf); + regions[n-1].name, + regions[n-1].data - buf, + regions[n-1].data + + regions[n-1].size - buf); fprintf(stderr, " %-8s: 0x%08tx - 0x%08tx,\n", - regions[i+3].name, - regions[i+3].data - buf, - regions[i+3].data + - regions[i+3].size - buf); + regions[n].name, + regions[n].data - buf, + regions[n].data + + regions[n].size - buf);
gap_warn = 1;
Note that for the ARM case, we are using IMAGE_FILE_MACHINE_THUMB (0x1c2) rather than IMAGE_FILE_MACHINE_ARM (0x1c0), as the latter refers to an older calling convention that is incompatible with Tianocore UEFI.
Signed-off-by: Ard Biesheuvel ard.biesheuvel@linaro.org --- src/coff/pe.h | 1 + src/image.c | 13 ++++++++----- 2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/coff/pe.h b/src/coff/pe.h index 3a43174ecfff..0d1036ebe12e 100644 --- a/src/coff/pe.h +++ b/src/coff/pe.h @@ -151,6 +151,7 @@ #define IMAGE_FILE_MACHINE_THUMB 0x01c2 #define IMAGE_FILE_MACHINE_TRICORE 0x0520 #define IMAGE_FILE_MACHINE_WCEMIPSV2 0x0169 +#define IMAGE_FILE_MACHINE_AARCH64 0xaa64
#define IMAGE_SUBSYSTEM_UNKNOWN 0 #define IMAGE_SUBSYSTEM_NATIVE 1 diff --git a/src/image.c b/src/image.c index 5285fbd0d7c3..0fdeb58bd0c3 100644 --- a/src/image.c +++ b/src/image.c @@ -180,13 +180,16 @@ static int image_pecoff_parse(struct image *image) image->opthdr.addr = image->pehdr + 1; magic = pehdr_u16(image->pehdr->f_magic);
- if (magic == IMAGE_FILE_MACHINE_AMD64) { + switch (magic) { + case IMAGE_FILE_MACHINE_AMD64: + case IMAGE_FILE_MACHINE_AARCH64: rc = image_pecoff_parse_64(image); - - } else if (magic == IMAGE_FILE_MACHINE_I386) { + break; + case IMAGE_FILE_MACHINE_I386: + case IMAGE_FILE_MACHINE_THUMB: rc = image_pecoff_parse_32(image); - - } else { + break; + default: fprintf(stderr, "Invalid PE header magic\n"); return -1; }
On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel wrote:
These patches have been in my personal queue for about two years, and have already been incorporated into the Ubuntu packaged version of sbsigntool.
Patch #1 and #2 fixes some generic issues, and patch #3 introduces the ARM and AArch64 magic values in the PE/COFF header check, which is all that is needed to get sbsign to sign ARM images.
Ard Biesheuvel (3): sbsigntool: remove doubly defined IMAGE_FILE_MACHINE_AMD64 sbsigntool: fix handling of zero sized sections sbsigntool: add support for ARM and Aarch64 PE/COFF images
src/coff/pe.h | 2 +- src/image.c | 48 +++++++++++--------- 2 files changed, 27 insertions(+), 23 deletions(-)
I can incorporate them into my build service package like I did for multi-sign. The problem is that Jeremy maintains the upstream and it's not moving:
git://kernel.ubuntu.com/jk/sbsigntool
I presume because Jeremy is now at Ozlabs? Do you have a different upstream URL?
James
On 27 January 2016 at 16:20, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel wrote:
These patches have been in my personal queue for about two years, and have already been incorporated into the Ubuntu packaged version of sbsigntool.
Patch #1 and #2 fixes some generic issues, and patch #3 introduces the ARM and AArch64 magic values in the PE/COFF header check, which is all that is needed to get sbsign to sign ARM images.
Ard Biesheuvel (3): sbsigntool: remove doubly defined IMAGE_FILE_MACHINE_AMD64 sbsigntool: fix handling of zero sized sections sbsigntool: add support for ARM and Aarch64 PE/COFF images
src/coff/pe.h | 2 +- src/image.c | 48 +++++++++++--------- 2 files changed, 27 insertions(+), 23 deletions(-)
I can incorporate them into my build service package like I did for multi-sign. The problem is that Jeremy maintains the upstream and it's not moving:
git://kernel.ubuntu.com/jk/sbsigntool
I presume because Jeremy is now at Ozlabs? Do you have a different upstream URL?
To be honest, I wrote these 2+ years ago, so I don't remember exactly. Someone brought it to my attention that these are not upstream, but if that is still Jeremy instead of you, then yes, I suppose they need to be sent to Jeremy.
Thanks, Ard.
On Wed, 2016-01-27 at 16:31 +0100, Ard Biesheuvel wrote:
On 27 January 2016 at 16:20, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel wrote:
These patches have been in my personal queue for about two years, and have already been incorporated into the Ubuntu packaged version of sbsigntool.
Patch #1 and #2 fixes some generic issues, and patch #3 introduces the ARM and AArch64 magic values in the PE/COFF header check, which is all that is needed to get sbsign to sign ARM images.
Ard Biesheuvel (3): sbsigntool: remove doubly defined IMAGE_FILE_MACHINE_AMD64 sbsigntool: fix handling of zero sized sections sbsigntool: add support for ARM and Aarch64 PE/COFF images
src/coff/pe.h | 2 +- src/image.c | 48 +++++++++++--------- 2 files changed, 27 insertions(+), 23 deletions(-)
I can incorporate them into my build service package like I did for multi-sign. The problem is that Jeremy maintains the upstream and it's not moving:
git://kernel.ubuntu.com/jk/sbsigntool
I presume because Jeremy is now at Ozlabs? Do you have a different upstream URL?
To be honest, I wrote these 2+ years ago, so I don't remember exactly. Someone brought it to my attention that these are not upstream, but if that is still Jeremy instead of you, then yes, I suppose they need to be sent to Jeremy.
You mean
http://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.git/
It's where I keep my changes, but it's not where Ubuntu pulls from.
James
On 27 January 2016 at 16:37, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 16:31 +0100, Ard Biesheuvel wrote:
On 27 January 2016 at 16:20, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel wrote:
These patches have been in my personal queue for about two years, and have already been incorporated into the Ubuntu packaged version of sbsigntool.
Patch #1 and #2 fixes some generic issues, and patch #3 introduces the ARM and AArch64 magic values in the PE/COFF header check, which is all that is needed to get sbsign to sign ARM images.
Ard Biesheuvel (3): sbsigntool: remove doubly defined IMAGE_FILE_MACHINE_AMD64 sbsigntool: fix handling of zero sized sections sbsigntool: add support for ARM and Aarch64 PE/COFF images
src/coff/pe.h | 2 +- src/image.c | 48 +++++++++++--------- 2 files changed, 27 insertions(+), 23 deletions(-)
I can incorporate them into my build service package like I did for multi-sign. The problem is that Jeremy maintains the upstream and it's not moving:
git://kernel.ubuntu.com/jk/sbsigntool
I presume because Jeremy is now at Ozlabs? Do you have a different upstream URL?
To be honest, I wrote these 2+ years ago, so I don't remember exactly. Someone brought it to my attention that these are not upstream, but if that is still Jeremy instead of you, then yes, I suppose they need to be sent to Jeremy.
You mean
http://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.git/
It's where I keep my changes, but it's not where Ubuntu pulls from.
OK. Perhaps Jeremy can confirm where I should send these patches, and which tree to base them on?
Thanks
On Wed, 2016-01-27 at 16:38 +0100, Ard Biesheuvel wrote:
On 27 January 2016 at 16:37, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 16:31 +0100, Ard Biesheuvel wrote:
On 27 January 2016 at 16:20, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel wrote:
These patches have been in my personal queue for about two years, and have already been incorporated into the Ubuntu packaged version of sbsigntool.
Patch #1 and #2 fixes some generic issues, and patch #3 introduces the ARM and AArch64 magic values in the PE/COFF header check, which is all that is needed to get sbsign to sign ARM images.
Ard Biesheuvel (3): sbsigntool: remove doubly defined IMAGE_FILE_MACHINE_AMD64 sbsigntool: fix handling of zero sized sections sbsigntool: add support for ARM and Aarch64 PE/COFF images
src/coff/pe.h | 2 +- src/image.c | 48 +++++++++++--------- 2 files changed, 27 insertions(+), 23 deletions(-)
I can incorporate them into my build service package like I did for multi-sign. The problem is that Jeremy maintains the upstream and it's not moving:
git://kernel.ubuntu.com/jk/sbsigntool
I presume because Jeremy is now at Ozlabs? Do you have a different upstream URL?
To be honest, I wrote these 2+ years ago, so I don't remember exactly. Someone brought it to my attention that these are not upstream, but if that is still Jeremy instead of you, then yes, I suppose they need to be sent to Jeremy.
You mean
http://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.git/
It's where I keep my changes, but it's not where Ubuntu pulls from.
OK. Perhaps Jeremy can confirm where I should send these patches, and which tree to base them on?
If Jeremy doesn't want to, I can. I think the first order of business would be to resolve all the divergent patches, although when I look through the ubuntu one (is this the master?):
https://launchpad.net/ubuntu/+source/sbsigntool
The patch efi_arch_ia32.patch should make it not build for aarch64, so I suspect there's another more recent one somewhere.
James
On 27 January 2016 at 17:16, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 16:38 +0100, Ard Biesheuvel wrote:
On 27 January 2016 at 16:37, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 16:31 +0100, Ard Biesheuvel wrote:
On 27 January 2016 at 16:20, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel wrote:
These patches have been in my personal queue for about two years, and have already been incorporated into the Ubuntu packaged version of sbsigntool.
Patch #1 and #2 fixes some generic issues, and patch #3 introduces the ARM and AArch64 magic values in the PE/COFF header check, which is all that is needed to get sbsign to sign ARM images.
Ard Biesheuvel (3): sbsigntool: remove doubly defined IMAGE_FILE_MACHINE_AMD64 sbsigntool: fix handling of zero sized sections sbsigntool: add support for ARM and Aarch64 PE/COFF images
src/coff/pe.h | 2 +- src/image.c | 48 +++++++++++--------- 2 files changed, 27 insertions(+), 23 deletions(-)
I can incorporate them into my build service package like I did for multi-sign. The problem is that Jeremy maintains the upstream and it's not moving:
git://kernel.ubuntu.com/jk/sbsigntool
I presume because Jeremy is now at Ozlabs? Do you have a different upstream URL?
To be honest, I wrote these 2+ years ago, so I don't remember exactly. Someone brought it to my attention that these are not upstream, but if that is still Jeremy instead of you, then yes, I suppose they need to be sent to Jeremy.
You mean
http://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.git/
It's where I keep my changes, but it's not where Ubuntu pulls from.
OK. Perhaps Jeremy can confirm where I should send these patches, and which tree to base them on?
If Jeremy doesn't want to, I can. I think the first order of business would be to resolve all the divergent patches, although when I look through the ubuntu one (is this the master?):
https://launchpad.net/ubuntu/+source/sbsigntool
The patch efi_arch_ia32.patch should make it not build for aarch64, so I suspect there's another more recent one somewhere.
I honestly haven't tried an aarch64 host, only aarch64 target, which is what I care about mostly tbh.
I know my Ubuntu box's sbsign v0.6 happily signs ARM images since Adam Conrad merged these 3 patches into the ubuntu version (0.6-0ubuntu7 as per your URL)
So if we can decide on a base to continue on, I'll try to resolve any AArch64 host issues if they are still present, and rebase these 3 patches onto it as well.
Thanks, Ard.
On Wed, 2016-01-27 at 17:20 +0100, Ard Biesheuvel wrote:
On 27 January 2016 at 17:16, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 16:38 +0100, Ard Biesheuvel wrote:
On 27 January 2016 at 16:37, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 16:31 +0100, Ard Biesheuvel wrote:
On 27 January 2016 at 16:20, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel wrote: > These patches have been in my personal queue for about > two > years, > and > have already been incorporated into the Ubuntu packaged > version > of > sbsigntool. > > Patch #1 and #2 fixes some generic issues, and patch #3 > introduces > the ARM and AArch64 magic values in the PE/COFF header > check, > which > is all that is needed to get sbsign to sign ARM images. > > > Ard Biesheuvel (3): > sbsigntool: remove doubly defined > IMAGE_FILE_MACHINE_AMD64 > sbsigntool: fix handling of zero sized sections > sbsigntool: add support for ARM and Aarch64 PE/COFF > images > > src/coff/pe.h | 2 +- > src/image.c | 48 +++++++++++--------- > 2 files changed, 27 insertions(+), 23 deletions(-)
I can incorporate them into my build service package like I did for multi-sign. The problem is that Jeremy maintains the upstream and it's not moving:
git://kernel.ubuntu.com/jk/sbsigntool
I presume because Jeremy is now at Ozlabs? Do you have a different upstream URL?
To be honest, I wrote these 2+ years ago, so I don't remember exactly. Someone brought it to my attention that these are not upstream, but if that is still Jeremy instead of you, then yes, I suppose they need to be sent to Jeremy.
You mean
http://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.gi t/
It's where I keep my changes, but it's not where Ubuntu pulls from.
OK. Perhaps Jeremy can confirm where I should send these patches, and which tree to base them on?
If Jeremy doesn't want to, I can. I think the first order of business would be to resolve all the divergent patches, although when I look through the ubuntu one (is this the master?):
https://launchpad.net/ubuntu/+source/sbsigntool
The patch efi_arch_ia32.patch should make it not build for aarch64, so I suspect there's another more recent one somewhere.
I honestly haven't tried an aarch64 host, only aarch64 target, which is what I care about mostly tbh.
Hmm, well here be dragons: the selector selects the EFI ABI based on the host architecture, so if you're cross building for AARCH64 on x86, it's actually pulling in the ABI header files from /usr/include/efi/x86_64 ... I suppose we're just lucky and this happens to be identical to the aarch64 ABI?
I know my Ubuntu box's sbsign v0.6 happily signs ARM images since Adam Conrad merged these 3 patches into the ubuntu version (0.6 -0ubuntu7 as per your URL)
So if we can decide on a base to continue on, I'll try to resolve any AArch64 host issues if they are still present, and rebase these 3 patches onto it as well.
I'll begin the integration in the 1h we just got back from Vincent. At least then we'll know what a combined tree might look like. I can also turn on the aarch64 build on OBS ... although without a test platform I'm not sure that will be useful.
James
On 27 January 2016 at 17:32, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 17:20 +0100, Ard Biesheuvel wrote:
On 27 January 2016 at 17:16, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 16:38 +0100, Ard Biesheuvel wrote:
On 27 January 2016 at 16:37, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 16:31 +0100, Ard Biesheuvel wrote:
On 27 January 2016 at 16:20, James Bottomley James.Bottomley@hansenpartnership.com wrote: > On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel wrote: > > These patches have been in my personal queue for about > > two > > years, > > and > > have already been incorporated into the Ubuntu packaged > > version > > of > > sbsigntool. > > > > Patch #1 and #2 fixes some generic issues, and patch #3 > > introduces > > the ARM and AArch64 magic values in the PE/COFF header > > check, > > which > > is all that is needed to get sbsign to sign ARM images. > > > > > > Ard Biesheuvel (3): > > sbsigntool: remove doubly defined > > IMAGE_FILE_MACHINE_AMD64 > > sbsigntool: fix handling of zero sized sections > > sbsigntool: add support for ARM and Aarch64 PE/COFF > > images > > > > src/coff/pe.h | 2 +- > > src/image.c | 48 +++++++++++--------- > > 2 files changed, 27 insertions(+), 23 deletions(-) > > I can incorporate them into my build service package like I > did > for > multi-sign. The problem is that Jeremy maintains the > upstream > and > it's > not moving: > > git://kernel.ubuntu.com/jk/sbsigntool > > I presume because Jeremy is now at Ozlabs? Do you have a > different > upstream URL? >
To be honest, I wrote these 2+ years ago, so I don't remember exactly. Someone brought it to my attention that these are not upstream, but if that is still Jeremy instead of you, then yes, I suppose they need to be sent to Jeremy.
You mean
http://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.gi t/
It's where I keep my changes, but it's not where Ubuntu pulls from.
OK. Perhaps Jeremy can confirm where I should send these patches, and which tree to base them on?
If Jeremy doesn't want to, I can. I think the first order of business would be to resolve all the divergent patches, although when I look through the ubuntu one (is this the master?):
https://launchpad.net/ubuntu/+source/sbsigntool
The patch efi_arch_ia32.patch should make it not build for aarch64, so I suspect there's another more recent one somewhere.
I honestly haven't tried an aarch64 host, only aarch64 target, which is what I care about mostly tbh.
Hmm, well here be dragons: the selector selects the EFI ABI based on the host architecture, so if you're cross building for AARCH64 on x86, it's actually pulling in the ABI header files from /usr/include/efi/x86_64 ... I suppose we're just lucky and this happens to be identical to the aarch64 ABI?
The parts of the PE/COFF headers that sbsign manipulates only differ between 32-bit and 64-bit (i.e., PE and PE+). Since x86_64 sbsign can correctly sign i386 images (afaict) this shouldn't be an issue
I know my Ubuntu box's sbsign v0.6 happily signs ARM images since Adam Conrad merged these 3 patches into the ubuntu version (0.6 -0ubuntu7 as per your URL)
So if we can decide on a base to continue on, I'll try to resolve any AArch64 host issues if they are still present, and rebase these 3 patches onto it as well.
I'll begin the integration in the 1h we just got back from Vincent. At least then we'll know what a combined tree might look like. I can also turn on the aarch64 build on OBS ... although without a test platform I'm not sure that will be useful.
I'd be happy to organize some automated testing for the ARM and AArch64 side (build time and runtime)
On Wed, 2016-01-27 at 17:36 +0100, Ard Biesheuvel wrote:
On 27 January 2016 at 17:32, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 17:20 +0100, Ard Biesheuvel wrote:
On 27 January 2016 at 17:16, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 16:38 +0100, Ard Biesheuvel wrote:
On 27 January 2016 at 16:37, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Wed, 2016-01-27 at 16:31 +0100, Ard Biesheuvel wrote: > On 27 January 2016 at 16:20, James Bottomley > James.Bottomley@hansenpartnership.com wrote: > > On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel > > wrote: > > > These patches have been in my personal queue for > > > about > > > two > > > years, > > > and > > > have already been incorporated into the Ubuntu > > > packaged > > > version > > > of > > > sbsigntool. > > > > > > Patch #1 and #2 fixes some generic issues, and patch > > > #3 > > > introduces > > > the ARM and AArch64 magic values in the PE/COFF > > > header > > > check, > > > which > > > is all that is needed to get sbsign to sign ARM > > > images. > > > > > > > > > Ard Biesheuvel (3): > > > sbsigntool: remove doubly defined > > > IMAGE_FILE_MACHINE_AMD64 > > > sbsigntool: fix handling of zero sized sections > > > sbsigntool: add support for ARM and Aarch64 PE/COFF > > > images > > > > > > src/coff/pe.h | 2 +- > > > src/image.c | 48 +++++++++++--------- > > > 2 files changed, 27 insertions(+), 23 deletions(-) > > > > I can incorporate them into my build service package > > like I > > did > > for > > multi-sign. The problem is that Jeremy maintains the > > upstream > > and > > it's > > not moving: > > > > git://kernel.ubuntu.com/jk/sbsigntool > > > > I presume because Jeremy is now at Ozlabs? Do you have > > a > > different > > upstream URL? > > > > To be honest, I wrote these 2+ years ago, so I don't > remember > exactly. Someone brought it to my attention that these > are > not > upstream, but if that is still Jeremy instead of you, > then > yes, I > suppose they need to be sent to Jeremy.
You mean
http://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntool s.gi t/
It's where I keep my changes, but it's not where Ubuntu pulls from.
OK. Perhaps Jeremy can confirm where I should send these patches, and which tree to base them on?
If Jeremy doesn't want to, I can. I think the first order of business would be to resolve all the divergent patches, although when I look through the ubuntu one (is this the master?):
https://launchpad.net/ubuntu/+source/sbsigntool
The patch efi_arch_ia32.patch should make it not build for aarch64, so I suspect there's another more recent one somewhere.
I honestly haven't tried an aarch64 host, only aarch64 target, which is what I care about mostly tbh.
Hmm, well here be dragons: the selector selects the EFI ABI based on the host architecture, so if you're cross building for AARCH64 on x86, it's actually pulling in the ABI header files from /usr/include/efi/x86_64 ... I suppose we're just lucky and this happens to be identical to the aarch64 ABI?
The parts of the PE/COFF headers that sbsign manipulates only differ between 32-bit and 64-bit (i.e., PE and PE+). Since x86_64 sbsign can correctly sign i386 images (afaict) this shouldn't be an issue
I know my Ubuntu box's sbsign v0.6 happily signs ARM images since Adam Conrad merged these 3 patches into the ubuntu version (0.6 -0ubuntu7 as per your URL)
So if we can decide on a base to continue on, I'll try to resolve any AArch64 host issues if they are still present, and rebase these 3 patches onto it as well.
I'll begin the integration in the 1h we just got back from Vincent. At least then we'll know what a combined tree might look like. I can also turn on the aarch64 build on OBS ... although without a test platform I'm not sure that will be useful.
I'd be happy to organize some automated testing for the ARM and AArch64 side (build time and runtime)
OK, I got all the ubuntu patches extracted and updated. There's plenty of scope for problems here because the ubuntu tree doesn't do multi -sign and mine does, so there was quite a bit of code motion.
http://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.git/
I'll push it to OBS and if it all seem to work move the version to 0.8
Thanks,
James
Hi James,
On 27/01/16 23:20, James Bottomley wrote:
On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel wrote:
These patches have been in my personal queue for about two years, and have already been incorporated into the Ubuntu packaged version of sbsigntool.
Patch #1 and #2 fixes some generic issues, and patch #3 introduces the ARM and AArch64 magic values in the PE/COFF header check, which is all that is needed to get sbsign to sign ARM images.
Ard Biesheuvel (3): sbsigntool: remove doubly defined IMAGE_FILE_MACHINE_AMD64 sbsigntool: fix handling of zero sized sections sbsigntool: add support for ARM and Aarch64 PE/COFF images
src/coff/pe.h | 2 +- src/image.c | 48 +++++++++++--------- 2 files changed, 27 insertions(+), 23 deletions(-)
I can incorporate them into my build service package like I did for multi-sign. The problem is that Jeremy maintains the upstream and it's not moving:
git://kernel.ubuntu.com/jk/sbsigntool
Yes - I don't have access to the git repo above anymore. I believe Steve Langasek was doing some work on it more recently. Steve - Do you have a new repo somewhere?
Cheers,
Jeremy
On Thu, 2016-01-28 at 07:45 +0800, Jeremy Kerr wrote:
Hi James,
On 27/01/16 23:20, James Bottomley wrote:
On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel wrote:
These patches have been in my personal queue for about two years, and have already been incorporated into the Ubuntu packaged version of sbsigntool.
Patch #1 and #2 fixes some generic issues, and patch #3 introduces the ARM and AArch64 magic values in the PE/COFF header check, which is all that is needed to get sbsign to sign ARM images.
Ard Biesheuvel (3): sbsigntool: remove doubly defined IMAGE_FILE_MACHINE_AMD64 sbsigntool: fix handling of zero sized sections sbsigntool: add support for ARM and Aarch64 PE/COFF images
src/coff/pe.h | 2 +- src/image.c | 48 +++++++++++--------- 2 files changed, 27 insertions(+), 23 deletions(-)
I can incorporate them into my build service package like I did for multi-sign. The problem is that Jeremy maintains the upstream and it's not moving:
git://kernel.ubuntu.com/jk/sbsigntool
Yes - I don't have access to the git repo above anymore. I believe Steve Langasek was doing some work on it more recently. Steve - Do you have a new repo somewhere?
That would be useful. The Ubuntu source is missing multi-sign, which really needs to be added. In the meantime, my integrated repo is here:
http://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.git/
I also set up OBS targets for armv7 and aarch64 here
https://build.opensuse.org/project/show/home:jejb1:UEFI
It's building for them, but I've no idea if it's working. I actually changed the whole setup of the sbsigntools build so the rpm build is effectively slaved from the debian one.
Is there any need to get efitools building for aarch64? It's got a calling convention thunk which prevents the build, but I've been meaning to get rid of it.
James
On 28 January 2016 at 01:10, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 07:45 +0800, Jeremy Kerr wrote:
Hi James,
On 27/01/16 23:20, James Bottomley wrote:
On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel wrote:
These patches have been in my personal queue for about two years, and have already been incorporated into the Ubuntu packaged version of sbsigntool.
Patch #1 and #2 fixes some generic issues, and patch #3 introduces the ARM and AArch64 magic values in the PE/COFF header check, which is all that is needed to get sbsign to sign ARM images.
Ard Biesheuvel (3): sbsigntool: remove doubly defined IMAGE_FILE_MACHINE_AMD64 sbsigntool: fix handling of zero sized sections sbsigntool: add support for ARM and Aarch64 PE/COFF images
src/coff/pe.h | 2 +- src/image.c | 48 +++++++++++--------- 2 files changed, 27 insertions(+), 23 deletions(-)
I can incorporate them into my build service package like I did for multi-sign. The problem is that Jeremy maintains the upstream and it's not moving:
git://kernel.ubuntu.com/jk/sbsigntool
Yes - I don't have access to the git repo above anymore. I believe Steve Langasek was doing some work on it more recently. Steve - Do you have a new repo somewhere?
That would be useful. The Ubuntu source is missing multi-sign, which really needs to be added. In the meantime, my integrated repo is here:
http://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.git/
I also set up OBS targets for armv7 and aarch64 here
https://build.opensuse.org/project/show/home:jejb1:UEFI
It's building for them, but I've no idea if it's working. I actually changed the whole setup of the sbsigntools build so the rpm build is effectively slaved from the debian one.
Is there any need to get efitools building for aarch64? It's got a calling convention thunk which prevents the build, but I've been meaning to get rid of it.
I have added support for ARM and AArch64 to gnu-efi, so porting efitools should be possible as well, but it is non-trivial since the GNU tools for ARM don't support PE/COFF. I will put it on my TODO list.
Thanks, Ard.
On Thu, 2016-01-28 at 10:30 +0100, Ard Biesheuvel wrote:
On 28 January 2016 at 01:10, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 07:45 +0800, Jeremy Kerr wrote:
Hi James,
On 27/01/16 23:20, James Bottomley wrote:
On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel wrote:
These patches have been in my personal queue for about two years, and have already been incorporated into the Ubuntu packaged version of sbsigntool.
Patch #1 and #2 fixes some generic issues, and patch #3 introduces the ARM and AArch64 magic values in the PE/COFF header check, which is all that is needed to get sbsign to sign ARM images.
Ard Biesheuvel (3): sbsigntool: remove doubly defined IMAGE_FILE_MACHINE_AMD64 sbsigntool: fix handling of zero sized sections sbsigntool: add support for ARM and Aarch64 PE/COFF images
src/coff/pe.h | 2 +- src/image.c | 48 +++++++++++--------- 2 files changed, 27 insertions(+), 23 deletions(-)
I can incorporate them into my build service package like I did for multi-sign. The problem is that Jeremy maintains the upstream and it's not moving:
git://kernel.ubuntu.com/jk/sbsigntool
Yes - I don't have access to the git repo above anymore. I believe Steve Langasek was doing some work on it more recently. Steve - Do you have a new repo somewhere?
That would be useful. The Ubuntu source is missing multi-sign, which really needs to be added. In the meantime, my integrated repo is here:
http://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.git/
I also set up OBS targets for armv7 and aarch64 here
https://build.opensuse.org/project/show/home:jejb1:UEFI
It's building for them, but I've no idea if it's working. I actually changed the whole setup of the sbsigntools build so the rpm build is effectively slaved from the debian one.
Is there any need to get efitools building for aarch64? It's got a calling convention thunk which prevents the build, but I've been meaning to get rid of it.
I have added support for ARM and AArch64 to gnu-efi, so porting efitools should be possible as well, but it is non-trivial since the GNU tools for ARM don't support PE/COFF. I will put it on my TODO list.
It's not just efitools; sbsigntools needs it as well. Aarch64 is actually building on OBS, so it must have gnu-efi. armv7l failed because it doesn't.
James
On 28 January 2016 at 16:31, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 10:30 +0100, Ard Biesheuvel wrote:
On 28 January 2016 at 01:10, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 07:45 +0800, Jeremy Kerr wrote:
Hi James,
On 27/01/16 23:20, James Bottomley wrote:
On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel wrote:
These patches have been in my personal queue for about two years, and have already been incorporated into the Ubuntu packaged version of sbsigntool.
Patch #1 and #2 fixes some generic issues, and patch #3 introduces the ARM and AArch64 magic values in the PE/COFF header check, which is all that is needed to get sbsign to sign ARM images.
Ard Biesheuvel (3): sbsigntool: remove doubly defined IMAGE_FILE_MACHINE_AMD64 sbsigntool: fix handling of zero sized sections sbsigntool: add support for ARM and Aarch64 PE/COFF images
src/coff/pe.h | 2 +- src/image.c | 48 +++++++++++--------- 2 files changed, 27 insertions(+), 23 deletions(-)
I can incorporate them into my build service package like I did for multi-sign. The problem is that Jeremy maintains the upstream and it's not moving:
git://kernel.ubuntu.com/jk/sbsigntool
Yes - I don't have access to the git repo above anymore. I believe Steve Langasek was doing some work on it more recently. Steve - Do you have a new repo somewhere?
That would be useful. The Ubuntu source is missing multi-sign, which really needs to be added. In the meantime, my integrated repo is here:
http://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.git/
I also set up OBS targets for armv7 and aarch64 here
https://build.opensuse.org/project/show/home:jejb1:UEFI
It's building for them, but I've no idea if it's working. I actually changed the whole setup of the sbsigntools build so the rpm build is effectively slaved from the debian one.
Is there any need to get efitools building for aarch64? It's got a calling convention thunk which prevents the build, but I've been meaning to get rid of it.
I have added support for ARM and AArch64 to gnu-efi, so porting efitools should be possible as well, but it is non-trivial since the GNU tools for ARM don't support PE/COFF. I will put it on my TODO list.
It's not just efitools; sbsigntools needs it as well. Aarch64 is actually building on OBS, so it must have gnu-efi. armv7l failed because it doesn't.
It does not look like sbsigntools builds anything that executes under UEFI, it only uses the GNUEFI headers to interpret the PE/COFF header format.
On Thu, 2016-01-28 at 16:34 +0100, Ard Biesheuvel wrote:
On 28 January 2016 at 16:31, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 10:30 +0100, Ard Biesheuvel wrote:
On 28 January 2016 at 01:10, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 07:45 +0800, Jeremy Kerr wrote:
Hi James,
On 27/01/16 23:20, James Bottomley wrote:
On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel wrote: > These patches have been in my personal queue for about > two > years, > and > have already been incorporated into the Ubuntu packaged > version > of > sbsigntool. > > Patch #1 and #2 fixes some generic issues, and patch #3 > introduces > the ARM and AArch64 magic values in the PE/COFF header > check, > which > is all that is needed to get sbsign to sign ARM images. > > > Ard Biesheuvel (3): > sbsigntool: remove doubly defined > IMAGE_FILE_MACHINE_AMD64 > sbsigntool: fix handling of zero sized sections > sbsigntool: add support for ARM and Aarch64 PE/COFF > images > > src/coff/pe.h | 2 +- > src/image.c | 48 +++++++++++--------- > 2 files changed, 27 insertions(+), 23 deletions(-)
I can incorporate them into my build service package like I did for multi-sign. The problem is that Jeremy maintains the upstream and it's not moving:
git://kernel.ubuntu.com/jk/sbsigntool
Yes - I don't have access to the git repo above anymore. I believe Steve Langasek was doing some work on it more recently. Steve
Do you have a new repo somewhere?
That would be useful. The Ubuntu source is missing multi-sign, which really needs to be added. In the meantime, my integrated repo is here:
http://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.gi t/
I also set up OBS targets for armv7 and aarch64 here
https://build.opensuse.org/project/show/home:jejb1:UEFI
It's building for them, but I've no idea if it's working. I actually changed the whole setup of the sbsigntools build so the rpm build is effectively slaved from the debian one.
Is there any need to get efitools building for aarch64? It's got a calling convention thunk which prevents the build, but I've been meaning to get rid of it.
I have added support for ARM and AArch64 to gnu-efi, so porting efitools should be possible as well, but it is non-trivial since the GNU tools for ARM don't support PE/COFF. I will put it on my TODO list.
It's not just efitools; sbsigntools needs it as well. Aarch64 is actually building on OBS, so it must have gnu-efi. armv7l failed because it doesn't.
It does not look like sbsigntools builds anything that executes under UEFI, it only uses the GNUEFI headers to interpret the PE/COFF header format.
That's right, but under OBS, which does native building in a virtual machine, it means the gnu-efi package has to be installed for the architectures it builds. If you click on one of the builds, you can see it being installed as part of the build log.
James
On 28 January 2016 at 16:51, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 16:34 +0100, Ard Biesheuvel wrote:
On 28 January 2016 at 16:31, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 10:30 +0100, Ard Biesheuvel wrote:
On 28 January 2016 at 01:10, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 07:45 +0800, Jeremy Kerr wrote:
Hi James,
On 27/01/16 23:20, James Bottomley wrote: > On Wed, 2016-01-27 at 13:17 +0100, Ard Biesheuvel wrote: > > These patches have been in my personal queue for about > > two > > years, > > and > > have already been incorporated into the Ubuntu packaged > > version > > of > > sbsigntool. > > > > Patch #1 and #2 fixes some generic issues, and patch #3 > > introduces > > the ARM and AArch64 magic values in the PE/COFF header > > check, > > which > > is all that is needed to get sbsign to sign ARM images. > > > > > > Ard Biesheuvel (3): > > sbsigntool: remove doubly defined > > IMAGE_FILE_MACHINE_AMD64 > > sbsigntool: fix handling of zero sized sections > > sbsigntool: add support for ARM and Aarch64 PE/COFF > > images > > > > src/coff/pe.h | 2 +- > > src/image.c | 48 +++++++++++--------- > > 2 files changed, 27 insertions(+), 23 deletions(-) > > I can incorporate them into my build service package like I > did > for > multi-sign. The problem is that Jeremy maintains the > upstream > and > it's > not moving: > > git://kernel.ubuntu.com/jk/sbsigntool
Yes - I don't have access to the git repo above anymore. I believe Steve Langasek was doing some work on it more recently. Steve
Do you have a new repo somewhere?
That would be useful. The Ubuntu source is missing multi-sign, which really needs to be added. In the meantime, my integrated repo is here:
http://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.gi t/
I also set up OBS targets for armv7 and aarch64 here
https://build.opensuse.org/project/show/home:jejb1:UEFI
It's building for them, but I've no idea if it's working. I actually changed the whole setup of the sbsigntools build so the rpm build is effectively slaved from the debian one.
Is there any need to get efitools building for aarch64? It's got a calling convention thunk which prevents the build, but I've been meaning to get rid of it.
I have added support for ARM and AArch64 to gnu-efi, so porting efitools should be possible as well, but it is non-trivial since the GNU tools for ARM don't support PE/COFF. I will put it on my TODO list.
It's not just efitools; sbsigntools needs it as well. Aarch64 is actually building on OBS, so it must have gnu-efi. armv7l failed because it doesn't.
It does not look like sbsigntools builds anything that executes under UEFI, it only uses the GNUEFI headers to interpret the PE/COFF header format.
That's right, but under OBS, which does native building in a virtual machine, it means the gnu-efi package has to be installed for the architectures it builds. If you click on one of the builds, you can see it being installed as part of the build log.
Ah, right. I didn't know that.
GNU-EFI does support both ARM and AArch64 now, but I have no idea which distros provide builds of either.
On Thu, 2016-01-28 at 16:53 +0100, Ard Biesheuvel wrote:
On 28 January 2016 at 16:51, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 16:34 +0100, Ard Biesheuvel wrote:
[..]
It does not look like sbsigntools builds anything that executes under UEFI, it only uses the GNUEFI headers to interpret the PE/COFF header format.
That's right, but under OBS, which does native building in a virtual machine, it means the gnu-efi package has to be installed for the architectures it builds. If you click on one of the builds, you can see it being installed as part of the build log.
Ah, right. I didn't know that.
GNU-EFI does support both ARM and AArch64 now, but I have no idea which distros provide builds of either.
I'm not sure it's a complete distribution. I'm building it out of devel:ARM:Factor which is just a bunch of packages someone's collecting on the OBS. However, it's enough to bring up a native virtual build environment, so it could probably be used as the basis for a distribution as well. The aarch64 repository looks fairly complete. The other ARM ones not so much. It's spitting out rpms, so if you're ubuntu based, you could see what alien makes of them. It doesn't look like OBS has a deb based aarch64 target.
James
On Thu, 2016-01-28 at 07:58 -0800, James Bottomley wrote:
On Thu, 2016-01-28 at 16:53 +0100, Ard Biesheuvel wrote:
On 28 January 2016 at 16:51, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 16:34 +0100, Ard Biesheuvel wrote:
[..]
It does not look like sbsigntools builds anything that executes under UEFI, it only uses the GNUEFI headers to interpret the PE/COFF header format.
That's right, but under OBS, which does native building in a virtual machine, it means the gnu-efi package has to be installed for the architectures it builds. If you click on one of the builds, you can see it being installed as part of the build log.
Ah, right. I didn't know that.
GNU-EFI does support both ARM and AArch64 now, but I have no idea which distros provide builds of either.
I'm not sure it's a complete distribution. I'm building it out of devel:ARM:Factor which is just a bunch of packages someone's collecting on the OBS. However, it's enough to bring up a native virtual build environment, so it could probably be used as the basis for a distribution as well. The aarch64 repository looks fairly complete. The other ARM ones not so much. It's spitting out rpms, so if you're ubuntu based, you could see what alien makes of them. It doesn't look like OBS has a deb based aarch64 target.
OK, I reworked the thunking mechanism in efitools and it now builds for aarch64. I'm a bit stuck for testing, though ... it looks like there's no OVMF build for aarch64 ... is that an oversight? (or is everyone supposed to have hardware by now ... not that it will operate fast under qemu on x86, I expect).
James
On 9 February 2016 at 22:30, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 07:58 -0800, James Bottomley wrote:
On Thu, 2016-01-28 at 16:53 +0100, Ard Biesheuvel wrote:
On 28 January 2016 at 16:51, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 16:34 +0100, Ard Biesheuvel wrote:
[..]
It does not look like sbsigntools builds anything that executes under UEFI, it only uses the GNUEFI headers to interpret the PE/COFF header format.
That's right, but under OBS, which does native building in a virtual machine, it means the gnu-efi package has to be installed for the architectures it builds. If you click on one of the builds, you can see it being installed as part of the build log.
Ah, right. I didn't know that.
GNU-EFI does support both ARM and AArch64 now, but I have no idea which distros provide builds of either.
I'm not sure it's a complete distribution. I'm building it out of devel:ARM:Factor which is just a bunch of packages someone's collecting on the OBS. However, it's enough to bring up a native virtual build environment, so it could probably be used as the basis for a distribution as well. The aarch64 repository looks fairly complete. The other ARM ones not so much. It's spitting out rpms, so if you're ubuntu based, you could see what alien makes of them. It doesn't look like OBS has a deb based aarch64 target.
OK, I reworked the thunking mechanism in efitools and it now builds for aarch64. I'm a bit stuck for testing, though ... it looks like there's no OVMF build for aarch64 ... is that an oversight? (or is everyone supposed to have hardware by now ... not that it will operate fast under qemu on x86, I expect).
Ovmf turned out to be slightly too x86-centric to be easily transferable to AArch64, so we have ArmVirtPkg instead.
I believe Steve packaged a build into qemu-efi for Debian/Ubuntu.
/ Leif
On Tue, 2016-02-09 at 23:08 +0000, Leif Lindholm wrote:
On 9 February 2016 at 22:30, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 07:58 -0800, James Bottomley wrote:
On Thu, 2016-01-28 at 16:53 +0100, Ard Biesheuvel wrote:
On 28 January 2016 at 16:51, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 16:34 +0100, Ard Biesheuvel wrote:
[..]
It does not look like sbsigntools builds anything that executes under UEFI, it only uses the GNUEFI headers to interpret the PE/COFF header format.
That's right, but under OBS, which does native building in a virtual machine, it means the gnu-efi package has to be installed for the architectures it builds. If you click on one of the builds, you can see it being installed as part of the build log.
Ah, right. I didn't know that.
GNU-EFI does support both ARM and AArch64 now, but I have no idea which distros provide builds of either.
I'm not sure it's a complete distribution. I'm building it out of devel:ARM:Factor which is just a bunch of packages someone's collecting on the OBS. However, it's enough to bring up a native virtual build environment, so it could probably be used as the basis for a distribution as well. The aarch64 repository looks fairly complete. The other ARM ones not so much. It's spitting out rpms, so if you're ubuntu based, you could see what alien makes of them. It doesn't look like OBS has a deb based aarch64 target.
OK, I reworked the thunking mechanism in efitools and it now builds for aarch64. I'm a bit stuck for testing, though ... it looks like there's no OVMF build for aarch64 ... is that an oversight? (or is everyone supposed to have hardware by now ... not that it will operate fast under qemu on x86, I expect).
Ovmf turned out to be slightly too x86-centric to be easily transferable to AArch64, so we have ArmVirtPkg instead.
Oh, right, sorry, I do remember this now. What's the difference between ArmVirtQemu and ArmVirtQemuKernel?
I believe Steve packaged a build into qemu-efi for Debian/Ubuntu.
If someone actually has the binary, I can try it out; otherwise I'll just get OBS to spit one out soon.
James
On 10 February 2016 at 00:13, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Tue, 2016-02-09 at 23:08 +0000, Leif Lindholm wrote:
On 9 February 2016 at 22:30, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 07:58 -0800, James Bottomley wrote:
On Thu, 2016-01-28 at 16:53 +0100, Ard Biesheuvel wrote:
On 28 January 2016 at 16:51, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 16:34 +0100, Ard Biesheuvel wrote:
[..]
> It does not look like sbsigntools builds anything that > executes > under > UEFI, it only uses the GNUEFI headers to interpret the > PE/COFF > header > format.
That's right, but under OBS, which does native building in a virtual machine, it means the gnu-efi package has to be installed for the architectures it builds. If you click on one of the builds, you can see it being installed as part of the build log.
Ah, right. I didn't know that.
GNU-EFI does support both ARM and AArch64 now, but I have no idea which distros provide builds of either.
I'm not sure it's a complete distribution. I'm building it out of devel:ARM:Factor which is just a bunch of packages someone's collecting on the OBS. However, it's enough to bring up a native virtual build environment, so it could probably be used as the basis for a distribution as well. The aarch64 repository looks fairly complete. The other ARM ones not so much. It's spitting out rpms, so if you're ubuntu based, you could see what alien makes of them. It doesn't look like OBS has a deb based aarch64 target.
OK, I reworked the thunking mechanism in efitools and it now builds for aarch64. I'm a bit stuck for testing, though ... it looks like there's no OVMF build for aarch64 ... is that an oversight? (or is everyone supposed to have hardware by now ... not that it will operate fast under qemu on x86, I expect).
Ovmf turned out to be slightly too x86-centric to be easily transferable to AArch64, so we have ArmVirtPkg instead.
Oh, right, sorry, I do remember this now. What's the difference between ArmVirtQemu and ArmVirtQemuKernel?
The former executes in place from emulated NOR flash, and the latter executes from RAM. Either should work with qemu-system-aarch64, but the former needs to be passed using the -bios switch and the latter via -kernel. Note that (for historical reasons?) qemu-system-aarch64 requires -cpu cortex-a57 to be passed in addition to '-M virt' (for the machine type), since even the 64-bit version emulates a 32-bit CPU by default.
Snapshots are here: http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstre...
I believe Steve packaged a build into qemu-efi for Debian/Ubuntu.
If someone actually has the binary, I can try it out; otherwise I'll just get OBS to spit one out soon.
Happy to pick this up if you send me a link to some binaries.
Thanks, Ard.
On Wed, 2016-02-10 at 11:26 +0100, Ard Biesheuvel wrote:
On 10 February 2016 at 00:13, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Tue, 2016-02-09 at 23:08 +0000, Leif Lindholm wrote:
On 9 February 2016 at 22:30, James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Thu, 2016-01-28 at 07:58 -0800, James Bottomley wrote:
On Thu, 2016-01-28 at 16:53 +0100, Ard Biesheuvel wrote:
On 28 January 2016 at 16:51, James Bottomley James.Bottomley@hansenpartnership.com wrote: > On Thu, 2016-01-28 at 16:34 +0100, Ard Biesheuvel wrote:
[..]
> > It does not look like sbsigntools builds anything that > > executes > > under > > UEFI, it only uses the GNUEFI headers to interpret the > > PE/COFF > > header > > format. > > That's right, but under OBS, which does native building > in a > virtual > machine, it means the gnu-efi package has to be installed > for > the > architectures it builds. If you click on one of the > builds, > you > can > see it being installed as part of the build log. >
Ah, right. I didn't know that.
GNU-EFI does support both ARM and AArch64 now, but I have no idea which distros provide builds of either.
I'm not sure it's a complete distribution. I'm building it out of devel:ARM:Factor which is just a bunch of packages someone's collecting on the OBS. However, it's enough to bring up a native virtual build environment, so it could probably be used as the basis for a distribution as well. The aarch64 repository looks fairly complete. The other ARM ones not so much. It's spitting out rpms, so if you're ubuntu based, you could see what alien makes of them. It doesn't look like OBS has a deb based aarch64 target.
OK, I reworked the thunking mechanism in efitools and it now builds for aarch64. I'm a bit stuck for testing, though ... it looks like there's no OVMF build for aarch64 ... is that an oversight? (or is everyone supposed to have hardware by now ... not that it will operate fast under qemu on x86, I expect).
Ovmf turned out to be slightly too x86-centric to be easily transferable to AArch64, so we have ArmVirtPkg instead.
Oh, right, sorry, I do remember this now. What's the difference between ArmVirtQemu and ArmVirtQemuKernel?
The former executes in place from emulated NOR flash, and the latter executes from RAM. Either should work with qemu-system-aarch64, but the former needs to be passed using the -bios switch and the latter via -kernel. Note that (for historical reasons?) qemu-system-aarch64 requires -cpu cortex-a57 to be passed in addition to '-M virt' (the Machine type), since even the 64-bit version emulates a 32-bit (forCPU by default.
Yes, I finally found SUSE has build instructions:
https://en.opensuse.org/Portal:ARM/AArch64
Snapshots are here: http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2 -upstream/latest/
Thanks, but just in case I need to play, I need OBS to be able to build my own, which I've now got it to do.
I believe Steve packaged a build into qemu-efi for Debian/Ubuntu.
If someone actually has the binary, I can try it out; otherwise I'll just get OBS to spit one out soon.
Happy to pick this up if you send me a link to some binaries.
Actually, I got OBS to do it for me:
http://download.opensuse.org/repositories/home:/jejb1:/UEFI/devel_ARM_Factor...
So I now (finally, after a lot of grubbing around trying to get a proper boostrap [bad suse, no debootstrap]) have a bootable UEFI bios image and a local build container using qemu-aarch64.
What I'm building locally works just fine; obs is being prissy about something in the objects which I have to track down further.
James
On Wed, 2016-02-10 at 16:09 -0800, James Bottomley wrote:
On Wed, 2016-02-10 at 11:26 +0100, Ard Biesheuvel wrote:
Happy to pick this up if you send me a link to some binaries.
Actually, I got OBS to do it for me:
http://download.opensuse.org/repositories/home:/jejb1:/UEFI/devel_ARM _Factory/aarch64/
So I now (finally, after a lot of grubbing around trying to get a proper boostrap [bad suse, no debootstrap]) have a bootable UEFI bios image and a local build container using qemu-aarch64.
What I'm building locally works just fine; obs is being prissy about something in the objects which I have to track down further.
OK, I found and fixed the OBS build so the efitools package now contains efi binaries that work for me in the virtual machine, if you'd like to check them on real hardware, that would be great.
Thanks,
James
-
Ard Biesheuvel -
James Bottomley -
Jeremy Kerr -
Leif Lindholm