So while doing a bit of investigation into a request that we have instructions for how to sign a Xen binary, I came across a related pair of questions. If we boot from a signed Xen binary, then: 1. Will Xen then successfully boot a signed dom0 kernel / initrd? 2. Will Xen fail to boot an unsigned dom0 kernel / initrd? I think if Xen is signed, then ideally we want both 1 and 2 to be true, right? Does UEFI provide a way to check the signature of files? Does it happen automatically, or would we need to add extra support? Or would we need to embed a public key within the Xen binary and have Xen check the signatures of files that it reads? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 26/11/12 17:57, George Dunlap wrote:> So while doing a bit of investigation into a request that we have > instructions for how to sign a Xen binary, I came across a related > pair of questions. If we boot from a signed Xen binary, then: > 1. Will Xen then successfully boot a signed dom0 kernel / initrd? > 2. Will Xen fail to boot an unsigned dom0 kernel / initrd? > > I think if Xen is signed, then ideally we want both 1 and 2 to be > true, right? Does UEFI provide a way to check the signature of > files? Does it happen automatically, or would we need to add extra > support? Or would we need to embed a public key within the Xen binary > and have Xen check the signatures of files that it reads? > > -GeorgeThe problem is deeper than that. The idea of secure boot is that only signed/verified code can perform privileged operations. One can argue as to exactly where this boundary lies, but in the native case, it contains any kernel level code. Userspace uses the kernel API/ABI subject to the permissions checks present and (assuming no security holes), everyone is happy. In the Xen case, Xen will happily accept any privileged hypercalls from dom0. So you could argue that anything able to make ioctls against /dev/xen/privcmd (and friends) would need to be within the signed code. This is the entire toolstack, and all root processes. Furthermore, cross-domain systems like xenbus/xenstore would also need to be signed. Imagine the carnage a malicious xenstored could cause! I am struggling to think of a way of getting secure boot working correctly without signing all of dom0. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com
On Mon, 26 Nov 2012, George Dunlap wrote:> So while doing a bit of investigation into a request that we have instructions for how to sign a Xen binary, I came across a related pair of questions. If we > boot from a signed Xen binary, then: > 1. Will Xen then successfully boot a signed dom0 kernel / initrd? > 2. Will Xen fail to boot an unsigned dom0 kernel / initrd? > > I think if Xen is signed, then ideally we want both 1 and 2 to be true, right?I think that you are right _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Mon, 26 Nov 2012 20:12:04 +0000 Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:> On Mon, 26 Nov 2012, George Dunlap wrote: > > So while doing a bit of investigation into a request that we have instructions for how to sign a Xen binary, I came across a related pair of questions. If we > > boot from a signed Xen binary, then: > > 1. Will Xen then successfully boot a signed dom0 kernel / initrd? > > 2. Will Xen fail to boot an unsigned dom0 kernel / initrd? > > > > I think if Xen is signed, then ideally we want both 1 and 2 to be true, right? > > I think that you are rightI think you''d have to be out of your tree to try and sign Xen itself using the MS setup - assuming you can ever get a key and get it to work which seems to be an issue of its own. You want to sign a small bootloader that is tightly auditable and do your own key management within that for anything else. I would think you''d be able to make use of the Linux bootloader work. Better yet would be to take the entire sorry EFI and ''secure'' boot mess and kick it where the sun won''t shine but alas that may be a challenge until the PC manufacturers realise they can''t handle the support costs of things in the current state and fix it.
>>> On 26.11.12 at 18:57, George Dunlap <dunlapg@umich.edu> wrote: > So while doing a bit of investigation into a request that we have > instructions for how to sign a Xen binary, I came across a related pair of > questions. If we boot from a signed Xen binary, then: > 1. Will Xen then successfully boot a signed dom0 kernel / initrd? > 2. Will Xen fail to boot an unsigned dom0 kernel / initrd? > > I think if Xen is signed, then ideally we want both 1 and 2 to be true, > right? Does UEFI provide a way to check the signature of files? Does it > happen automatically, or would we need to add extra support? Or would we > need to embed a public key within the Xen binary and have Xen check the > signatures of files that it reads?I don''t have any answers to these questions yet; as we need to do this for our upcoming SLE11 SP3, I''m expecting our EFI and/or kernel folks to come forward with an outline of what needs to be done (and ideally with an implementation in the boot loader) that I could then just clone for the Xen code. I had expected that to happen already, but it''s apparently not making enough progress (or the progress is not visible to me). Jan
On Mon, Nov 26, 2012 at 9:51 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:> I think you''d have to be out of your tree to try and sign Xen itself > using the MS setup - assuming you can ever get a key and get it to work > which seems to be an issue of its own. >> You want to sign a small bootloader that is tightly auditable and do your > own key management within that for anything else. I would think you''d be > able to make use of the Linux bootloader work. >I was thinking of people who wanted to install their own keys. Some people think that since you have EFI you shouldn''t need a bootloader. :-) But you''re right, I think on the whole the critical thing is just to make sure that "secure" bootloaders from distros know how to load signed Xen / Linux images. Booting Xen directly is probably going to be a bit niche. That said, I''m sure there are people who will want to do it, so it probably should be on our "to-do" list.> > Better yet would be to take the entire sorry EFI and ''secure'' boot mess > and kick it where the sun won''t shine but alas that may be a challenge > until the PC manufacturers realise they can''t handle the support costs of > things in the current state and fix it. >I''m not sure the vendors have much choice in the matter, as long as a single vendor controls the majority of the market and can dictate terms. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Mon, Nov 26, 2012 at 6:16 PM, Andrew Cooper <andrew.cooper3@citrix.com>wrote:> The idea of secure boot is that only signed/verified code can perform > privileged operations. One can argue as to exactly where this boundary > lies, but in the native case, it contains any kernel level code. > Userspace uses the kernel API/ABI subject to the permissions checks > present and (assuming no security holes), everyone is happy. >Different people have different opinions on this. Fedora are signing all the way down to modules, but not user-space; as a result, IIUC, they are ruling out third-party or out-of-tree drivers. Ubuntu are not signing modules AIUI, so in theory someone could install a rootkit; but they think that it''s likely any local attacker is going to be able to attack the kernel anyway; on the balance having third-party drivers is more important to them. Nonetheless, Ubuntu are still signing kernels, so that the kernel can still do some of the "boot mode" UEFI operations. (Not sure the correct term here.) The idea is that the kernel will disable the "boot mode" UEFI operations before it loads any kernel modules. Someone booting Xen directly from EFI may want to do the same thing. -George> > In the Xen case, Xen will happily accept any privileged hypercalls from > dom0. So you could argue that anything able to make ioctls against > /dev/xen/privcmd (and friends) would need to be within the signed code. > This is the entire toolstack, and all root processes. > > Furthermore, cross-domain systems like xenbus/xenstore would also need > to be signed. Imagine the carnage a malicious xenstored could cause! > > I am struggling to think of a way of getting secure boot working > correctly without signing all of dom0. > > -- > Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer > T: +44 (0)1223 225 900, http://www.citrix.com > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Mon, 2012-11-26 at 18:16 +0000, Andrew Cooper wrote:> On 26/11/12 17:57, George Dunlap wrote: > > So while doing a bit of investigation into a request that we have > > instructions for how to sign a Xen binary, I came across a related > > pair of questions. If we boot from a signed Xen binary, then: > > 1. Will Xen then successfully boot a signed dom0 kernel / initrd? > > 2. Will Xen fail to boot an unsigned dom0 kernel / initrd? > > > > I think if Xen is signed, then ideally we want both 1 and 2 to be > > true, right? Does UEFI provide a way to check the signature of > > files? Does it happen automatically, or would we need to add extra > > support? Or would we need to embed a public key within the Xen binary > > and have Xen check the signatures of files that it reads? > > > > -George > > The problem is deeper than that. > > The idea of secure boot is that only signed/verified code can perform > privileged operations. One can argue as to exactly where this boundary > lies, but in the native case, it contains any kernel level code. > Userspace uses the kernel API/ABI subject to the permissions checks > present and (assuming no security holes), everyone is happy. > > In the Xen case, Xen will happily accept any privileged hypercalls from > dom0. So you could argue that anything able to make ioctls against > /dev/xen/privcmd (and friends) would need to be within the signed code. > This is the entire toolstack, and all root processes.AIUI Restricted Boot doesn''t really concern itself with the integrity of the system post boot, just with the integrity of the bits which are being booted. I think this extends to booting dom0 but anything relating to booting guests could reasonably be considered to be handled separately. Given that it''s very possible that the hypervisor could lock down even dom0 from being able to make calls which would allow the firmware to be subverted (i.e. access to I/O ports or MMIO regions which would allow the BIOS to be reflashed or whatever), at which point dom0 root user and toolstack becomes irrelevant. That probably involves some sort of black/whitelisting scheme for I/O ports and such which is pretty tedious but not overwhelming I don''t think.> Furthermore, cross-domain systems like xenbus/xenstore would also need > to be signed. Imagine the carnage a malicious xenstored could cause!It would need to be able to subvert the bootloader and system firmware or something, which seems like a bit of a stretch.> I am struggling to think of a way of getting secure boot working > correctly without signing all of dom0.Ian.
>>> On 27.11.12 at 10:50, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > On Mon, Nov 26, 2012 at 9:51 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: >> You want to sign a small bootloader that is tightly auditable and do your >> own key management within that for anything else. I would think you''d be >> able to make use of the Linux bootloader work. >> > > I was thinking of people who wanted to install their own keys. Some people > think that since you have EFI you shouldn''t need a bootloader. :-)I think boot loader is the wrong term - shim loader is what our folks use (i.e. just a wrapper to deal with the key problem). That would wrap grub2.efi (or whatever its name) as well as xen.efi or (if someone cares) elilo.efi. Jan
> ruling out third-party or out-of-tree drivers. Ubuntu are not signing > modules AIUI, so in theory someone could install a rootkit; but they thinkThey can anyway. If the kernel has a hole you can just stuff something hidden in early early userspace boot (eg in the initrd) to re-trojan it. Plus the next generation of devices mostly suspend/resume so its hardly that important anyway.> that it''s likely any local attacker is going to be able to attack the > kernel anyway; on the balance having third-party drivers is more important > to them.Don''t be misled into thinking this has anything much to do with security. If you are trying to do security use the TPM and do a trusted measured boot which gives you the keys to the file system which then uses signing of its own.> Nonetheless, Ubuntu are still signing kernelsIn the UEFI sense they are not - nor are Fedora. They are signing a tiny boot loader and implementing their own policy behind that. It''s basically a way around the Windows 8 lock down.
> That probably involves some sort of black/whitelisting scheme for I/O > ports and such which is pretty tedious but not overwhelming I don''t > think.Until you start to think about indirect access via DMA or using one device to set up an I/O window into another, or the ACPI EC or the GPU ... its nigh on impossible. PC hardware isn''t designed for restricted boot. Alan
On Tue, Nov 27, 2012 at 10:51:06AM +0000, George Dunlap wrote:> On Mon, Nov 26, 2012 at 6:16 PM, Andrew Cooper > <[1]andrew.cooper3@citrix.com> wrote: > > The idea of secure boot is that only signed/verified code can perform > privileged operations. One can argue as to exactly where this boundary > lies, but in the native case, it contains any kernel level code. > Userspace uses the kernel API/ABI subject to the permissions checks > present and (assuming no security holes), everyone is happy. > > Different people have different opinions on this. Fedora are signing all > the way down to modules, but not user-space; as a result, IIUC, they are > ruling out third-party or out-of-tree drivers. >Fedora/Redhat are planning to support custom/out-of-tree drivers by allowing the user to install trusted custom signing keys, so you can sign the kernel drivers using those keys. The process was described for example in Matthew Garrett''s UEFI presentation at LinuxCon 2012 NA after XenSummit 2012. Some info: http://mjg59.dreamwidth.org/16863.html: "We''re planning on using Suse''s approach of permitting local key management at the shim level, and I spent some time discussing this with Vojtech last week. In combination with the above, this should provide a workable mechanism for permitting the end-user to install module signing keys." -- Pasi
>>> On 26.11.12 at 18:57, George Dunlap <dunlapg@umich.edu> wrote: > So while doing a bit of investigation into a request that we have > instructions for how to sign a Xen binary, I came across a related pair of > questions. If we boot from a signed Xen binary, then: > 1. Will Xen then successfully boot a signed dom0 kernel / initrd? > 2. Will Xen fail to boot an unsigned dom0 kernel / initrd? > > I think if Xen is signed, then ideally we want both 1 and 2 to be true, > right?Not necessarily: With the shim approach that most people now seem to agree to, it would depend on whether xen.efi actually got loaded directly or through the shim. When loaded through the shim, both ought to be true. If loaded without the shim, whether Xen is signed doesn''t matter, and hence whether the Dom0 kernel image is signed shouldn''t matter either. The grub2 code I just looked at doesn''t verify the initrd btw, that''s apparently left to the kernel.> Does UEFI provide a way to check the signature of files? Does > it happen automatically, or would we need to add extra support? > Or would we need to embed a public key within the Xen binary > and have Xen check the signatures of files that it reads?No, that''s what the shim is actually for - it publishes a suitable, trivial protocol. Adding the verification step has turned out to require 19 added lines, so pretty trivial. I didn''t look into what additional data Dom0 may need access to, yet. Jan
>>> On 28.11.12 at 16:33, "Jan Beulich" <JBeulich@suse.com> wrote: >>>> On 26.11.12 at 18:57, George Dunlap <dunlapg@umich.edu> wrote: >> So while doing a bit of investigation into a request that we have >> instructions for how to sign a Xen binary, I came across a related pair of >> questions. If we boot from a signed Xen binary, then: >> 1. Will Xen then successfully boot a signed dom0 kernel / initrd? >> 2. Will Xen fail to boot an unsigned dom0 kernel / initrd? >> >> I think if Xen is signed, then ideally we want both 1 and 2 to be true, >> right? > > Not necessarily: With the shim approach that most people now > seem to agree to, it would depend on whether xen.efi actually > got loaded directly or through the shim. When loaded through > the shim, both ought to be true. If loaded without the shim, > whether Xen is signed doesn''t matter, and hence whether the > Dom0 kernel image is signed shouldn''t matter either. > > The grub2 code I just looked at doesn''t verify the initrd btw, > that''s apparently left to the kernel. > >> Does UEFI provide a way to check the signature of files? Does >> it happen automatically, or would we need to add extra support? >> Or would we need to embed a public key within the Xen binary >> and have Xen check the signatures of files that it reads? > > No, that''s what the shim is actually for - it publishes a suitable, > trivial protocol. > > Adding the verification step has turned out to require 19 added > lines, so pretty trivial. I didn''t look into what additional data Dom0 > may need access to, yet.So I learned a little more meanwhile - it''s not that trivial: I''m told the shim uses UEFI services to do the verification, and those services only handle PE images. But we obviously can''t reasonably expect the Dom0 kernel to be packaged as PE image, as that would then be unusable as DomU kernel (on older hosts at least, i.e. even if we added a PE loader to libxc). I''m therefore considering to create a PE image from the kernel binary [if compressed, even without uncompressing] on the fly (in memory), and present that to the verification routine. Which requires a way to locate the signature within that binary kernel blob, which would need to be placed there without disturbing the decompression of the image - not sure if that''s possible at all. Jan
On Fri, Nov 30, 2012 at 10:27 AM, Jan Beulich <JBeulich@suse.com> wrote:> So I learned a little more meanwhile - it''s not that trivial: I''m told > the shim uses UEFI services to do the verification, and those > services only handle PE images. But we obviously can''t reasonably > expect the Dom0 kernel to be packaged as PE image, as that > would then be unusable as DomU kernel (on older hosts at least, > i.e. even if we added a PE loader to libxc). >Sorry for the n00b question, but what''s a PE image in this context? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Fri, Nov 30, 2012 at 10:27 AM, Jan Beulich <JBeulich@suse.com> wrote:> > So I learned a little more meanwhile - it''s not that trivial: I''m told > the shim uses UEFI services to do the verification, and those > services only handle PE images. But we obviously can''t reasonably > expect the Dom0 kernel to be packaged as PE image, as that > would then be unusable as DomU kernel (on older hosts at least, > i.e. even if we added a PE loader to libxc). >But what does the shim use to check the signature of Xen in this case? Does Xen / native Linux need to be a PE image to boot from the shim? If not, wouldn''t the native PE image suffice? And if so, why can''t the shim check signatures the same way it checks the sig for the thing it''s booting? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 30/11/12 10:42, George Dunlap wrote:> On Fri, Nov 30, 2012 at 10:27 AM, Jan Beulich <JBeulich@suse.com > <mailto:JBeulich@suse.com>> wrote: > > So I learned a little more meanwhile - it''s not that trivial: I''m told > the shim uses UEFI services to do the verification, and those > services only handle PE images. But we obviously can''t reasonably > expect the Dom0 kernel to be packaged as PE image, as that > would then be unusable as DomU kernel (on older hosts at least, > i.e. even if we added a PE loader to libxc). > > > Sorry for the n00b question, but what''s a PE image in this context?I think this refers to the Microsoft PE (portable executable) file format - that is, the file should be like a .EXE or .DLL on windows. I wish I thought I was wrong here, but I''m afraid that MS solutions are rather popular in some camps... Further searching seems to confirm that PE is indeed "standard format" for EFI. http://en.wikipedia.org/wiki/Portable_Executable -- Mats> > -George >
>>> On 30.11.12 at 11:42, George Dunlap <dunlapg@umich.edu> wrote: > On Fri, Nov 30, 2012 at 10:27 AM, Jan Beulich <JBeulich@suse.com> wrote: > >> So I learned a little more meanwhile - it''s not that trivial: I''m told >> the shim uses UEFI services to do the verification, and those >> services only handle PE images. But we obviously can''t reasonably >> expect the Dom0 kernel to be packaged as PE image, as that >> would then be unusable as DomU kernel (on older hosts at least, >> i.e. even if we added a PE loader to libxc). >> > > Sorry for the n00b question, but what''s a PE image in this context?"Portable Executable", i.e. the binary format used by Windows and EFI for their executables. Jan
>>> On 30.11.12 at 11:56, George Dunlap <dunlapg@umich.edu> wrote: > On Fri, Nov 30, 2012 at 10:27 AM, Jan Beulich <JBeulich@suse.com> wrote: > >> >> So I learned a little more meanwhile - it''s not that trivial: I''m told >> the shim uses UEFI services to do the verification, and those >> services only handle PE images. But we obviously can''t reasonably >> expect the Dom0 kernel to be packaged as PE image, as that >> would then be unusable as DomU kernel (on older hosts at least, >> i.e. even if we added a PE loader to libxc). >> > > But what does the shim use to check the signature of Xen in this case? > Does Xen / native Linux need to be a PE image to boot from the shim?Yes - xen.efi just needs to get a signature implanted for that part to work, and native Linux uses the EFI_STUB mechanism to gets its binary into said format (which then also only needs a signature added).> If > not, wouldn''t the native PE image suffice? And if so, why can''t the shim > check signatures the same way it checks the sig for the thing it''s booting?The checking code only knows to locate signatures inside PE images. Consequently, whatever you want to pass to that code needs to look like one. xen.efi and native Linux with EFI_STUB enabled already do, but if you handed such a kernel binary to either of the two PV domain kernel loaders Xen has, they would just bail. But - now that I checked what I was told, I can''t see the EFI_STUB config option to result in a PE binary to be created. So I''m back to square 1... Jan
>>> On 30.11.12 at 12:23, "Jan Beulich" <JBeulich@suse.com> wrote: > But - now that I checked what I was told, I can''t see the EFI_STUB > config option to result in a PE binary to be created. So I''m back to > square 1...Wait - I looked at the wrong file, it _is_ a PE binary that results. Jan
On Fri, Nov 30, 2012 at 11:23 AM, Jan Beulich <JBeulich@suse.com> wrote:> >>> On 30.11.12 at 11:56, George Dunlap <dunlapg@umich.edu> wrote: > > On Fri, Nov 30, 2012 at 10:27 AM, Jan Beulich <JBeulich@suse.com> wrote: > > > >> > >> So I learned a little more meanwhile - it''s not that trivial: I''m told > >> the shim uses UEFI services to do the verification, and those > >> services only handle PE images. But we obviously can''t reasonably > >> expect the Dom0 kernel to be packaged as PE image, as that > >> would then be unusable as DomU kernel (on older hosts at least, > >> i.e. even if we added a PE loader to libxc). > >> > > > > But what does the shim use to check the signature of Xen in this case? > > Does Xen / native Linux need to be a PE image to boot from the shim? > > Yes - xen.efi just needs to get a signature implanted for that > part to work, and native Linux uses the EFI_STUB mechanism > to gets its binary into said format (which then also only needs a > signature added). > > > If > > not, wouldn''t the native PE image suffice? And if so, why can''t the shim > > check signatures the same way it checks the sig for the thing it''s > booting? > > The checking code only knows to locate signatures inside PE > images. Consequently, whatever you want to pass to that code > needs to look like one. xen.efi and native Linux with EFI_STUB > enabled already do, but if you handed such a kernel binary to > either of the two PV domain kernel loaders Xen has, they would > just bail. >OK... so Fedora and Ubuntu are going to be shipping signed kernel binaries. Are those binaries going to be in PE / EFI format then? If so: 1. You won''t need to do any fancy on-the-fly repackaging in Xen; you can just pass the already-signed distro-supplied binary 2. The toolstack is simply going to have to be able to read PE kernels for PV guests 3. If distros don''t include non-PE kernels, we''re going to have to backport that functionality to older versions of Xen. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>>> On 30.11.12 at 12:34, George Dunlap <dunlapg@umich.edu> wrote: > On Fri, Nov 30, 2012 at 11:23 AM, Jan Beulich <JBeulich@suse.com> wrote: > >> >>> On 30.11.12 at 11:56, George Dunlap <dunlapg@umich.edu> wrote: >> > On Fri, Nov 30, 2012 at 10:27 AM, Jan Beulich <JBeulich@suse.com> wrote: >> > >> >> >> >> So I learned a little more meanwhile - it''s not that trivial: I''m told >> >> the shim uses UEFI services to do the verification, and those >> >> services only handle PE images. But we obviously can''t reasonably >> >> expect the Dom0 kernel to be packaged as PE image, as that >> >> would then be unusable as DomU kernel (on older hosts at least, >> >> i.e. even if we added a PE loader to libxc). >> >> >> > >> > But what does the shim use to check the signature of Xen in this case? >> > Does Xen / native Linux need to be a PE image to boot from the shim? >> >> Yes - xen.efi just needs to get a signature implanted for that >> part to work, and native Linux uses the EFI_STUB mechanism >> to gets its binary into said format (which then also only needs a >> signature added). >> >> > If >> > not, wouldn''t the native PE image suffice? And if so, why can''t the shim >> > check signatures the same way it checks the sig for the thing it''s >> booting? >> >> The checking code only knows to locate signatures inside PE >> images. Consequently, whatever you want to pass to that code >> needs to look like one. xen.efi and native Linux with EFI_STUB >> enabled already do, but if you handed such a kernel binary to >> either of the two PV domain kernel loaders Xen has, they would >> just bail. >> > > OK... so Fedora and Ubuntu are going to be shipping signed kernel > binaries. Are those binaries going to be in PE / EFI format then? If so: > 1. You won''t need to do any fancy on-the-fly repackaging in Xen; you can > just pass the already-signed distro-supplied binary > 2. The toolstack is simply going to have to be able to read PE kernels for > PV guests > 3. If distros don''t include non-PE kernels, we''re going to have to backport > that functionality to older versions of Xen.Looks like our bzImage loader may be able to deal with these (fake) PE images already, so that should then be backwards compatible back to 3.4.2 (DomU loader) and 4.0.0 (Dom0 loader). Good enough, I think. I''ll check next week whether that''s actually true. Jan