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:	Tue, 18 Mar 2014 16:21:05 -0600
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Roy Franz <roy.franz@...aro.org>
Cc:	Mark Salter <msalter@...hat.com>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Catalin Marinas <catalin.marinas@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Leif Lindholm <leif.lindholm@...aro.org>,
	"matt.fleming@...el.com" <matt.fleming@...el.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 11/15] arm64: add EFI stub

On Tue, Mar 18, 2014 at 02:48:30PM -0700, Roy Franz wrote:

> > 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 looked at the UEFI spec and there is no mention of cache flushing
> in ExitBootServices(), so it seems it is up to the OS to do any
> cache management.

Something to think about: On mvebu we recently confirmed a situation
where turning off the L1 cache is not sufficient for booting. The L2
cache must also be completely off and disabled prior to jumping in to
the kernel.

The issue is the decompressor turns the L1 cache back on, and if the
L2 is also enabled at this point then it gets filled with
decompression data. Things go wrong from here because after
decompression the L1 dcache is switched off, but the L2 isn't
flush-invalidated.

So now the L2 holds writeback data and uncached reads return garbage,
and/or the L2 misses the uncached writes (eg relocation fixup) and
becomes inconsistent with memory. Either case gives a black screen
crash at boot.

Fundementally if the L2 doesn't monitor uncached read/writes then it
will cause a big problem.

Thus, if the UEFI calls the sub with the caches on, and the stub
doesn't know enough to turn off the L2 then you might not be able to
turn the dcache off at all. :(

On ARM64 at least the L1 cache ops are standardized so maybe ARM64
could keep the mmu+caches enabled during boot and do the L1
d-flush/i-inval required for instruction coherency?

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