linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mjg59@srcf.ucam.org (Matthew Garrett)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/3] Documentation: arm: add UEFI support documentation
Date: Wed, 4 Dec 2013 22:44:47 +0000	[thread overview]
Message-ID: <20131204224447.GA19265@srcf.ucam.org> (raw)
In-Reply-To: <CAHCPf3tsWdV+dJGm6mX6N4Ou5EQoGukdLyRvsRX6VQFjtKgxtg@mail.gmail.com>

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 at srcf.ucam.org

  parent reply	other threads:[~2013-12-04 22:44 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-28 16:41 [PATCH v3 0/3] (U)EFI runtime services for arm Leif Lindholm
     [not found] ` < 20131129115319.GC11775@console-pimps.org>
     [not found] ` < 1385656883-4420-2-git-send-email-leif.lindholm@linaro.org>
     [not found]   ` < CAHCPf3t5dEzVWbYZ6DWcFCENNO2dbrx-YeZvKRk0MkEsJMTE3A@mail.gmail.com>
     [not found]     ` < 20131202210719.GQ24997@rocoto.smurfnet.nu>
     [not found]       ` < CAHCPf3tsWdV+dJGm6mX6N4Ou5EQoGukdLyRvsRX6VQFjtKgxtg@mail.gmail.com>
     [not found]         ` < 20131204224447.GA19265@srcf.ucam.org>
     [not found]           ` < CAHCPf3s_SXYXLRwvn7tzqTCQ-gB=emRMK_dXkEmw_HWigiD7Mw@mail.gmail.com>
     [not found]             ` < 20131210123035.D1586C40A27@trevor.secretlab.ca>
2013-11-28 16:41 ` [PATCH v3 1/3] Documentation: arm: add UEFI support documentation Leif Lindholm
2013-12-02 19:51   ` Matt Sealey
2013-12-02 21:07     ` Leif Lindholm
2013-12-04 21:06       ` Matt Sealey
2013-12-04 22:31         ` Mark Salter
2013-12-04 22:44         ` Matthew Garrett [this message]
2013-12-06 17:20           ` Matt Sealey
2013-12-10 12:30             ` Grant Likely
2013-12-10 18:29               ` Roy Franz
2013-12-10 22:42                 ` Grant Likely
2013-12-05 11:08         ` Grant Likely
2013-12-05 12:58         ` Leif Lindholm
2013-12-05 10:55     ` Grant Likely
2013-12-05 11:16   ` Grant Likely
2013-11-28 16:41 ` [PATCH v3 2/3] arm: Add [U]EFI runtime services support Leif Lindholm
2013-11-29 16:10   ` Will Deacon
2013-11-29 17:43     ` Leif Lindholm
2013-12-06 12:20       ` Will Deacon
2013-12-05 11:59   ` Grant Likely
2013-12-06  1:59   ` Arnd Bergmann
2013-12-06 17:54     ` Leif Lindholm
2013-12-06 17:59       ` Arnd Bergmann
2013-11-28 16:41 ` [PATCH v3 3/3] init: efi: arm: enable (U)EFI runtime services on arm Leif Lindholm
2013-12-05 12:03   ` Grant Likely
2013-11-29 11:53 ` [PATCH v3 0/3] (U)EFI runtime services for arm Matt Fleming
2013-11-29 17:58   ` Leif Lindholm
2013-12-05 12:04     ` Grant Likely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131204224447.GA19265@srcf.ucam.org \
    --to=mjg59@srcf.ucam.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).