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 14:32:53 +0000	[thread overview]
Message-ID: <50F80B95.3010005@eu.citrix.com> (raw)
In-Reply-To: <50F815AC02000078000B6DC2@nat28.tlf.novell.com>

On 17/01/13 14:15, Jan Beulich wrote:
>> Just to be clear here: are you saying that there is no way to boot 
>> Xen directly from EFI with a pvops kernel? if so, that seems like a 
>> pretty big deal to me... 
> It depends on the system: Those ones where legacy methods still
> allow finding namely ACPI tables would allow booting. On ones
> where those tables can be found only by consulting EFI, booting
> is possible, but you'd generally end up without PCI interrupts
> (which to me is almost the same as "doesn't boot").

OK; so we're talking about different things.  I'm talking about 1) can 
the binary be loaded into memory by EFI bootloaders 2) can dom0 access 
EFI runtime services.  You're talking about "can it boot", which 
minimally requires 1, and on some systems (i.e., systems that do not 
provide appropriate ACPI tables) also requires 2.

So we already have #1 for both xenlinux and pvops; we just need #2. Is 
that correct?

>>>> * Xen able to detect the existence of a signed Linux binary, and leave
>>>> EFI boot-time services enabled for dom0 to use when appropriate
>>> No. We can't leave bot services enabled, and we also don't
>>> need to. The model is that only the Dom0 kernel binary needs
>>> validation at the boot loader level. Everything else will be
>>> done in the kernel (including initrd validation, or really the
>>> parts of it that need validation).
>> 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.

>>   Nonetheless, Ubuntu are still signing their kernel
>> images, because they want the kernel to be able to play some fancy
>> tricks for which they need boot-time services.  (I think this is
>> something to do with making it easy to upload your own keys.) Full EFI
>> functionality for Xen would include the ability to do this as well.
> Yes, because you particularly need access to the EFI variables
> from the kernel. Which in turn requires an EFI-enabled kernel.

I'm responding to what you said above:  "No.  We can't leave [boot] 
services enabled, and we don't need to."  If we want the dom0 kernel to 
be able to use boot-time services, to enable whatever features Ubuntu &c 
are using them for, then yes, we will need to leave boot services 
enabled until dom0 is done using them.

But we should only do that if 1) EFI services are enabled but Xen wasn't 
signed (i.e,. SecureBoot disabled), or 2) both Xen and dom0 are signed.

  -George

  reply	other threads:[~2013-01-17 14:32 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 [this message]
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
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=50F80B95.3010005@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).