lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131205152806.GC974@darko.cambridge.arm.com>
Date:	Thu, 5 Dec 2013 15:28:06 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	Mark Salter <msalter@...hat.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"patches@...aro.org" <patches@...aro.org>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Will Deacon <Will.Deacon@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"matt.fleming@...el.com" <matt.fleming@...el.com>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	Leif Lindholm <leif.lindholm@...aro.org>,
	"roy.franz@...aro.org" <roy.franz@...aro.org>
Subject: Re: [PATCH 1/3] arm64: add EFI stub

On Thu, Dec 05, 2013 at 02:43:23PM +0000, Mark Salter wrote:
> On Thu, 2013-12-05 at 14:18 +0000, Catalin Marinas wrote:
> > On Fri, Nov 29, 2013 at 10:05:10PM +0000, Mark Salter wrote:
> > > This patch adds PE/COFF header fields to the start of the Image
> > > so that it appears as an EFI application to EFI firmware. An EFI
> > > stub is included to allow direct booting of the kernel Image. Due
> > > to EFI firmware limitations, only little endian kernels with 4K
> > > page sizes are supported at this time.
> > 
> > I don't fully understand the EFI firmware limitations but for big endian
> > we could have the EFI_STUB wrapper in little endian and get the kernel
> > to switch to big endian once booted. The image header should always be
> > little endian.
> 
> That would be fun. :) You'd also have to switch back and forth to make
> EFI runtime services calls.

OK, we'll have to live with this restriction.

> > And I have to dig further into the 4K limitation (or you could give a
> > quick summary ;)).
> 
> Just that the current UEFI spec mandates 4K pages for UEFI. So if UEFI
> maps two 4k pages with different attributes and those two pages are
> within the same 64k kernel page, there'd be a problem. I'd be better if
> UEFI used 64k pages, then the kernel could easily use 4k or 64k.

For server space, we may see some people asking for 64K pages. But I
don't know whether there are any UEFI plans here.

Thanks.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