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]

Date:	Wed, 19 Mar 2014 10:57:06 +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 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.

Another aspect in the booting document is that we require any external
cache to be disabled. I think on ARMv8 with a more transparent external
cache we can relax this (Applied's SoC already does this). Otherwise,
since external cache enabling is usually a secure operation, we would
need some SoC specific code just for this early during boot and I'd like
to avoid it.

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