RFC Xen signature verification for kexec

RFC Xen signature verification for kexec

[Eric DeVolder]

In reading this and providing feedback, I'm hoping to obtain
community consensus on the following questions:
- Is there interest in this?
- Which approach is favored?
- Are there other approaches/efforts?
- Other concerns/feedback?

Executive Summary
Xen currently lacks signature verification infrastructure which makes
it vulnerable to exploit, even with secure boot mode, such as UEFI.
This proposal outlines a high-level approach to support signature
verification for kexec in Xen.

Option 1: Port Linux signature verification into Xen
Option 2: Enable signature verification in Xen utilizing libgcrypt

Overview
In UEFI secure boot mode, a "root of trust" is established. Typically,
UEFI secure boot verifies a boot loader, e.g. GRUB2, first. Then the
bootloader verifies Xen using the UEFI shim protocol and Xen verifies
the dom0 [Linux] kernel using shim protocol too.  Xen utilizes the
UEFI shim protocol at boot to verify the dom0 kernel.[1]

Thus UEFI can be used to boot into a "trusted" Xen and dom0 kernel.
However, this "trusted" environment is vulnerable to exploit as a dom0
user space application can be utilized to kexec a second, untrusted
kernel.

In the Xen environment, the kexec/kdump solution involves user space
utilities (eg. kexec-tools and makedumpfile), hypervisor support (eg.
xen/common/kexec.c) and post-mortem analysis tools (eg. crash).

Typically, in the Xen environment, the kexec of a second kernel (plus
initrd) is requested by /sbin/kexec binary *directly* invoking the Xen
kexec hypercall (which bypasses dom0) with a data structure pointing
to loadable segments.  Xen then places these segments into memory.
This second kernel is not verified, and the system can be rebooted
into an untrusted kernel.

As it stands today, the Xen hypervisor has no mechanism for signature
verification, and thus can not prevent this exploit.

NOTE: A solution for signature verification in Xen would perhaps also
enable a solution for LivePatch signature checking.


#####
Two options for signature verification in Xen

This proposal outlines two options under consideration for enhancing
Xen to support signature verification of kexec loaded images. The
first option is essentially to mirror Linux signature verification
code into Xen. The second option utilizes components from sources
other than Linux (for example, libgcrypt rather than linux/crypto).

NOTE: An option to utilize dom0 kernel signature verification does not
prevent the exploit as user space can invoke the hypercall directly,
bypassing dom0.

#####
Option 1: Port Linux signature verification into Xen

This option essentially is porting the Linux kexec_file_load()
system call as a new Xen kexec hypercall operation, for example,
KEXEC_CMD_kexec_file_load.

The license of Linux and Xen allow for Xen to take files from Linux
and incorporate into Xen. So in general most of this could be lifted
from Linux and dropped into Xen with the new hypercall op providing a
needed wrapper.

Pros:
- Most of the code already exists in Linux

Cons:
- This could potentially be taking tens of files from Linux and
   placing into Xen (linux/crypto has 115 source files). This
   would be a problematic management scenario going forward with
   uptaking changes in Linux and merging into Xen, and vice versa.

Changes to kexec-tools:
- Changes primarily to do_kexec_file_load():
   - if xen_present()...
     - Read entire file contents into buffer
     - Invoke new hypercall op

Changes to Xen:
- Import linux/crypto, linux/include/crypto, and
   linux/arch/x86/crypto <-- RSA, SHA, PKCS, etc
- Import linux/crypto/asymmetric_keys <-- PE handling
- Import linux/certs  <-- has system_keyring
- Import security/keys <-- key management
- Import various accompanying CONFIG settings
- Implement new hypercall operation,
   patterning after Linux' kexec_file_load(). One
   difference would be that rather than passing
   file handles, Xen would need to be passed pointers
   to the buffer(s) containing the image(s), as Xen
   can not read a file (for second kernel and the
   initrd) from Linux. Xen can access the buffer(s)
   via copy_from_user().

#####
Option 2: Enable signature verification in Xen utilizing libgcrypt

This option is similar to Option 1, but utilizes libgcrypt
crytpo library rather than linux/crypto files.

Pros:
- Libgcrypt is LGPLv2.1+ license.
- Eliminates problematic scenario of tracking changes to
   linux/crypto sources in Xen, and vice versa in Linux.

Cons:
- Introduces a dependency on libgcrypt
- Still relying on lifting many Linux kernel sources for PE file
   handling, certificate handling, etc. However, an alternative
   source for PE file handling is shim.

Changes to kexec-tools:
- Exactly same as Option 1 Xen version above

