xen-devel.lists.xenproject.org archive mirror
 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 15:48:03 +0000	[thread overview]
Message-ID: <50F81D33.9030200@eu.citrix.com> (raw)
In-Reply-To: <50F8270902000078000B6E48@nat28.tlf.novell.com>

On 17/01/13 15:30, Jan Beulich wrote:
>>>> On 17.01.13 at 15:32, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>> On 17/01/13 14:15, Jan Beulich wrote:
>>>> As I understood it, the Ubuntu bootloader will not require an image to
>>>> be signed to boot.
>>> Yes - the plan is to decide whether booting securely by picking
>>> to boot with or without the shim. All layers above have to
>>> react accordingly. However, it is my understanding that if you
>>> use the shim and your kernel isn't signed, boot will fail.
>> My understanding was that Ubuntu's shim will load Ubuntu's signed
>> bootloader; and the bootloader will load either signed or unsigned
>> kernels.  If the kernel is signed, it will (as I understand it) leave
>> boot services on so that the kernel can use them, leaving the kernel to
>> turn them off.
> I think it's slightly different: The shim will only load signed kernels,
> but the same kernel can be loaded directly by EFI or the boot
> loader to boot non-securely.
> As to boot services - in the native case it's always the kernel to
> turn them off; in the Xen case it's always Xen.
> Again, no. Boot services are meaningless to the Dom0 kernel
> when run under Xen.

You are suggesting that Ubuntu only signed their kernels so that someone 
can use the EFI boot menu to boot shim + Ubuntu kernel?

 From what I undertstood from the discussion at the Ubuntu Developer 
Summit, you are wrong.  I may have misunderstood, but it seemed pretty 
clear to me at the time that:

* Ubuntu, and most of the distros, are trying to avoid having the user 
do anything through the native EFI menu.  This is because the EFI menu 
will be implemented differently by each different motherboard 
manufacturer -- making it impossible to provide any kind of reasonable 
instructions on how to do anything.  Furthermore, there's every 
possibility that the EFI user interface for adding new keys will be 
quirky, difficult (e.g., type in the key long-hand), or just plain 
buggy.  For that reason, they are still planning on using software 
bootloaders (like grub) by default, and also planning on providing ways 
to add keys without using the EFI menu.

Therefore, the plan as I understood it from the EFI session at UDS was 
as follows:

* Ubuntu has their own shim which will enforce signatures
* Ubuntu plans on having the shim always load a bootloader (with a more 
full-featured menu which is under Ubuntu's control, as opposed to the 
EFI menu, which will be different for each platform)
* The bootloader will load either signed or unsigned kernel images
* Ubuntu will still be signing their kernel images, however, because:
* The bootloader will turn off boot services for unsigned images, but 
will leave boot services on for signed images, so that
* The signed kernel binaries can do *other* things with boot services 
besides booting.  I don't know the details of this but I think it had to 
do with making it possible for users to add their own keys in a 
consistent manner (rather than using the platform interface, which will 
be different for each OEM).

Therefore, if we want Ubuntu+Xen to have the same functionality as 
Ubuntu w/o Xen, then:
* When the dom0 kernel is signed, Xen will need to leave boot-time 
services enabled
* dom0 will need to have hooks so that it can access boot-time services 
and then disable them.

  -George

  reply	other threads:[~2013-01-17 15:48 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 [this message]
2013-01-17 16:04                 ` George Dunlap
2013-01-17 16:20                   ` Jan Beulich
2013-01-17 17:22                     ` George Dunlap
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=50F81D33.9030200@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 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).