From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Matt Fleming <matt@codeblueprint.co.uk>
Cc: The development of GNU GRUB <grub-devel@gnu.org>,
Colin Watson <cjwatson@debian.org>,
Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
Subject: Re: Linux loader EFI handover
Date: Fri, 11 Mar 2016 20:46:05 +0300 [thread overview]
Message-ID: <56E3045D.2050200@gmail.com> (raw)
In-Reply-To: <20160310142130.GE15775@codeblueprint.co.uk>
10.03.2016 17:21, Matt Fleming пишет:
> On Wed, 09 Mar, at 11:15:16PM, Andrei Borzenkov wrote:
>> 09.03.2016 18:18, Matt Fleming пишет:
>>> On Tue, 08 Mar, at 07:57:35AM, Andrei Borzenkov wrote:
>>>>>> - 64-bit kernel on 32-bit platform like Baytrail can't work
>>>>
>>>> Do you mean "32 bit EFI"? If yes, why is it a problem?
>>>
>>> The biggest issue is that there's no way right now for a boot loader
>>> to tell the kernel that it needs to use a translation layer when
>>> calling EFI services (we refer to this as the "thunk" layer in the
>>> kernel) without going via the EFI handover protocol.
>>>
>>> Obviously this could be achieved by writing the required code for GRUB
>>> but it would be largely duplicated from the existing code EFI boot
>>> stub code in the kernel. I don't think it's worth the effort.
>>>
>>
>> That sounds like this should be supported irrespectively of secure boot
>> then.
>
> I'm not sure what you mean here. Are you suggesting to add support for
> the EFI handover protocol to the regular linux loader?
>
Yes.
>>> The kernel figures out when to use the thunk layer by taking note of
>>> which EFI handover offset entry point the boot loader entered from, we
>>> include both a 32-bit and 64-bit entry point when CONFIG_EFI_MIXED is
>>> enabled.
>>>
>>
>> OK, looking at linuxefi patch, the only real difference from normal
>> linux loader is that it restricts memory allocations to below 1G. Is it
>> kernel requirement?
>
> No, I'm not aware of such a requirement for modern kernels, though
> it's possible there was a historical restriction.
>
>> What to do if kernel is compiled without CONFIG_EFI_MIXED support?
>> Should we fall back to traditional handover without calling into EFI
>> stub or fail load completely?
>
> Falling back to the traditional handover and disabling EFI runtime
> services would be the best way to go. You can see whether mixed mode
> is enabled by inspecting the ->xloadflags in the bzImage header.
>
OK, even more reason to support EFI handover as part of normal linux loader.
next prev parent reply other threads:[~2016-03-11 17:46 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 15:01 Bugs and tasks for 2.02[~rc1] Vladimir 'phcoder' Serbinenko
2016-03-02 22:24 ` Daniel Kiper
2016-03-09 10:49 ` Daniel Kiper
[not found] ` <20160309144557.GA19753@char.us.oracle.com>
2016-03-09 14:51 ` Vladimir 'phcoder' Serbinenko
2016-03-09 20:05 ` Daniel Kiper
2016-03-04 20:06 ` Peter Jones
2016-03-05 8:38 ` Andrei Borzenkov
2016-03-07 19:00 ` Peter Jones
2016-03-07 19:57 ` Vladimir 'phcoder' Serbinenko
2016-03-07 20:33 ` Andrei Borzenkov
2016-03-07 20:40 ` Vladimir 'phcoder' Serbinenko
2016-03-07 20:57 ` Andrei Borzenkov
2016-03-07 21:03 ` Vladimir 'phcoder' Serbinenko
2016-03-07 21:20 ` Peter Jones
2016-03-07 21:29 ` Andrei Borzenkov
2016-03-07 22:01 ` Peter Jones
2016-03-07 22:07 ` Vladimir 'phcoder' Serbinenko
2016-03-08 4:16 ` Michael Chang
2016-03-08 3:40 ` Michael Chang
2016-03-08 4:57 ` Andrei Borzenkov
2016-03-09 15:18 ` Matt Fleming
2016-03-09 20:15 ` Linux loader EFI handover (was: Bugs and tasks for 2.02[~rc1]) Andrei Borzenkov
2016-03-10 14:21 ` Matt Fleming
2016-03-11 17:46 ` Andrei Borzenkov [this message]
2016-03-07 21:42 ` Bugs and tasks for 2.02[~rc1] Matt Fleming
2016-03-11 15:51 ` Vladimir 'phcoder' Serbinenko
2016-03-14 15:17 ` Matt Fleming
2016-03-15 17:38 ` Vladimir 'phcoder' Serbinenko
2016-03-22 17:54 ` Peter Jones
2016-03-07 21:14 ` Peter Jones
2016-03-07 21:50 ` Vladimir 'phcoder' Serbinenko
2016-03-07 21:10 ` Peter Jones
2016-03-11 18:01 ` Andrei Borzenkov
2016-03-07 21:03 ` Peter Jones
2016-03-07 21:08 ` Andrei Borzenkov
2016-03-07 21:26 ` Peter Jones
2016-03-07 21:08 ` Vladimir 'phcoder' Serbinenko
2016-03-08 17:57 ` Andrei Borzenkov
2016-03-08 21:47 ` Peter Jones
2016-03-11 18:38 ` Andrei Borzenkov
2016-03-09 6:38 ` Olaf Hering
2016-03-09 7:54 ` Michael Chang
2016-03-09 8:13 ` Andrei Borzenkov
2016-03-11 16:04 ` Vladimir 'phcoder' Serbinenko
2016-04-13 8:49 ` Olaf Hering
2016-03-13 6:30 ` Andrei Borzenkov
2016-03-22 18:48 ` Vladimir 'phcoder' Serbinenko
2016-03-22 19:51 ` Andrei Borzenkov
2016-04-18 4:18 ` Vladimir 'phcoder' Serbinenko
[not found] ` <20160328145903.GF17944@char.us.oracle.com>
2016-04-12 16:44 ` Konrad Rzeszutek Wilk
2016-04-18 4:20 ` Vladimir 'phcoder' Serbinenko
2016-04-12 17:53 ` Bruce Dubbs
2016-04-18 4:20 ` Vladimir 'phcoder' Serbinenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56E3045D.2050200@gmail.com \
--to=arvidjaar@gmail.com \
--cc=cjwatson@debian.org \
--cc=grub-devel@gnu.org \
--cc=matt@codeblueprint.co.uk \
--cc=phcoder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).