Changes to Xen:
- Changes are essentially same as Option 1 Xen above, but
   replacing linux/crypto with libgcrypt. This also involves
   changes around the API differences between linux/crypto
   and libgcrypt.

References:
[1] "XPDDS17: EFI Secure Boot, Shim and Xen: Current Status and
     Developments - Daniel Kiper - Oracle"
 
https://www.slideshare.net/xen_com_mgr/xppds17-efi-secure-boot-shim-and-xen-current-status-and-developments-daniel-kiper-oracle

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

RFC Xen signature verification for kexec

[Eric DeVolder]

In reading this and providing feedback, I'm hoping to obtain
community consensus on the following questions:
- Is there interest in this?
- Which approach is favored?
- Are there other approaches/efforts?
- Other concerns/feedback?

Executive Summary
Xen currently lacks signature verification infrastructure which makes
it vulnerable to exploit, even with secure boot mode, such as UEFI.
This proposal outlines a high-level approach to support signature
verification for kexec in Xen.

Option 1: Port Linux signature verification into Xen
Option 2: Enable signature verification in Xen utilizing libgcrypt

Overview
In UEFI secure boot mode, a "root of trust" is established. Typically,
UEFI secure boot verifies a boot loader, e.g. GRUB2, first. Then the
bootloader verifies Xen using the UEFI shim protocol and Xen verifies
the dom0 [Linux] kernel using shim protocol too.  Xen utilizes the
UEFI shim protocol at boot to verify the dom0 kernel.[1]

Thus UEFI can be used to boot into a "trusted" Xen and dom0 kernel.
However, this "trusted" environment is vulnerable to exploit as a dom0
user space application can be utilized to kexec a second, untrusted
kernel.

In the Xen environment, the kexec/kdump solution involves user space
utilities (eg. kexec-tools and makedumpfile), hypervisor support (eg.
xen/common/kexec.c) and post-mortem analysis tools (eg. crash).

Typically, in the Xen environment, the kexec of a second kernel (plus
initrd) is requested by /sbin/kexec binary *directly* invoking the Xen
kexec hypercall (which bypasses dom0) with a data structure pointing
to loadable segments.  Xen then places these segments into memory.
This second kernel is not verified, and the system can be rebooted
into an untrusted kernel.

As it stands today, the Xen hypervisor has no mechanism for signature
verification, and thus can not prevent this exploit.

NOTE: A solution for signature verification in Xen would perhaps also
enable a solution for LivePatch signature checking.


#####
Two options for signature verification in Xen

This proposal outlines two options under consideration for enhancing
Xen to support signature verification of kexec loaded images. The
first option is essentially to mirror Linux signature verification
code into Xen. The second option utilizes components from sources
other than Linux (for example, libgcrypt rather than linux/crypto).

NOTE: An option to utilize dom0 kernel signature verification does not
prevent the exploit as user space can invoke the hypercall directly,
bypassing dom0.

#####
Option 1: Port Linux signature verification into Xen

This option essentially is porting the Linux kexec_file_load()
system call as a new Xen kexec hypercall operation, for example,
KEXEC_CMD_kexec_file_load.

The license of Linux and Xen allow for Xen to take files from Linux
and incorporate into Xen. So in general most of this could be lifted
from Linux and dropped into Xen with the new hypercall op providing a
needed wrapper.

Pros:
- Most of the code already exists in Linux

Cons:
- This could potentially be taking tens of files from Linux and
   placing into Xen (linux/crypto has 115 source files). This
   would be a problematic management scenario going forward with
   uptaking changes in Linux and merging into Xen, and vice versa.

Changes to kexec-tools:
- Changes primarily to do_kexec_file_load():
   - if xen_present()...
     - Read entire file contents into buffer
     - Invoke new hypercall op

Changes to Xen:
- Import linux/crypto, linux/include/crypto, and
   linux/arch/x86/crypto <-- RSA, SHA, PKCS, etc
- Import linux/crypto/asymmetric_keys <-- PE handling
- Import linux/certs  <-- has system_keyring
- Import security/keys <-- key management
- Import various accompanying CONFIG settings
- Implement new hypercall operation,
   patterning after Linux' kexec_file_load(). One
   difference would be that rather than passing
   file handles, Xen would need to be passed pointers
   to the buffer(s) containing the image(s), as Xen
   can not read a file (for second kernel and the
   initrd) from Linux. Xen can access the buffer(s)
   via copy_from_user().

#####
Option 2: Enable signature verification in Xen utilizing libgcrypt

This option is similar to Option 1, but utilizes libgcrypt
crytpo library rather than linux/crypto files.

Pros:
- Libgcrypt is LGPLv2.1+ license.
- Eliminates problematic scenario of tracking changes to
   linux/crypto sources in Xen, and vice versa in Linux.

