[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131204224447.GA19265@srcf.ucam.org>
Date: Wed, 4 Dec 2013 22:44:47 +0000
From: Matthew Garrett <mjg59@...f.ucam.org>
To: Matt Sealey <neko@...uhatsu.net>
Cc: Leif Lindholm <leif.lindholm@...aro.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, linux-efi@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Russell King <linux@....linux.org.uk>, matt.fleming@...el.com,
Grant Likely <grant.likely@...aro.org>,
Roy Franz <roy.franz@...aro.org>,
Mark Salter <msalter@...hat.com>,
Patch Tracking <patches@...aro.org>,
linaro-uefi@...ts.linaro.org, Mark Rutland <mark.rutland@....com>,
Rob Landley <rob@...dley.net>, linux-doc@...r.kernel.org
Subject: Re: [PATCH v3 1/3] Documentation: arm: add UEFI support
documentation
On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote:
> there's no guarantee that the kernel hasn't been decompressed over
> some important UEFI feature or some memory hasn't been trashed. You
> can't make that guarantee because by entering the plain zImage, you
> forfeited that information.
The stub is responsible for ensuring that the compressed kernel is
loaded at a suitable address. Take a look at efi_relocate_kernel().
> Most of the guessing is ideally not required to be a guess at all, the
> restrictions are purely to deal with the lack of trust for the
> bootloader environment. Why can't we trust UEFI? Or at least hold it
> to a higher standard. If someone ships a broken UEFI, they screw a
> feature or have a horrible bug and ship it, laud the fact Linux
> doesn't boot on it and the fact that it's their fault - over their
> head. It actually works these days, Linux actually has "market share,"
> companies really go out of their way to rescue their "image" and
> resolve the situation when someone blogs about a serious UEFI bug on
> their $1300 laptops, or even $300 tablets.
Yeah, that hasn't actually worked out too well for us.
--
Matthew Garrett | mjg59@...f.ucam.org
--
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