Patchwork multiboot: Prevent loading of x86_64 images

login
register
mail settings
Submitter Adam Lackorzynski
Date Aug. 19, 2010, 11:24 a.m.
Message ID <20100819112414.GH22245@os.inf.tu-dresden.de>
Download mbox | patch
Permalink /patch/62142/
State New
Headers show

Comments

Adam Lackorzynski - Aug. 19, 2010, 11:24 a.m.
A via -kernel supplied x86_64 ELF image is being started in 32bit mode.
Detect and exit if a 64bit image has been supplied.

Signed-off-by: Adam Lackorzynski <adam@os.inf.tu-dresden.de>
---
 hw/multiboot.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)
Alexander Graf - Aug. 19, 2010, 11:27 a.m.
On 19.08.2010, at 13:24, Adam Lackorzynski wrote:

> A via -kernel supplied x86_64 ELF image is being started in 32bit mode.
> Detect and exit if a 64bit image has been supplied.

According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way...


Alex
Adam Lackorzynski - Aug. 19, 2010, 11:36 a.m.
On Thu Aug 19, 2010 at 13:27:32 +0200, Alexander Graf wrote:
> 
> On 19.08.2010, at 13:24, Adam Lackorzynski wrote:
> 
> > A via -kernel supplied x86_64 ELF image is being started in 32bit mode.
> > Detect and exit if a 64bit image has been supplied.
> 
> According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way...

Yes, but then the supplied ELF-image should say it's a 32bit one and
switch to 64bit mode itself. That's at least how we do load a 64bit
kernel.



Adam
Alexander Graf - Aug. 19, 2010, 11:40 a.m.
On 19.08.2010, at 13:36, Adam Lackorzynski wrote:

> 
> On Thu Aug 19, 2010 at 13:27:32 +0200, Alexander Graf wrote:
>> 
>> On 19.08.2010, at 13:24, Adam Lackorzynski wrote:
>> 
>>> A via -kernel supplied x86_64 ELF image is being started in 32bit mode.
>>> Detect and exit if a 64bit image has been supplied.
>> 
>> According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way...
> 
> Yes, but then the supplied ELF-image should say it's a 32bit one and
> switch to 64bit mode itself. That's at least how we do load a 64bit
> kernel.

Hrm - maybe you're right:

busu:~ # readelf -a /boot/xen
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32

What does the spec say here? What does grub do?


Alex
Adam Lackorzynski - Aug. 19, 2010, 12:32 p.m.
On Thu Aug 19, 2010 at 13:40:54 +0200, Alexander Graf wrote:
> 
> On 19.08.2010, at 13:36, Adam Lackorzynski wrote:
> 
> > 
> > On Thu Aug 19, 2010 at 13:27:32 +0200, Alexander Graf wrote:
> >> 
> >> On 19.08.2010, at 13:24, Adam Lackorzynski wrote:
> >> 
> >>> A via -kernel supplied x86_64 ELF image is being started in 32bit mode.
> >>> Detect and exit if a 64bit image has been supplied.
> >> 
> >> According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way...
> > 
> > Yes, but then the supplied ELF-image should say it's a 32bit one and
> > switch to 64bit mode itself. That's at least how we do load a 64bit
> > kernel.
> 
> Hrm - maybe you're right:
> 
> busu:~ # readelf -a /boot/xen
> ELF Header:
>   Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
>   Class:                             ELF32
> 
> What does the spec say here? What does grub do?