Cons:
- Introduces a dependency on libgcrypt
- Still relying on lifting many Linux kernel sources for PE file
   handling, certificate handling, etc. However, an alternative
   source for PE file handling is shim.

Changes to kexec-tools:
- Exactly same as Option 1 Xen version above

Changes to Xen:
- Changes are essentially same as Option 1 Xen above, but
   replacing linux/crypto with libgcrypt. This also involves
   changes around the API differences between linux/crypto
   and libgcrypt.

References:
[1] "XPDDS17: EFI Secure Boot, Shim and Xen: Current Status and
     Developments - Daniel Kiper - Oracle"
 
https://www.slideshare.net/xen_com_mgr/xppds17-efi-secure-boot-shim-and-xen-current-status-and-developments-daniel-kiper-oracle

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: RFC Xen signature verification for kexec

[Jan Beulich]

>>> On 20.04.18 at 21:12, <eric.devolder@oracle.com> wrote:
> Two options for signature verification in Xen
> 
> This proposal outlines two options under consideration for enhancing
> Xen to support signature verification of kexec loaded images. The
> first option is essentially to mirror Linux signature verification
> code into Xen. The second option utilizes components from sources
> other than Linux (for example, libgcrypt rather than linux/crypto).
> 
> NOTE: An option to utilize dom0 kernel signature verification does not
> prevent the exploit as user space can invoke the hypercall directly,
> bypassing dom0.

Not exactly - this option nevertheless exists, albeit is perhaps
unattractive: No user space component can issue hypercalls
directly, they always go through the privcmd driver. Hence the
driver cold snoop the kexec hypercall.

> #####
> Option 2: Enable signature verification in Xen utilizing libgcrypt
> 
> This option is similar to Option 1, but utilizes libgcrypt
> crytpo library rather than linux/crypto files.
> 
> Pros:
> - Libgcrypt is LGPLv2.1+ license.
> - Eliminates problematic scenario of tracking changes to
>    linux/crypto sources in Xen, and vice versa in Linux.

As an initial reaction, of the two options presented I'd prefer this
2nd one, for this specific reason.

> Cons:
> - Introduces a dependency on libgcrypt
> - Still relying on lifting many Linux kernel sources for PE file
>    handling, certificate handling, etc. However, an alternative
>    source for PE file handling is shim.

That's under the assumption that PE files are the only containers usable
to carry certificates, which I consider odd, not the least because Linux
kernel modules aren't PE either. If the kernel was carrying its certificate
in a way (also) accessible without parsing PE structures, this dependency
could be dropped.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] RFC Xen signature verification for kexec

[Jan Beulich]

>>> On 20.04.18 at 21:12, <eric.devolder@oracle.com> wrote:
> Two options for signature verification in Xen
> 
> This proposal outlines two options under consideration for enhancing
> Xen to support signature verification of kexec loaded images. The
> first option is essentially to mirror Linux signature verification
> code into Xen. The second option utilizes components from sources
> other than Linux (for example, libgcrypt rather than linux/crypto).
> 
> NOTE: An option to utilize dom0 kernel signature verification does not
> prevent the exploit as user space can invoke the hypercall directly,
> bypassing dom0.

Not exactly - this option nevertheless exists, albeit is perhaps
unattractive: No user space component can issue hypercalls
directly, they always go through the privcmd driver. Hence the
driver cold snoop the kexec hypercall.

> #####
> Option 2: Enable signature verification in Xen utilizing libgcrypt
> 
> This option is similar to Option 1, but utilizes libgcrypt
> crytpo library rather than linux/crypto files.
> 
> Pros:
> - Libgcrypt is LGPLv2.1+ license.
> - Eliminates problematic scenario of tracking changes to
>    linux/crypto sources in Xen, and vice versa in Linux.

As an initial reaction, of the two options presented I'd prefer this
2nd one, for this specific reason.

> Cons:
> - Introduces a dependency on libgcrypt
> - Still relying on lifting many Linux kernel sources for PE file
>    handling, certificate handling, etc. However, an alternative
>    source for PE file handling is shim.

That's under the assumption that PE files are the only containers usable
to carry certificates, which I consider odd, not the least because Linux
kernel modules aren't PE either. If the kernel was carrying its certificate
in a way (also) accessible without parsing PE structures, this dependency
could be dropped.

Jan



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: RFC Xen signature verification for kexec

[Daniel Kiper]

