From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ae1TB-0007Ny-Cf for mharc-grub-devel@gnu.org; Thu, 10 Mar 2016 09:21:41 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42416) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ae1T9-0007Nq-1F for grub-devel@gnu.org; Thu, 10 Mar 2016 09:21:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ae1T3-0008Hd-7u for grub-devel@gnu.org; Thu, 10 Mar 2016 09:21:38 -0500 Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:33021) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ae1T3-0008H2-09 for grub-devel@gnu.org; Thu, 10 Mar 2016 09:21:33 -0500 Received: by mail-wm0-x229.google.com with SMTP id l68so30835489wml.0 for ; Thu, 10 Mar 2016 06:21:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeblueprint-co-uk.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=5HLsRAFZGp6UerLHMpEtXK3JpWR8vRZ87CESRvwSTy0=; b=YRdTeON+ELCli6ELavDBcv5lU/7KiRM/L0+Rsat/+TUFxqxTfSJNHchcofWaqedZVn qnlq+e2DFpq/KmtytGu7On35DhPXsDmFump/SZtrTDp4dWTvG95X14b7eLcy8ym7oYyo aaJZrBvb4pzkiMqo1JoQXJ7MPJXT3Q6sTohsS0xMAYFu7vR+f6nk3BHdfqGDh/0dcrnY QgenRm2kMku7Cgkw41iBsGxPhrrJNCi4ZNmX4Vvs3+rU++6/PExBr2S3BHvhuGQHCHRU RDQpzh8lG/b/u1j+y4P0IQAoJ+R23pPYVgXvzUt4uJ89K73S3hPFIHhqoQj3mDLtC0Gx Rn1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=5HLsRAFZGp6UerLHMpEtXK3JpWR8vRZ87CESRvwSTy0=; b=Qn9PaOT2IFZ3Dp9mHMMxzCAyAvKCCj2yjkmdUp9PmoPViErOi4Tit7IBNRwrgebxBF +OpfTDEpwzNkmU7hUxuVP83UMY/Nup8PLV1LFoKWmzn0matGeeuPl8ktYdrRd3CeWr+C ti+FwwyrJ1h4JfkPrZiXoKBkJBoHDwRK1LnKMcMOALCvspa320luZLd3g7YdYTpgX6dq OsndujGaKq0L6DwSljjSTnK0pqaHRYuhuf9ZsDUHsjpcc30qRppGxXssjUnQvEf18FId moeWIaDHlhR/j/GfkWLRcEuuFRf8LPJhzy2IhzrKy77HCQqpLL/aBC9kahKNA0xX3IWC 8QcQ== X-Gm-Message-State: AD7BkJK5kd91/j1QfyycWlAH0pb82X2cImLj3SIekDwhK51wOhHYufO/kZhCREFrNrjyhQ== X-Received: by 10.28.60.84 with SMTP id j81mr4302183wma.91.1457619691700; Thu, 10 Mar 2016 06:21:31 -0800 (PST) Received: from localhost (bcdc58e5.skybroadband.com. [188.220.88.229]) by smtp.gmail.com with ESMTPSA id gt7sm3788082wjc.1.2016.03.10.06.21.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Mar 2016 06:21:30 -0800 (PST) Date: Thu, 10 Mar 2016 14:21:30 +0000 From: Matt Fleming To: Andrei Borzenkov Subject: Re: Linux loader EFI handover (was: Bugs and tasks for 2.02[~rc1]) Message-ID: <20160310142130.GE15775@codeblueprint.co.uk> References: <56DDE5B0.6080002@gmail.com> <56DDEB3D.4010505@gmail.com> <20160307211958.GF13163@redhat.com> <56DDF2AA.3010504@gmail.com> <20160307220132.GI13163@redhat.com> <20160308034010.GA19551@linux-dsax.tai.apac.novell.com> <56DE5BBF.5050108@gmail.com> <20160309151824.GA15775@codeblueprint.co.uk> <56E08454.4020107@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56E08454.4020107@gmail.com> User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::229 Cc: The development of GNU GRUB , Colin Watson , Vladimir 'phcoder' Serbinenko X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 14:21:40 -0000 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? > > 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.