linux-kernel - Re: [PATCH 16/17] Add EFI stub for ARM

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]

Date:	Wed, 7 Aug 2013 20:33:57 +0200
From:	Leif Lindholm <leif.lindholm@...aro.org>
To:	Dave Martin <Dave.Martin@....com>
Cc:	Roy Franz <roy.franz@...aro.org>, linux-kernel@...r.kernel.org,
	linux-efi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	matt.fleming@...el.com, linux@....linux.org.uk
Subject: Re: [PATCH 16/17] Add EFI stub for ARM

On Wed, Aug 07, 2013 at 07:05:54PM +0100, Dave Martin wrote:
> Is it possible for this allocation to fail -- i.e., because UEFI has
> put us in an unsuitable location which is within the first 128MB of
> RAM, such that we can't pick a suitable location without overlap?
> 
> For the time being though, I think this is impossible because the
> decompressed Image can't exceed ~32MB (so the zImage should not
> exceed that either, and both can fit inside 128MB.  It doesn't
> matter if UEFI's initial load location overlaps the decompressed
> Image).
> 
> If UEFI put reserved regions with the first 128MB we're likely to
> be dead anyway, so we shouldn't assume we'll have to cope with that
> for now...

There is no reason we would be dead unless we end up not being able
to allocate regions for FDT and initrd within range.

There could be some boot services region lying around, that will
be reusable before we even jump to the decompressor. Or there could
be some badly placed runtime code lying where it can safely remain.

Are there additional kernel regions to worry about?

> > +		@ Save return values of efi_entry
> > +		stmfd	sp!, {r0, r3}
> > +		bl	cache_clean_flush
> > +		bl	cache_off
> 
> Why turn the cache off?  Does that mean that EFI may launch images with
> the cache enabled?
 
Yup.

> If so, are we guaranteed that VA=PA?  Otherwise simply turning the MMU
> off is not safe.

Yes, VA=PA is guaranteed.
 
> (Hmm, the UEFI spec seems to suggest "yes" for these questions)
 
:)

/
    Leif
--
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/