I would like to change the defaults for CONFIG_EFI and CONFIG_EFI_STUB
to y. There is little reason to omit this since EFI now is a
significant percentage of all systems.
-hpa
On Fri, 2013-08-09 at 08:23 -0700, H. Peter Anvin wrote:
> I would like to change the defaults for CONFIG_EFI and CONFIG_EFI_STUB
> to y. There is little reason to omit this since EFI now is a
> significant percentage of all systems.
You didn't actually attach the patch, but I presume this is for 64 bit
compiles on x86 only? We still have significant problems getting 64 bit
EFI to interact with 32 bit kernels, so I don't believe we should enable
CONFIG_EFI globally for all of x86.
James
On 08/09/2013 08:32 AM, James Bottomley wrote:
> On Fri, 2013-08-09 at 08:23 -0700, H. Peter Anvin wrote:
>> I would like to change the defaults for CONFIG_EFI and CONFIG_EFI_STUB
>> to y. There is little reason to omit this since EFI now is a
>> significant percentage of all systems.
>
> You didn't actually attach the patch, but I presume this is for 64 bit
> compiles on x86 only? We still have significant problems getting 64 bit
> EFI to interact with 32 bit kernels, so I don't believe we should enable
> CONFIG_EFI globally for all of x86.
>
Well, it doesn't *solve* the problem with cross-mode, but it should work
as-is for EFI32->32-bit kernel and EFI64->64-bit kernel. For the
cross-mode kernels they will simply not do anything.
Either way, nothing bad should come from it. The worst thing that will
happen is that the kernel says "I don't have any EFI that I recognize."
Cross-mode support will always require a secondary bootloader (since as
far as I know there is no concept of "fat binaries" for EFI), but Matt
Fleming is working on genuine cross-mode support for both the boot stub
and (eventually) run time support.
-hpa
On 08/09/2013 08:38 AM, H. Peter Anvin wrote:
> On 08/09/2013 08:32 AM, James Bottomley wrote:
>> On Fri, 2013-08-09 at 08:23 -0700, H. Peter Anvin wrote:
>>> I would like to change the defaults for CONFIG_EFI and CONFIG_EFI_STUB
>>> to y. There is little reason to omit this since EFI now is a
>>> significant percentage of all systems.
>>
>> You didn't actually attach the patch, but I presume this is for 64 bit
>> compiles on x86 only? We still have significant problems getting 64 bit
>> EFI to interact with 32 bit kernels, so I don't believe we should enable
>> CONFIG_EFI globally for all of x86.
>>
>
> Well, it doesn't *solve* the problem with cross-mode, but it should work
> as-is for EFI32->32-bit kernel and EFI64->64-bit kernel. For the
> cross-mode kernels they will simply not do anything.
>
> Either way, nothing bad should come from it. The worst thing that will
> happen is that the kernel says "I don't have any EFI that I recognize."
>
> Cross-mode support will always require a secondary bootloader (since as
> far as I know there is no concept of "fat binaries" for EFI), but Matt
> Fleming is working on genuine cross-mode support for both the boot stub
> and (eventually) run time support.
>
James, does this address your concerns?
-hpa
On Tue, 2013-08-13 at 11:30 -0700, H. Peter Anvin wrote:
> On 08/09/2013 08:38 AM, H. Peter Anvin wrote:
> > On 08/09/2013 08:32 AM, James Bottomley wrote:
> >> On Fri, 2013-08-09 at 08:23 -0700, H. Peter Anvin wrote:
> >>> I would like to change the defaults for CONFIG_EFI and CONFIG_EFI_STUB
> >>> to y. There is little reason to omit this since EFI now is a
> >>> significant percentage of all systems.
> >>
> >> You didn't actually attach the patch, but I presume this is for 64 bit
> >> compiles on x86 only? We still have significant problems getting 64 bit
> >> EFI to interact with 32 bit kernels, so I don't believe we should enable
> >> CONFIG_EFI globally for all of x86.
> >>
> >
> > Well, it doesn't *solve* the problem with cross-mode, but it should work
> > as-is for EFI32->32-bit kernel and EFI64->64-bit kernel. For the
> > cross-mode kernels they will simply not do anything.
> >
> > Either way, nothing bad should come from it. The worst thing that will
> > happen is that the kernel says "I don't have any EFI that I recognize."
> >
> > Cross-mode support will always require a secondary bootloader (since as
> > far as I know there is no concept of "fat binaries" for EFI), but Matt
> > Fleming is working on genuine cross-mode support for both the boot stub
> > and (eventually) run time support.
> >
>
> James, does this address your concerns?
You mean for globally enabling CONFIG_EFI on x86? not really for 32
bit, you say above it's pretty much unusable; I'd prefer just to enable
it for 64 bit. As you said in your original post "since EFI now is a
significant percentage of all systems" but you actually mean EFI64 ...
EFI32 is a pretty insignificant percentage of all systems.
Can we actually boot a 32 bit kernel on an EFI64 system? The last time
I tried on my Secure Boot SDV it wouldn't work; the problem is getting
someting in the transfer of control path to boot the processor back to
32 bit mode.
James
On 08/13/2013 11:43 AM, James Bottomley wrote:
>> James, does this address your concerns?
>
> You mean for globally enabling CONFIG_EFI on x86? not really for 32
> bit, you say above it's pretty much unusable; I'd prefer just to enable
> it for 64 bit. As you said in your original post "since EFI now is a
> significant percentage of all systems" but you actually mean EFI64 ...
> EFI32 is a pretty insignificant percentage of all systems.
For better or worse, there will be more.
> Can we actually boot a 32 bit kernel on an EFI64 system? The last time
> I tried on my Secure Boot SDV it wouldn't work; the problem is getting
> someting in the transfer of control path to boot the processor back to
> 32 bit mode.
We can boot with a bootloader in "skip stub" mode; no runtime services
yet. We are working on making it possible to boot via a EFI stub in
assisted mode (still needing a bootloader, but with the boot stub in the
kernel.)
Runtime services will be the last piece, obviously, but even that looks
reasonably doable.
-hpa
On Tue, 2013-08-13 at 11:52 -0700, H. Peter Anvin wrote:
> On 08/13/2013 11:43 AM, James Bottomley wrote:
> > Can we actually boot a 32 bit kernel on an EFI64 system? The last time
> > I tried on my Secure Boot SDV it wouldn't work; the problem is getting
> > someting in the transfer of control path to boot the processor back to
> > 32 bit mode.
>
> We can boot with a bootloader in "skip stub" mode; no runtime services
> yet.
So the bootloader has to do the 64->32 transition?
> We are working on making it possible to boot via a EFI stub in
> assisted mode (still needing a bootloader, but with the boot stub in the
> kernel.)
>
> Runtime services will be the last piece, obviously, but even that looks
> reasonably doable.
So why not start with the working case (default to EFI on 64 bit) and
add in the mostly non-working case (default to EFI on 32 bit) when it
actually mostly works?
James
On 08/13/2013 12:02 PM, James Bottomley wrote:
> On Tue, 2013-08-13 at 11:52 -0700, H. Peter Anvin wrote:
>> On 08/13/2013 11:43 AM, James Bottomley wrote:
>>> Can we actually boot a 32 bit kernel on an EFI64 system? The last time
>>> I tried on my Secure Boot SDV it wouldn't work; the problem is getting
>>> someting in the transfer of control path to boot the processor back to
>>> 32 bit mode.
>>
>> We can boot with a bootloader in "skip stub" mode; no runtime services
>> yet.
>
> So the bootloader has to do the 64->32 transition?
>
Currently, yes.
>> We are working on making it possible to boot via a EFI stub in
>> assisted mode (still needing a bootloader, but with the boot stub in the
>> kernel.)
>>
>> Runtime services will be the last piece, obviously, but even that looks
>> reasonably doable.
>
> So why not start with the working case (default to EFI on 64 bit) and
> add in the mostly non-working case (default to EFI on 32 bit) when it
> actually mostly works?
We can do that, but I really hate making gratuitous differences between
32 and 64 bits... we have too many of those already.
-hpa
On Tue, Aug 13, 2013 at 11:43:30AM -0700, James Bottomley wrote:
> Can we actually boot a 32 bit kernel on an EFI64 system? The last time
> I tried on my Secure Boot SDV it wouldn't work; the problem is getting
> someting in the transfer of control path to boot the processor back to
> 32 bit mode.
In theory, as long as you jump to the 32-bit entry point having already
set the cpu to that mode. The linux command in grub2 ought to do that.
--
Matthew Garrett | [email protected]