I contacted the people behind the the Fedora Seure Boot feature and got the following responses, from Peter Jones:
Okay, to be honest I don't remember much about Xen's layout - dom0 is the management kernel the hypervisor starts? So, depending on how xen works, there are probably more things that need to be done in the hypervisor than in the kernel, because the hypervisor is the part that does most physical memory accesses, and that's where there's a worry about faking SB=0 and launching windows.
At the very least, the hypervisor will a) need to be an efi binary, and b) need to be signed with the fedora kernel-signing key. It may also need to be audited for any command line options that allow physical memory access or other similar things, analogous to Matthew's kernel patch for linux.
We're still working out with rel-eng how getting things signed with that is going to work. I don't think there's really any necessity that it's announced in a proper Feature, but if you feel like going that way, that's fine too.
and from Matthew Garrett:
Right. We can conceivably sign Xen as long as it's an EFI binary, but I'd expect that it would have to enforce secure boot itself using the host databases.
------
So we need to get xen working with EFI, to lock xen down so it can't be used to get around Secure Boot, and probably need to do some enforcement of secure boot as well.
Michael Young
On Sat, Jul 14, 2012 at 12:50:35PM +0100, M A Young wrote:
I contacted the people behind the the Fedora Seure Boot feature and got the following responses, from Peter Jones:
Thanks for doing this!
Okay, to be honest I don't remember much about Xen's layout - dom0 is the management kernel the hypervisor starts? So, depending on how xen works, there are probably more things that need to be done in the hypervisor than in the kernel, because the hypervisor is the part that does most physical memory accesses, and that's where there's a worry about faking SB=0 and launching windows.
At the very least, the hypervisor will a) need to be an efi binary, and b) need to be signed with the fedora kernel-signing key. It may also need to be audited for any command line options that allow physical memory access or other similar things, analogous to Matthew's kernel patch for linux.
We're still working out with rel-eng how getting things signed with that is going to work. I don't think there's really any necessity that it's announced in a proper Feature, but if you feel like going that way, that's fine too.
and from Matthew Garrett:
Right. We can conceivably sign Xen as long as it's an EFI binary, but I'd expect that it would have to enforce secure boot itself using the host databases.
So we need to get xen working with EFI, to lock xen down so it can't be used to get around Secure Boot, and probably need to do some enforcement of secure boot as well.
I think you already know this, but Suse guys (Jan) made xen.efi working, the patches are in xen-unstable (so in upcoming Xen 4.2), and they've backported the efi patches to Xen 4.1 in SLES11SP2, and also Suse's (traditional) Linux 3.0 dom0 kernel has some patches for EFI.
-- Pasi
On Mon, Jul 16, 2012 at 10:11:50AM +0300, Pasi Kärkkäinen wrote:
On Sat, Jul 14, 2012 at 12:50:35PM +0100, M A Young wrote:
I contacted the people behind the the Fedora Seure Boot feature and got the following responses, from Peter Jones:
Thanks for doing this!
Okay, to be honest I don't remember much about Xen's layout - dom0 is the management kernel the hypervisor starts? So, depending on how xen works, there are probably more things that need to be done in the hypervisor than in the kernel, because the hypervisor is the part that does most physical memory accesses, and that's where there's a worry about faking SB=0 and launching windows.
At the very least, the hypervisor will a) need to be an efi binary, and b) need to be signed with the fedora kernel-signing key. It may also need to be audited for any command line options that allow physical memory access or other similar things, analogous to Matthew's kernel patch for linux.
We're still working out with rel-eng how getting things signed with that is going to work. I don't think there's really any necessity that it's announced in a proper Feature, but if you feel like going that way, that's fine too.
and from Matthew Garrett:
Right. We can conceivably sign Xen as long as it's an EFI binary, but I'd expect that it would have to enforce secure boot itself using the host databases.
So we need to get xen working with EFI, to lock xen down so it can't be used to get around Secure Boot, and probably need to do some enforcement of secure boot as well.
I think you already know this, but Suse guys (Jan) made xen.efi working, the patches are in xen-unstable (so in upcoming Xen 4.2), and they've backported the efi patches to Xen 4.1 in SLES11SP2, and also Suse's (traditional) Linux 3.0 dom0 kernel has some patches for EFI.
<nods> I think MA Young already has an Xen 4.2 RPM - so the functionality for that is there. It is just the matter of compiling it with a GCC compiler that can do PE.
Then there is the Linux upstream kernel thing. Daniel Kiper has volunteered to look at this - but his schedule is a bit busy with kexec upstreaming.
I've no idea what 'enforce secure boot itself using the host database' means. It probably means making some extra EFI calls maybe?
On Mon, 16 Jul 2012, Konrad Rzeszutek Wilk wrote:
<nods> I think MA Young already has an Xen 4.2 RPM - so the functionality for that is there. It is just the matter of compiling it with a GCC compiler that can do PE.
I got it to build (in x86_64) with a fair amount of hacking as the xen code assumes you have binutils that will handle ELF and PE and Fedora's doesn't. There are some temporary rpms at http://koji.fedoraproject.org/koji/taskinfo?taskID=4245256 though they need a lot of tidying up for proper use and I have no idea if they actually work.
Michael Young
On Tue, Jul 17, 2012 at 01:14:14AM +0100, M A Young wrote:
On Mon, 16 Jul 2012, Konrad Rzeszutek Wilk wrote:
<nods> I think MA Young already has an Xen 4.2 RPM - so the functionality for that is there. It is just the matter of compiling it with a GCC compiler that can do PE.
I got it to build (in x86_64) with a fair amount of hacking as the xen code assumes you have binutils that will handle ELF and PE and Fedora's doesn't. There are some temporary rpms at http://koji.fedoraproject.org/koji/taskinfo?taskID=4245256 though they need a lot of tidying up for proper use and I have no idea if they actually work.
Does anyone know when Fedora will get PE capable binutils?
-- Pasi
On Sat, 2012-07-14 at 12:50 +0100, M A Young wrote:
I contacted the people behind the the Fedora Seure Boot feature and got the following responses, from Peter Jones:
Wow, cool, thanks a lot!
Okay, to be honest I don't remember much about Xen's layout - dom0 is the management kernel the hypervisor starts? So, depending on how xen works, there are probably more things that need to be done in the hypervisor than in the kernel, because the hypervisor is the part that does most physical memory accesses, and that's where there's a worry about faking SB=0 and launching windows.
At the very least, the hypervisor will a) need to be an efi binary, and b) need to be signed with the fedora kernel-signing key. It may also need to be audited for any command line options that allow physical memory access or other similar things, analogous to Matthew's kernel patch for linux.
As others have said, all the above should or will be fine, I guess.
The only thing that comes to my mind is PCI passthrough, as it probably could be thought at something allowing physical memory accesses... Or is the control Xen/qemu provides over it sufficient? (Again, I think the same could apply to KVM, right?).
Thanks again and Regards, Dario
On Tue, Jul 17, 2012 at 03:45:02PM +0200, Dario Faggioli wrote:
On Sat, 2012-07-14 at 12:50 +0100, M A Young wrote:
I contacted the people behind the the Fedora Seure Boot feature and got the following responses, from Peter Jones:
Wow, cool, thanks a lot!
Okay, to be honest I don't remember much about Xen's layout - dom0 is the management kernel the hypervisor starts? So, depending on how xen works, there are probably more things that need to be done in the hypervisor than in the kernel, because the hypervisor is the part that does most physical memory accesses, and that's where there's a worry about faking SB=0 and launching windows.
At the very least, the hypervisor will a) need to be an efi binary, and b) need to be signed with the fedora kernel-signing key. It may also need to be audited for any command line options that allow physical memory access or other similar things, analogous to Matthew's kernel patch for linux.
As others have said, all the above should or will be fine, I guess.
The only thing that comes to my mind is PCI passthrough, as it probably could be thought at something allowing physical memory accesses... Or is the control Xen/qemu provides over it sufficient? (Again, I think the same could apply to KVM, right?).
Right, and also kexec for example. There is code loaded from userspace binary into the kernel to deal with a crashed kernel. Its called purgatory code.
What I am not clear is how far the "chain of trust" needs to go - b/c this also would imply module signing - which is right now _not_ in the upstream kernel.
On Tue, 2012-07-17 at 11:33 -0400, Konrad Rzeszutek Wilk wrote:
The only thing that comes to my mind is PCI passthrough, as it probably could be thought at something allowing physical memory accesses... Or is the control Xen/qemu provides over it sufficient? (Again, I think the same could apply to KVM, right?).
Right, and also kexec for example. There is code loaded from userspace binary into the kernel to deal with a crashed kernel. Its called purgatory code.
I see.
What I am not clear is how far the "chain of trust" needs to go - b/c this also would imply module signing - which is right now _not_ in the upstream kernel.
It sure does, and in fact, module signing figures in the (still drafted) Fedora's plan: http://mjg59.dreamwidth.org/12368.html ("Signed modules are obviously troubling from a user perspective. We'll be signing all the drivers that we ship [...]").
The X server is also mentioned there, so I guess qemu (it open /dev/mem as root after all, doesn't it?) could be a candidate either? :-O
Thanks and Regards, Dario
On Tue, Jul 17, 2012 at 05:55:19PM +0200, Dario Faggioli wrote:
On Tue, 2012-07-17 at 11:33 -0400, Konrad Rzeszutek Wilk wrote:
The only thing that comes to my mind is PCI passthrough, as it probably could be thought at something allowing physical memory accesses... Or is the control Xen/qemu provides over it sufficient? (Again, I think the same could apply to KVM, right?).
Right, and also kexec for example. There is code loaded from userspace binary into the kernel to deal with a crashed kernel. Its called purgatory code.
I see.
What I am not clear is how far the "chain of trust" needs to go - b/c this also would imply module signing - which is right now _not_ in the upstream kernel.
It sure does, and in fact, module signing figures in the (still drafted) Fedora's plan: http://mjg59.dreamwidth.org/12368.html ("Signed modules are obviously troubling from a user perspective. We'll be signing all the drivers that we ship [...]").
The X server is also mentioned there, so I guess qemu (it open /dev/mem as root after all, doesn't it?) could be a candidate either? :-O
Right, if you follow that logic, then v86d needs to be signed.
I am not sure about the Xen toolstack - it makes ioctl calls in /dev/xen/privcmd so that the kernel alters the underlaying PFNs to point to the guest memory. Should those be signed too? Not really sure what the criteria is for signing something when it comes to doing guest operations.
I would think not, b/c what you are doing is an up-call. And the up-call is verified by a trusted agent (kernel). Then the kernel makes a hypercall up-call to a another truested agent (hypervisor), and then the hypervisor does it stuff.
If we were divergent from this chain of operation and muddling with /dev/mem or some other non-inspected method then perhaps we should have sign the binary?
Thought from an attack perspective - what if I made a little C code that did the ioctls, openned a window to a guest and injected some binary blob (virus). Obviously it needs to run as root, so if I find an exploit and run it I can do that. Hmm, so if we the ioctl (privcmd) check the signature of the program to always be on the matching signature list (so only libxenguest or xl or whatever has the ELF signature part) then we can thwart that attach vector. Then we "only" need to worry about possible exploits in 'xl'.
But if this the train of thinking, then it would seem like you need to have signatures for every application that does any type of ioctls. So you would need to sign 'fdisk', 'vim', 'sysctl'.. ? And if you tried to run your own compiled 'fdisk' you wouldn't be able to, unless you get your own self-signed key in the key repo or get the $99 cert and start signging the binaries after compiling.
Or perhaps I am thinking way too much? This doesn't seem any different than TPM / tboot and its chain of trust concept. Except that those stopped with the kernel and modules I believe.
Thanks and Regards, Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
On Tue, 17 Jul 2012, Konrad Rzeszutek Wilk wrote:
On Tue, Jul 17, 2012 at 03:45:02PM +0200, Dario Faggioli wrote:
On Sat, 2012-07-14 at 12:50 +0100, M A Young wrote:
I contacted the people behind the the Fedora Seure Boot feature and got the following responses, from Peter Jones:
Wow, cool, thanks a lot!
Okay, to be honest I don't remember much about Xen's layout - dom0 is the management kernel the hypervisor starts? So, depending on how xen works, there are probably more things that need to be done in the hypervisor than in the kernel, because the hypervisor is the part that does most physical memory accesses, and that's where there's a worry about faking SB=0 and launching windows.
At the very least, the hypervisor will a) need to be an efi binary, and b) need to be signed with the fedora kernel-signing key. It may also need to be audited for any command line options that allow physical memory access or other similar things, analogous to Matthew's kernel patch for linux.
As others have said, all the above should or will be fine, I guess.
The only thing that comes to my mind is PCI passthrough, as it probably could be thought at something allowing physical memory accesses... Or is the control Xen/qemu provides over it sufficient? (Again, I think the same could apply to KVM, right?).
Right, and also kexec for example. There is code loaded from userspace binary into the kernel to deal with a crashed kernel. Its called purgatory code.
What I am not clear is how far the "chain of trust" needs to go - b/c this also would imply module signing - which is right now _not_ in the upstream kernel.
The rawhide kernels have a big modsign patch (plus a fix) which seems to be from the modsign repo http://git.kernel.org/?p=linux/kernel/git/dhowells/linux-modsign.git;a=summa...
Michael Young