On Mon, Apr 23, 2018 at 12:55:45AM -0600, Jan Beulich wrote:
> >>> On 20.04.18 at 21:12, <eric.devolder@oracle.com> wrote:
> > Two options for signature verification in Xen
> >
> > This proposal outlines two options under consideration for enhancing
> > Xen to support signature verification of kexec loaded images. The
> > first option is essentially to mirror Linux signature verification
> > code into Xen. The second option utilizes components from sources
> > other than Linux (for example, libgcrypt rather than linux/crypto).
> >
> > NOTE: An option to utilize dom0 kernel signature verification does not
> > prevent the exploit as user space can invoke the hypercall directly,
> > bypassing dom0.
>
> Not exactly - this option nevertheless exists, albeit is perhaps
> unattractive: No user space component can issue hypercalls
> directly, they always go through the privcmd driver. Hence the
> driver cold snoop the kexec hypercall.

Hmmm... Is not it a problem from security point of view for us in this
case? It should not if dom0 kernel is signed. It have to be signed here.
Just thinking a loud...

> > #####
> > Option 2: Enable signature verification in Xen utilizing libgcrypt
> >
> > This option is similar to Option 1, but utilizes libgcrypt
> > crytpo library rather than linux/crypto files.
> >
> > Pros:
> > - Libgcrypt is LGPLv2.1+ license.
> > - Eliminates problematic scenario of tracking changes to
> >    linux/crypto sources in Xen, and vice versa in Linux.
>
> As an initial reaction, of the two options presented I'd prefer this
> 2nd one, for this specific reason.
>
> > Cons:
> > - Introduces a dependency on libgcrypt
> > - Still relying on lifting many Linux kernel sources for PE file
> >    handling, certificate handling, etc. However, an alternative
> >    source for PE file handling is shim.
>
> That's under the assumption that PE files are the only containers usable
> to carry certificates, which I consider odd, not the least because Linux
> kernel modules aren't PE either. If the kernel was carrying its certificate

I do not think that we care about kernel modules format here...

> in a way (also) accessible without parsing PE structures, this dependency
> could be dropped.

IIRC kexec-tools feeds one file with signature attached into Linux
kernel via syscall. It does not support detached signatures. Does it?
Eric, could you check it? If it does not then we have to add some
code into kexec-tools too. However, I do not think that gain in Xen
code will be significant. PE file parsing in this case should be simple.
The largest part still would be PKCS#7 and/or PEM parser. Hmmm...
There is a chance that there is a lib floating around which does that.
Eric, please double check it.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] RFC Xen signature verification for kexec

[Daniel Kiper]

On Mon, Apr 23, 2018 at 12:55:45AM -0600, Jan Beulich wrote:
> >>> On 20.04.18 at 21:12, <eric.devolder@oracle.com> wrote:
> > Two options for signature verification in Xen
> >
> > This proposal outlines two options under consideration for enhancing
> > Xen to support signature verification of kexec loaded images. The
> > first option is essentially to mirror Linux signature verification
> > code into Xen. The second option utilizes components from sources
> > other than Linux (for example, libgcrypt rather than linux/crypto).
> >
> > NOTE: An option to utilize dom0 kernel signature verification does not
> > prevent the exploit as user space can invoke the hypercall directly,
> > bypassing dom0.
>
> Not exactly - this option nevertheless exists, albeit is perhaps
> unattractive: No user space component can issue hypercalls
> directly, they always go through the privcmd driver. Hence the
> driver cold snoop the kexec hypercall.

Hmmm... Is not it a problem from security point of view for us in this
case? It should not if dom0 kernel is signed. It have to be signed here.
Just thinking a loud...

> > #####
> > Option 2: Enable signature verification in Xen utilizing libgcrypt
> >
> > This option is similar to Option 1, but utilizes libgcrypt
> > crytpo library rather than linux/crypto files.
> >
> > Pros:
> > - Libgcrypt is LGPLv2.1+ license.
> > - Eliminates problematic scenario of tracking changes to
> >    linux/crypto sources in Xen, and vice versa in Linux.
>
> As an initial reaction, of the two options presented I'd prefer this
> 2nd one, for this specific reason.
>
> > Cons:
> > - Introduces a dependency on libgcrypt
> > - Still relying on lifting many Linux kernel sources for PE file
> >    handling, certificate handling, etc. However, an alternative
> >    source for PE file handling is shim.
>
> That's under the assumption that PE files are the only containers usable
> to carry certificates, which I consider odd, not the least because Linux
> kernel modules aren't PE either. If the kernel was carrying its certificate

I do not think that we care about kernel modules format here...

> in a way (also) accessible without parsing PE structures, this dependency
> could be dropped.

IIRC kexec-tools feeds one file with signature attached into Linux
kernel via syscall. It does not support detached signatures. Does it?
Eric, could you check it? If it does not then we have to add some
code into kexec-tools too. However, I do not think that gain in Xen
code will be significant. PE file parsing in this case should be simple.
The largest part still would be PKCS#7 and/or PEM parser. Hmmm...
There is a chance that there is a lib floating around which does that.
Eric, please double check it.

