linux-kernel - Re: [PATCH v2 11/15] arm64: add EFI stub

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: <20140319160149.GF2214@arm.com>
Date:	Wed, 19 Mar 2014 16:01:49 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	Mark Salter <msalter@...hat.com>
Cc:	Leif Lindholm <leif.lindholm@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"matt.fleming@...el.com" <matt.fleming@...el.com>,
	"roy.franz@...aro.org" <roy.franz@...aro.org>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>
Subject: Re: [PATCH v2 11/15] arm64: add EFI stub

On Wed, Mar 19, 2014 at 03:13:18PM +0000, Mark Salter wrote:
> On Wed, 2014-03-19 at 10:57 +0000, Catalin Marinas wrote:
> > On Tue, Mar 18, 2014 at 09:40:31PM +0000, Mark Salter wrote:
> > > On Tue, 2014-03-18 at 18:28 +0000, Catalin Marinas wrote:
> > > > If UEFI doesn't handle the caches, the only thing left to EFI_STUB is to
> > > > flush by MVA. We don't need to flush the whole DRAM (and I would even
> > > > recommend it) but at least the relevant kernel code/data touched with
> > > > the MMU disabled.
> > > 
> > > So, it goes like this:
> > > 
> > >   1) UEFI calls stub with MMU/Caches on. Stub/kernel can be anywhere.
> > >   2) Stub runs and relocates kernel to the desired runtime location
> > >      but continues to execute from wherever UEFI loaded it until just
> > >      after ExitBootServices().
> > >   3) After ExitBootServices, efi_entry() returns relocated entry point
> > >      for kernel to efi_stub_entry() in efi-entry.S where the Dcache and
> > >      MMU are turned off, the __flush_dcache_all is called, then the
> > >      code jumps to the kernel proper entry point.
> > > 
> > > It isn't clear to me if UEFI does cache flushing at ExitBootServices
> > > time, but even so, at least stack use will get cached between then and
> > > the kernel entry point. The stub could conceivably get its hands on the
> > > EFI memmap and invalidate dcache using address ranges from UEFI memory
> > > descriptors so maybe that is the way we should do it.
> > 
> > I think the stub just needs to flush the relocated kernel image, ensure
> > it is sync with the memory. Additional flushing can be done by the
> > kernel for bits it writes (like page tables, code patching etc). We can
> > enter the kernel with the SCTLR.I bit set, so it can allocate in an
> > unified cache already and D-cache maintenance would be needed anyway.
> 
> How about this?
> 
> diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
> index 83bfb72..ed480b2 100644
> --- a/arch/arm64/kernel/efi-entry.S
> +++ b/arch/arm64/kernel/efi-entry.S
> @@ -52,11 +52,19 @@ ENTRY(efi_stub_entry)
>  	 * efi_entry() will have relocated the kernel image if necessary
>  	 * and we return here with device tree address in x0 and the kernel
>  	 * entry point stored at *image_addr. Save those values in registers
> -	 * which are preserved by __flush_dcache_all.
> +	 * which are callee preserved.
>  	 */
> -	ldr	x1, [sp, #16]
>  	mov	x20, x0
> -	mov	x21, x1
> +	ldr	x0, [sp, #16]
> +	mov	x21, x0

BTW, some comments to make it easier to review the code later about
what's at [sp, #16].

> +
> +	adrp	x1, _text
> +	add	x1, x1, #:lo12:_text
> +	adrp	x2, _edata
> +	add	x2, x2, #:lo12:_edata
> +	sub	x1, x2, x1
> +
> +	bl	__flush_dcache_area

Looks fine. We also need a "ic ialluis", is any other part of EFI_STUB
invalidating the I-cache?

We need a patch to invalidate the D-cache for areas of memory that the
kernel touches but I'll do this as a separate patch.

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