All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: Xen 4.3 development update, and stock-taking
Date: Thu, 17 Jan 2013 17:22:49 +0000	[thread overview]
Message-ID: <50F83369.3060607@eu.citrix.com> (raw)
In-Reply-To: <50F832D802000078000B6EE6@nat28.tlf.novell.com>

On 17/01/13 16:20, Jan Beulich wrote:
> But there might be some fundamental understanding issue here:
> I take it that it is not a property of a system whether one wants
> secure boot, but a request of the owner of the system. If (s)he
> wants to boot securely, then of course anything that isn't signed
> doesn't even get loaded. If (s)he wants to boot "normally", the
> shim gets left out of the picture, and off we go. But maybe I'm
> wrong with that?

As I understand it, the whole reason Fedora and Ubuntu are going through 
this whole hassle with secure boot is:
* Microsoft requires a system to ship w/ secure boot enabled to get "MS 
Certified" for Windows 8
* The vast majority of desktop systems will be shipping with Windows 8, 
and so will want to be certified
* Therefore the vast majority of desktop systems will ship w/ secure 
boot enabled
* MS requires that secure boot be able to be disabled; however
* Each EFI system will be different, so it will be impossible to provide 
instructions on how to do so
* Furthermore many EFI systems may be buggy, so it may still not be 
possible to disable EFI

So the vast majority of desktop systems, saying that secure boot was "a 
request of the owner of the system" is false.  They didn't ask for it to 
be turned on, and it may be difficult or impossible to turn off.

  -George

  reply	other threads:[~2013-01-17 17:22 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-16 17:55 Xen 4.3 development update, and stock-taking George Dunlap
2013-01-16 18:03 ` Matthew Fioravante
2013-01-18 15:19   ` Konrad Rzeszutek Wilk
2013-01-18 21:17     ` Fioravante, Matthew E.
2013-01-16 18:15 ` Wei Liu
2013-01-17 10:50   ` George Dunlap
2013-01-17  9:09 ` Jan Beulich
2013-01-17 11:12   ` George Dunlap
2013-01-17 12:51     ` Jan Beulich
2013-01-17 13:58       ` George Dunlap
2013-01-17 14:15         ` Jan Beulich
2013-01-17 14:32           ` George Dunlap
2013-01-17 15:26             ` Jan Beulich
2013-01-17 15:30             ` Jan Beulich
2013-01-17 15:48               ` George Dunlap
2013-01-17 16:04                 ` George Dunlap
2013-01-17 16:20                   ` Jan Beulich
2013-01-17 17:22                     ` George Dunlap [this message]
2013-01-17 16:14                 ` Jan Beulich
2013-01-17 16:29                   ` George Dunlap
2013-01-17 16:49                     ` Jan Beulich
2013-01-17 17:11                       ` George Dunlap
2013-01-18  9:35                         ` Jan Beulich
2013-01-17 16:43                   ` George Dunlap
2013-01-17 17:06                     ` Jan Beulich
2013-01-17 16:49                   ` George Dunlap
2013-01-18  9:30                     ` Jan Beulich
2013-01-18 15:24       ` Konrad Rzeszutek Wilk
2013-01-18 11:20     ` Daniel Kiper
2013-01-21 14:12       ` George Dunlap
2013-01-22 13:53         ` Daniel Kiper
2013-01-22 14:10           ` Jan Beulich
2013-01-18 15:22   ` Konrad Rzeszutek Wilk
2013-01-17 10:00 ` Roger Pau Monné
2013-01-17 11:22   ` George Dunlap
2013-01-18  9:50     ` Roger Pau Monné
2013-01-18 15:21       ` Konrad Rzeszutek Wilk
2013-01-18 15:33         ` Roger Pau Monné
2013-01-21 15:06       ` George Dunlap
2013-01-17 10:20 ` Olaf Hering
2013-01-17 17:23   ` George Dunlap
2013-01-17 15:54 ` Daniel De Graaf
2013-01-17 15:49   ` George Dunlap
2013-01-18 15:41 ` Konrad Rzeszutek Wilk
2013-01-21 15:04   ` George Dunlap
2013-01-22 17:42     ` Konrad Rzeszutek Wilk
     [not found] <mailman.21508.1358358967.1399.xen-devel@lists.xen.org>
2013-01-17 16:07 ` Andres Lagar-Cavilla
  -- strict thread matches above, loose matches on Subject: below --
2013-01-22 14:32 Daniel Kiper

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=50F83369.3060607@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.