Daniel

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: RFC Xen signature verification for kexec

[Jan Beulich]

>>> On 23.04.18 at 12:25, <daniel.kiper@oracle.com> wrote:
> On Mon, Apr 23, 2018 at 12:55:45AM -0600, Jan Beulich wrote:
>> >>> On 20.04.18 at 21:12, <eric.devolder@oracle.com> wrote:
>> > Two options for signature verification in Xen
>> >
>> > This proposal outlines two options under consideration for enhancing
>> > Xen to support signature verification of kexec loaded images. The
>> > first option is essentially to mirror Linux signature verification
>> > code into Xen. The second option utilizes components from sources
>> > other than Linux (for example, libgcrypt rather than linux/crypto).
>> >
>> > NOTE: An option to utilize dom0 kernel signature verification does not
>> > prevent the exploit as user space can invoke the hypercall directly,
>> > bypassing dom0.
>>
>> Not exactly - this option nevertheless exists, albeit is perhaps
>> unattractive: No user space component can issue hypercalls
>> directly, they always go through the privcmd driver. Hence the
>> driver cold snoop the kexec hypercall.
> 
> Hmmm... Is not it a problem from security point of view for us in this
> case? It should not if dom0 kernel is signed. It have to be signed here.
> Just thinking a loud...

I'm afraid I don't understand: If the Dom0 kernel isn't signed (or hasn't
been verified), the system is insecure in the first place. No reason to
bother measuring the kexec kernel then.

>> > #####
>> > Option 2: Enable signature verification in Xen utilizing libgcrypt
>> >
>> > This option is similar to Option 1, but utilizes libgcrypt
>> > crytpo library rather than linux/crypto files.
>> >
>> > Pros:
>> > - Libgcrypt is LGPLv2.1+ license.
>> > - Eliminates problematic scenario of tracking changes to
>> >    linux/crypto sources in Xen, and vice versa in Linux.
>>
>> As an initial reaction, of the two options presented I'd prefer this
>> 2nd one, for this specific reason.
>>
>> > Cons:
>> > - Introduces a dependency on libgcrypt
>> > - Still relying on lifting many Linux kernel sources for PE file
>> >    handling, certificate handling, etc. However, an alternative
>> >    source for PE file handling is shim.
>>
>> That's under the assumption that PE files are the only containers usable
>> to carry certificates, which I consider odd, not the least because Linux
>> kernel modules aren't PE either. If the kernel was carrying its certificate
> 
> I do not think that we care about kernel modules format here...

This was just meant to give an example of a case where PE is not required
for carrying certificates.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] RFC Xen signature verification for kexec

[Jan Beulich]

>>> On 23.04.18 at 12:25, <daniel.kiper@oracle.com> wrote:
> On Mon, Apr 23, 2018 at 12:55:45AM -0600, Jan Beulich wrote:
>> >>> On 20.04.18 at 21:12, <eric.devolder@oracle.com> wrote:
>> > Two options for signature verification in Xen
>> >
>> > This proposal outlines two options under consideration for enhancing
>> > Xen to support signature verification of kexec loaded images. The
>> > first option is essentially to mirror Linux signature verification
>> > code into Xen. The second option utilizes components from sources
>> > other than Linux (for example, libgcrypt rather than linux/crypto).
>> >
>> > NOTE: An option to utilize dom0 kernel signature verification does not
>> > prevent the exploit as user space can invoke the hypercall directly,
>> > bypassing dom0.
>>
>> Not exactly - this option nevertheless exists, albeit is perhaps
>> unattractive: No user space component can issue hypercalls
>> directly, they always go through the privcmd driver. Hence the
>> driver cold snoop the kexec hypercall.
> 
> Hmmm... Is not it a problem from security point of view for us in this
> case? It should not if dom0 kernel is signed. It have to be signed here.
> Just thinking a loud...

I'm afraid I don't understand: If the Dom0 kernel isn't signed (or hasn't
been verified), the system is insecure in the first place. No reason to
bother measuring the kexec kernel then.