Grub starts the (multiboot-)OS in 32bit mode. Starting directly in 64bit
mode would require to setup page-tables etc. which is not done.
The Spec doesn't mention 64bit OS at all, and says that 32bit OSs are
fine ("An OS image may be an ordinary 32-bit executable file in the
standard format for that particular operating system, except that it may
be linked at a non-default load address to avoid loading on top of the
...");




Adam
Alexander Graf - Aug. 19, 2010, 12:34 p.m.
On 19.08.2010, at 14:32, Adam Lackorzynski wrote:

> 
> On Thu Aug 19, 2010 at 13:40:54 +0200, Alexander Graf wrote:
>> 
>> On 19.08.2010, at 13:36, Adam Lackorzynski wrote:
>> 
>>> 
>>> On Thu Aug 19, 2010 at 13:27:32 +0200, Alexander Graf wrote:
>>>> 
>>>> On 19.08.2010, at 13:24, Adam Lackorzynski wrote:
>>>> 
>>>>> A via -kernel supplied x86_64 ELF image is being started in 32bit mode.
>>>>> Detect and exit if a 64bit image has been supplied.
>>>> 
>>>> According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way...
>>> 
>>> Yes, but then the supplied ELF-image should say it's a 32bit one and
>>> switch to 64bit mode itself. That's at least how we do load a 64bit
>>> kernel.
>> 
>> Hrm - maybe you're right:
>> 
>> busu:~ # readelf -a /boot/xen
>> ELF Header:
>>  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
>>  Class:                             ELF32
>> 
>> What does the spec say here? What does grub do?
> 
> Grub starts the (multiboot-)OS in 32bit mode. Starting directly in 64bit
> mode would require to setup page-tables etc. which is not done.
> The Spec doesn't mention 64bit OS at all, and says that 32bit OSs are
> fine ("An OS image may be an ordinary 32-bit executable file in the
> standard format for that particular operating system, except that it may
> be linked at a non-default load address to avoid loading on top of the
> ...");

I think we should do the same grub does here. If grub loads 64-bit elf binaries and runs them in 32-bit mode, we should too. If it refuses to load them, we should too.

Alex
Adam Lackorzynski - Aug. 19, 2010, 12:49 p.m.
On Thu Aug 19, 2010 at 14:34:10 +0200, Alexander Graf wrote:
> 
> On 19.08.2010, at 14:32, Adam Lackorzynski wrote:
> 
> > 
> > On Thu Aug 19, 2010 at 13:40:54 +0200, Alexander Graf wrote:
> >> 
> >> On 19.08.2010, at 13:36, Adam Lackorzynski wrote:
> >> 
> >>> 
> >>> On Thu Aug 19, 2010 at 13:27:32 +0200, Alexander Graf wrote:
> >>>> 
> >>>> On 19.08.2010, at 13:24, Adam Lackorzynski wrote:
> >>>> 
> >>>>> A via -kernel supplied x86_64 ELF image is being started in 32bit mode.
> >>>>> Detect and exit if a 64bit image has been supplied.
> >>>> 
> >>>> According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way...
> >>> 
> >>> Yes, but then the supplied ELF-image should say it's a 32bit one and
> >>> switch to 64bit mode itself. That's at least how we do load a 64bit
> >>> kernel.
> >> 
> >> Hrm - maybe you're right:
> >> 
> >> busu:~ # readelf -a /boot/xen
> >> ELF Header:
> >>  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
> >>  Class:                             ELF32
> >> 
> >> What does the spec say here? What does grub do?
> > 
> > Grub starts the (multiboot-)OS in 32bit mode. Starting directly in 64bit
> > mode would require to setup page-tables etc. which is not done.
> > The Spec doesn't mention 64bit OS at all, and says that 32bit OSs are
> > fine ("An OS image may be an ordinary 32-bit executable file in the
> > standard format for that particular operating system, except that it may
> > be linked at a non-default load address to avoid loading on top of the
> > ...");
> 
> I think we should do the same grub does here. If grub loads 64-bit elf
> binaries and runs them in 32-bit mode, we should too. If it refuses to
> load them, we should too.

grub1:

grub> kernel (nd)/tftpboot/adam/bootstrap.elf                                  

Error 13: Invalid or unsupported executable format

grub>


grub2 loads it but then it crashes and reboots. Looks like a bug to me.



Adam
Alexander Graf - Aug. 19, 2010, 1:01 p.m.
On 19.08.2010, at 14:49, Adam Lackorzynski wrote:

> 
> On Thu Aug 19, 2010 at 14:34:10 +0200, Alexander Graf wrote:
>> 
>> On 19.08.2010, at 14:32, Adam Lackorzynski wrote:
>> 
>>> 
>>> On Thu Aug 19, 2010 at 13:40:54 +0200, Alexander Graf wrote:
>>>> 
>>>> On 19.08.2010, at 13:36, Adam Lackorzynski wrote:
>>>> 
>>>>> 
>>>>> On Thu Aug 19, 2010 at 13:27:32 +0200, Alexander Graf wrote:
>>>>>> 
>>>>>> On 19.08.2010, at 13:24, Adam Lackorzynski wrote:
>>>>>> 
>>>>>>> A via -kernel supplied x86_64 ELF image is being started in 32bit mode.
>>>>>>> Detect and exit if a 64bit image has been supplied.
>>>>>> 
>>>>>> According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way...
>>>>> 
>>>>> Yes, but then the supplied ELF-image should say it's a 32bit one and
>>>>> switch to 64bit mode itself. That's at least how we do load a 64bit
>>>>> kernel.
>>>> 
>>>> Hrm - maybe you're right:
>>>> 
>>>> busu:~ # readelf -a /boot/xen
>>>> ELF Header:
>>>> Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
>>>> Class:                             ELF32
>>>> 
>>>> What does the spec say here? What does grub do?
>>> 
>>> Grub starts the (multiboot-)OS in 32bit mode. Starting directly in 64bit
>>> mode would require to setup page-tables etc. which is not done.
>>> The Spec doesn't mention 64bit OS at all, and says that 32bit OSs are
>>> fine ("An OS image may be an ordinary 32-bit executable file in the
>>> standard format for that particular operating system, except that it may
>>> be linked at a non-default load address to avoid loading on top of the
>>> ...");
>> 
>> I think we should do the same grub does here. If grub loads 64-bit elf
>> binaries and runs them in 32-bit mode, we should too. If it refuses to
>> load them, we should too.
> 
> grub1:
> 
> grub> kernel (nd)/tftpboot/adam/bootstrap.elf                                  
> 
> Error 13: Invalid or unsupported executable format

Alright.

Acked-by: Alexander Graf <agraf@suse.de>


Alex
Avi Kivity - Aug. 19, 2010, 1:02 p.m.
On 08/19/2010 02:24 PM, Adam Lackorzynski wrote:
> A via -kernel supplied x86_64 ELF image is being started in 32bit mode.
> Detect and exit if a 64bit image has been supplied.
>
>
>
> diff --git a/hw/multiboot.c b/hw/multiboot.c
> index dc980e6..e9dcbc9 100644
> --- a/hw/multiboot.c
> +++ b/hw/multiboot.c
> @@ -171,6 +171,12 @@ int load_multiboot(void *fw_cfg,
>           uint64_t elf_low, elf_high;
>           int kernel_size;
>           fclose(f);
> +
> +        if (((struct elf64_hdr*)header)->e_machine == EM_X86_64) {
> +            fprintf(stderr, "Cannot load x86-64 image, give a 32bit one.\n");
> +            exit(1);
> +        }
> +
>           kernel_size = load_elf(kernel_filename, NULL, NULL,&elf_entry,
>                                  &elf_low,&elf_high, 0, ELF_MACHINE, 0);
>           if (kernel_size<  0) {

We rely on the existing behaviour in kvm-unit-tests.git.  Tests (.flat 
files) are 64-bit elf binaries that are loaded in 32-bit more and switch 
immediately to 64-bit.

We can easily wrap them in a 32-bit elf, but that's a needless complication.
Alexander Graf - Aug. 19, 2010, 1:57 p.m.
On 19.08.2010, at 15:02, Avi Kivity wrote:

> On 08/19/2010 02:24 PM, Adam Lackorzynski wrote:
>> A via -kernel supplied x86_64 ELF image is being started in 32bit mode.
>> Detect and exit if a 64bit image has been supplied.
>> 
>> 
>> 
>> diff --git a/hw/multiboot.c b/hw/multiboot.c
>> index dc980e6..e9dcbc9 100644
>> --- a/hw/multiboot.c
>> +++ b/hw/multiboot.c
>> @@ -171,6 +171,12 @@ int load_multiboot(void *fw_cfg,
>>          uint64_t elf_low, elf_high;
>>          int kernel_size;
>>          fclose(f);
>> +
>> +        if (((struct elf64_hdr*)header)->e_machine == EM_X86_64) {
>> +            fprintf(stderr, "Cannot load x86-64 image, give a 32bit one.\n");
>> +            exit(1);
>> +        }
>> +
>>          kernel_size = load_elf(kernel_filename, NULL, NULL,&elf_entry,
>>                                 &elf_low,&elf_high, 0, ELF_MACHINE, 0);
>>          if (kernel_size<  0) {
> 
> We rely on the existing behaviour in kvm-unit-tests.git.  Tests (.flat files) are 64-bit elf binaries that are loaded in 32-bit more and switch immediately to 64-bit.
> 
> We can easily wrap them in a 32-bit elf, but that's a needless complication.

Well, but if they wouldn't work in grub that doesn't help too much, right? I'm in full sympathy to stick to whatever grub does, as that's the reference implementation.


Alex
Avi Kivity - Aug. 19, 2010, 2:05 p.m.
On 08/19/2010 04:57 PM, Alexander Graf wrote:
>
>> We rely on the existing behaviour in kvm-unit-tests.git.  Tests (.flat files) are 64-bit elf binaries that are loaded in 32-bit more and switch immediately to 64-bit.
>>
>> We can easily wrap them in a 32-bit elf, but that's a needless complication.
> Well, but if they wouldn't work in grub that doesn't help too much, right?

Since the processor vendors don't use kvm-unit-tests.git to test their 
silicon, most people use qemu -kernel to run the unit tests, not grub.

> I'm in full sympathy to stick to whatever grub does, as that's the reference implementation.

Copying reference implementations blindly is a bad idea as you just copy 
their bugs.  In this case, however, the spec does agree with the 
implementation, so I'm fine with the change.  I'm not so hot about the 
elf32 wrapper, but I accept it's the right thing.
Alexander Graf - Aug. 19, 2010, 2:10 p.m.
On 19.08.2010, at 16:05, Avi Kivity wrote:

> On 08/19/2010 04:57 PM, Alexander Graf wrote:
>> 
>>> We rely on the existing behaviour in kvm-unit-tests.git.  Tests (.flat files) are 64-bit elf binaries that are loaded in 32-bit more and switch immediately to 64-bit.
>>> 
>>> We can easily wrap them in a 32-bit elf, but that's a needless complication.
>> Well, but if they wouldn't work in grub that doesn't help too much, right?
> 
> Since the processor vendors don't use kvm-unit-tests.git to test their silicon, most people use qemu -kernel to run the unit tests, not grub.

It would potentially also help the unit tests, as running them in grub would allow for easy verification on real hardware too.

> 
>> I'm in full sympathy to stick to whatever grub does, as that's the reference implementation.
> 
> Copying reference implementations blindly is a bad idea as you just copy their bugs.  In this case, however, the spec does agree with the implementation, so I'm fine with the change.  I'm not so hot about the elf32 wrapper, but I accept it's the right thing.

:)


Alex
Avi Kivity - Aug. 19, 2010, 2:12 p.m.
On 08/19/2010 05:10 PM, Alexander Graf wrote:
>>>
>>>> We rely on the existing behaviour in kvm-unit-tests.git.  Tests (.flat files) are 64-bit elf binaries that are loaded in 32-bit more and switch immediately to 64-bit.
>>>>
>>>> We can easily wrap them in a 32-bit elf, but that's a needless complication.
>>> Well, but if they wouldn't work in grub that doesn't help too much, right?
>> Since the processor vendors don't use kvm-unit-tests.git to test their silicon, most people use qemu -kernel to run the unit tests, not grub.
> It would potentially also help the unit tests, as running them in grub would allow for easy verification on real hardware too.

True.  We need to write an INT 10 driver and a serial driver for this to 
work.
René Rebe - Aug. 20, 2010, 6:47 p.m.
Hi,

On Aug 19, 2010, at 2:49 PM, Adam Lackorzynski wrote:

> 
> On Thu Aug 19, 2010 at 14:34:10 +0200, Alexander Graf wrote:
>> 
>> On 19.08.2010, at 14:32, Adam Lackorzynski wrote:
>> 
>>> 
>>> On Thu Aug 19, 2010 at 13:40:54 +0200, Alexander Graf wrote:
>>>> 
>>>> On 19.08.2010, at 13:36, Adam Lackorzynski wrote:
>>>> 
>>>>> 
>>>>> On Thu Aug 19, 2010 at 13:27:32 +0200, Alexander Graf wrote:
>>>>>> 
>>>>>> On 19.08.2010, at 13:24, Adam Lackorzynski wrote:
>>>>>> 
>>>>>>> A via -kernel supplied x86_64 ELF image is being started in 32bit mode.
>>>>>>> Detect and exit if a 64bit image has been supplied.
>>>>>> 
>>>>>> According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way...
>>>>> 
>>>>> Yes, but then the supplied ELF-image should say it's a 32bit one and
>>>>> switch to 64bit mode itself. That's at least how we do load a 64bit
>>>>> kernel.
>>>> 
>>>> Hrm - maybe you're right:
>>>> 
>>>> busu:~ # readelf -a /boot/xen
>>>> ELF Header:
>>>> Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
>>>> Class:                             ELF32
>>>> 
>>>> What does the spec say here? What does grub do?
>>> 
>>> Grub starts the (multiboot-)OS in 32bit mode. Starting directly in 64bit
>>> mode would require to setup page-tables etc. which is not done.
>>> The Spec doesn't mention 64bit OS at all, and says that 32bit OSs are
>>> fine ("An OS image may be an ordinary 32-bit executable file in the
>>> standard format for that particular operating system, except that it may
>>> be linked at a non-default load address to avoid loading on top of the
>>> ...");
>> 
>> I think we should do the same grub does here. If grub loads 64-bit elf
>> binaries and runs them in 32-bit mode, we should too. If it refuses to
>> load them, we should too.
> 
> grub1:
> 
> grub> kernel (nd)/tftpboot/adam/bootstrap.elf                                  
> 
> Error 13: Invalid or unsupported executable format
> 
> grub>
> 
> 
> grub2 loads it but then it crashes and reboots. Looks like a bug to me.

I once added some x86_64 patch to our grub at T2. I forgot for what, L4, Luvally? At that time it worked, ...

http://svn.exactcode.de/t2/trunk/package/x86/grub/grub-0.97-x86_64.patch

	René

Patch

diff --git a/hw/multiboot.c b/hw/multiboot.c
index dc980e6..e9dcbc9 100644
--- a/hw/multiboot.c
+++ b/hw/multiboot.c
@@ -171,6 +171,12 @@  int load_multiboot(void *fw_cfg,
         uint64_t elf_low, elf_high;
         int kernel_size;
         fclose(f);
+
+        if (((struct elf64_hdr*)header)->e_machine == EM_X86_64) {
+            fprintf(stderr, "Cannot load x86-64 image, give a 32bit one.\n");
+            exit(1);
+        }
+
         kernel_size = load_elf(kernel_filename, NULL, NULL, &elf_entry,
                                &elf_low, &elf_high, 0, ELF_MACHINE, 0);
         if (kernel_size < 0) {