>> > #####
>> > Option 2: Enable signature verification in Xen utilizing libgcrypt
>> >
>> > This option is similar to Option 1, but utilizes libgcrypt
>> > crytpo library rather than linux/crypto files.
>> >
>> > Pros:
>> > - Libgcrypt is LGPLv2.1+ license.
>> > - Eliminates problematic scenario of tracking changes to
>> >    linux/crypto sources in Xen, and vice versa in Linux.
>>
>> As an initial reaction, of the two options presented I'd prefer this
>> 2nd one, for this specific reason.
>>
>> > Cons:
>> > - Introduces a dependency on libgcrypt
>> > - Still relying on lifting many Linux kernel sources for PE file
>> >    handling, certificate handling, etc. However, an alternative
>> >    source for PE file handling is shim.
>>
>> That's under the assumption that PE files are the only containers usable
>> to carry certificates, which I consider odd, not the least because Linux
>> kernel modules aren't PE either. If the kernel was carrying its certificate
> 
> I do not think that we care about kernel modules format here...

This was just meant to give an example of a case where PE is not required
for carrying certificates.

Jan



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: RFC Xen signature verification for kexec

[George Dunlap]

On Mon, Apr 23, 2018 at 11:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 23.04.18 at 12:25, <daniel.kiper@oracle.com> wrote:
>> On Mon, Apr 23, 2018 at 12:55:45AM -0600, Jan Beulich wrote:
>>> >>> On 20.04.18 at 21:12, <eric.devolder@oracle.com> wrote:
>>> > Two options for signature verification in Xen
>>> >
>>> > This proposal outlines two options under consideration for enhancing
>>> > Xen to support signature verification of kexec loaded images. The
>>> > first option is essentially to mirror Linux signature verification
>>> > code into Xen. The second option utilizes components from sources
>>> > other than Linux (for example, libgcrypt rather than linux/crypto).
>>> >
>>> > NOTE: An option to utilize dom0 kernel signature verification does not
>>> > prevent the exploit as user space can invoke the hypercall directly,
>>> > bypassing dom0.
>>>
>>> Not exactly - this option nevertheless exists, albeit is perhaps
>>> unattractive: No user space component can issue hypercalls
>>> directly, they always go through the privcmd driver. Hence the
>>> driver cold snoop the kexec hypercall.
>>
>> Hmmm... Is not it a problem from security point of view for us in this
>> case? It should not if dom0 kernel is signed. It have to be signed here.
>> Just thinking a loud...
>
> I'm afraid I don't understand: If the Dom0 kernel isn't signed (or hasn't
> been verified), the system is insecure in the first place. No reason to
> bother measuring the kexec kernel then.

I think you're both saying the same thing.

FWIW I wouldn't mind coming up with a hypercall that the privcmd
driver refuses to pass-through as-is, and having some way for the
tools to ask the kernel to check the signature.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] RFC Xen signature verification for kexec

[George Dunlap]

On Mon, Apr 23, 2018 at 11:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 23.04.18 at 12:25, <daniel.kiper@oracle.com> wrote:
>> On Mon, Apr 23, 2018 at 12:55:45AM -0600, Jan Beulich wrote:
>>> >>> On 20.04.18 at 21:12, <eric.devolder@oracle.com> wrote:
>>> > Two options for signature verification in Xen
>>> >
>>> > This proposal outlines two options under consideration for enhancing
>>> > Xen to support signature verification of kexec loaded images. The
>>> > first option is essentially to mirror Linux signature verification
>>> > code into Xen. The second option utilizes components from sources
>>> > other than Linux (for example, libgcrypt rather than linux/crypto).
>>> >
>>> > NOTE: An option to utilize dom0 kernel signature verification does not
>>> > prevent the exploit as user space can invoke the hypercall directly,
>>> > bypassing dom0.
>>>
>>> Not exactly - this option nevertheless exists, albeit is perhaps
>>> unattractive: No user space component can issue hypercalls
>>> directly, they always go through the privcmd driver. Hence the
>>> driver cold snoop the kexec hypercall.
>>
>> Hmmm... Is not it a problem from security point of view for us in this
>> case? It should not if dom0 kernel is signed. It have to be signed here.
>> Just thinking a loud...
>
> I'm afraid I don't understand: If the Dom0 kernel isn't signed (or hasn't
> been verified), the system is insecure in the first place. No reason to
> bother measuring the kexec kernel then.

I think you're both saying the same thing.

FWIW I wouldn't mind coming up with a hypercall that the privcmd
driver refuses to pass-through as-is, and having some way for the
tools to ask the kernel to check the signature.

 -George

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: RFC Xen signature verification for kexec

[Daniel Kiper]

On Tue, Apr 24, 2018 at 10:46:38AM +0100, George Dunlap wrote:
> On Mon, Apr 23, 2018 at 11:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>> On 23.04.18 at 12:25, <daniel.kiper@oracle.com> wrote:
> >> On Mon, Apr 23, 2018 at 12:55:45AM -0600, Jan Beulich wrote:
> >>> >>> On 20.04.18 at 21:12, <eric.devolder@oracle.com> wrote:
> >>> > Two options for signature verification in Xen
> >>> >
> >>> > This proposal outlines two options under consideration for enhancing
> >>> > Xen to support signature verification of kexec loaded images. The
> >>> > first option is essentially to mirror Linux signature verification
> >>> > code into Xen. The second option utilizes components from sources
> >>> > other than Linux (for example, libgcrypt rather than linux/crypto).
> >>> >
> >>> > NOTE: An option to utilize dom0 kernel signature verification does not
> >>> > prevent the exploit as user space can invoke the hypercall directly,
> >>> > bypassing dom0.
> >>>
> >>> Not exactly - this option nevertheless exists, albeit is perhaps
> >>> unattractive: No user space component can issue hypercalls
> >>> directly, they always go through the privcmd driver. Hence the
> >>> driver cold snoop the kexec hypercall.
> >>
> >> Hmmm... Is not it a problem from security point of view for us in this
> >> case? It should not if dom0 kernel is signed. It have to be signed here.
> >> Just thinking a loud...
> >
> > I'm afraid I don't understand: If the Dom0 kernel isn't signed (or hasn't
> > been verified), the system is insecure in the first place. No reason to
> > bother measuring the kexec kernel then.
>
> I think you're both saying the same thing.
>
> FWIW I wouldn't mind coming up with a hypercall that the privcmd
> driver refuses to pass-through as-is, and having some way for the
> tools to ask the kernel to check the signature.

I have a feeling that I should reformulate the question: How far the Xen
hypervisor trusts the privcmd driver? If the privcmd driver is signed
then at first sight there should not be a problem. However, we can be
more strict and require that (every? Daniel is running away...) hypercall
from privcmd to Xen should be verified somehow. Maybe I am overzealous but
I think that it make sense to discuss this now than later have problems.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] RFC Xen signature verification for kexec

[Daniel Kiper]

On Tue, Apr 24, 2018 at 10:46:38AM +0100, George Dunlap wrote:
> On Mon, Apr 23, 2018 at 11:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>> On 23.04.18 at 12:25, <daniel.kiper@oracle.com> wrote:
> >> On Mon, Apr 23, 2018 at 12:55:45AM -0600, Jan Beulich wrote:
> >>> >>> On 20.04.18 at 21:12, <eric.devolder@oracle.com> wrote:
> >>> > Two options for signature verification in Xen
> >>> >
> >>> > This proposal outlines two options under consideration for enhancing
> >>> > Xen to support signature verification of kexec loaded images. The
> >>> > first option is essentially to mirror Linux signature verification
> >>> > code into Xen. The second option utilizes components from sources
> >>> > other than Linux (for example, libgcrypt rather than linux/crypto).
> >>> >
> >>> > NOTE: An option to utilize dom0 kernel signature verification does not
> >>> > prevent the exploit as user space can invoke the hypercall directly,
> >>> > bypassing dom0.
> >>>
> >>> Not exactly - this option nevertheless exists, albeit is perhaps
> >>> unattractive: No user space component can issue hypercalls
> >>> directly, they always go through the privcmd driver. Hence the
> >>> driver cold snoop the kexec hypercall.
> >>
> >> Hmmm... Is not it a problem from security point of view for us in this
> >> case? It should not if dom0 kernel is signed. It have to be signed here.
> >> Just thinking a loud...
> >
> > I'm afraid I don't understand: If the Dom0 kernel isn't signed (or hasn't
> > been verified), the system is insecure in the first place. No reason to
> > bother measuring the kexec kernel then.
>
> I think you're both saying the same thing.
>
> FWIW I wouldn't mind coming up with a hypercall that the privcmd
> driver refuses to pass-through as-is, and having some way for the
> tools to ask the kernel to check the signature.

I have a feeling that I should reformulate the question: How far the Xen
hypervisor trusts the privcmd driver? If the privcmd driver is signed
then at first sight there should not be a problem. However, we can be
more strict and require that (every? Daniel is running away...) hypercall
from privcmd to Xen should be verified somehow. Maybe I am overzealous but
I think that it make sense to discuss this now than later have problems.

Daniel

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: RFC Xen signature verification for kexec

[Jan Beulich]

>>> On 24.04.18 at 12:13, <daniel.kiper@oracle.com> wrote:
> On Tue, Apr 24, 2018 at 10:46:38AM +0100, George Dunlap wrote:
>> On Mon, Apr 23, 2018 at 11:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >>>> On 23.04.18 at 12:25, <daniel.kiper@oracle.com> wrote:
>> >> On Mon, Apr 23, 2018 at 12:55:45AM -0600, Jan Beulich wrote:
>> >>> >>> On 20.04.18 at 21:12, <eric.devolder@oracle.com> wrote:
>> >>> > Two options for signature verification in Xen
>> >>> >
>> >>> > This proposal outlines two options under consideration for enhancing
>> >>> > Xen to support signature verification of kexec loaded images. The
>> >>> > first option is essentially to mirror Linux signature verification
>> >>> > code into Xen. The second option utilizes components from sources
>> >>> > other than Linux (for example, libgcrypt rather than linux/crypto).
>> >>> >
>> >>> > NOTE: An option to utilize dom0 kernel signature verification does not
>> >>> > prevent the exploit as user space can invoke the hypercall directly,
>> >>> > bypassing dom0.
>> >>>
>> >>> Not exactly - this option nevertheless exists, albeit is perhaps
>> >>> unattractive: No user space component can issue hypercalls
>> >>> directly, they always go through the privcmd driver. Hence the
>> >>> driver cold snoop the kexec hypercall.
>> >>
>> >> Hmmm... Is not it a problem from security point of view for us in this
>> >> case? It should not if dom0 kernel is signed. It have to be signed here.
>> >> Just thinking a loud...
>> >
>> > I'm afraid I don't understand: If the Dom0 kernel isn't signed (or hasn't
>> > been verified), the system is insecure in the first place. No reason to
>> > bother measuring the kexec kernel then.
>>
>> I think you're both saying the same thing.
>>
>> FWIW I wouldn't mind coming up with a hypercall that the privcmd
>> driver refuses to pass-through as-is, and having some way for the
>> tools to ask the kernel to check the signature.
> 
> I have a feeling that I should reformulate the question: How far the Xen
> hypervisor trusts the privcmd driver? If the privcmd driver is signed
> then at first sight there should not be a problem. However, we can be
> more strict and require that (every? Daniel is running away...) hypercall
> from privcmd to Xen should be verified somehow. Maybe I am overzealous but
> I think that it make sense to discuss this now than later have problems.

An analogy of this would be that every system call needs verifying by the
OS, which imo would be insane. Once we established trust in a component,
we _should_ trust it.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] RFC Xen signature verification for kexec

[Jan Beulich]

>>> On 24.04.18 at 12:13, <daniel.kiper@oracle.com> wrote:
> On Tue, Apr 24, 2018 at 10:46:38AM +0100, George Dunlap wrote:
>> On Mon, Apr 23, 2018 at 11:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >>>> On 23.04.18 at 12:25, <daniel.kiper@oracle.com> wrote:
>> >> On Mon, Apr 23, 2018 at 12:55:45AM -0600, Jan Beulich wrote:
>> >>> >>> On 20.04.18 at 21:12, <eric.devolder@oracle.com> wrote:
>> >>> > Two options for signature verification in Xen
>> >>> >
>> >>> > This proposal outlines two options under consideration for enhancing
>> >>> > Xen to support signature verification of kexec loaded images. The
>> >>> > first option is essentially to mirror Linux signature verification
>> >>> > code into Xen. The second option utilizes components from sources
>> >>> > other than Linux (for example, libgcrypt rather than linux/crypto).
>> >>> >
>> >>> > NOTE: An option to utilize dom0 kernel signature verification does not
>> >>> > prevent the exploit as user space can invoke the hypercall directly,
>> >>> > bypassing dom0.
>> >>>
>> >>> Not exactly - this option nevertheless exists, albeit is perhaps
>> >>> unattractive: No user space component can issue hypercalls
>> >>> directly, they always go through the privcmd driver. Hence the
>> >>> driver cold snoop the kexec hypercall.
>> >>
>> >> Hmmm... Is not it a problem from security point of view for us in this
>> >> case? It should not if dom0 kernel is signed. It have to be signed here.
>> >> Just thinking a loud...
>> >
>> > I'm afraid I don't understand: If the Dom0 kernel isn't signed (or hasn't
>> > been verified), the system is insecure in the first place. No reason to
>> > bother measuring the kexec kernel then.
>>
>> I think you're both saying the same thing.
>>
>> FWIW I wouldn't mind coming up with a hypercall that the privcmd
>> driver refuses to pass-through as-is, and having some way for the
>> tools to ask the kernel to check the signature.
> 
> I have a feeling that I should reformulate the question: How far the Xen
> hypervisor trusts the privcmd driver? If the privcmd driver is signed
> then at first sight there should not be a problem. However, we can be
> more strict and require that (every? Daniel is running away...) hypercall
> from privcmd to Xen should be verified somehow. Maybe I am overzealous but
> I think that it make sense to discuss this now than later have problems.

An analogy of this would be that every system call needs verifying by the
OS, which imo would be insane. Once we established trust in a component,
we _should_ trust it.

Jan



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec