Re: [qubes-users] UEFI secureboot issue
89 views
Skip to first unread message
Marek Marczykowski-Górecki
Jun 6, 2018, 5:46:57 AM6/6/18
to kra...@gmail.com, qubes-users, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Fri, Jun 01, 2018 at 07:48:52AM -0700, kra...@gmail.com wrote:
> Just curious if there is any movement on this.
>
> It's mind boggling that an OS that claims to be "secure OS" does not implement binary signing.
>
> Unfortunately, as it is the system is not usable to me. Though it makes for a nice show with all different colors.
>
> Any chance this will be fast tracked?
Generally having signed xen/kernel binaries would be a good thing,
mostly because AEM is incompatible with UEFI, so there is no alternative
way of verifying /boot integrity boot time. In any case, you can verify
/boot files integrity using rpm database, which is derived from signed
rpm packages (see rpm -V). But that doesn't help during system boot.
Implementing this requires quite a bit of knowledge/research:
1. How to sign efi binaries (specific command), preferably in a
split-gpg compatible way (if that's using gpg at all, which AFAIK isn't
true). Preferable private key shouldn't be exposed directly to the build
environment, but in any case, it should be separate key from package
signing key.
2. Make sure kernel and initramfs also gets verified (the only binary
loaded directly is the xen.efi) - how to do that when initramfs is
dynamically generated? How other distributions do that(*)?
AFAIK xen.efi do have support for shim.efi (is that the correct name?)
for offloading signature verification, but still it isn't clear to me
how it helps here.
3. Make sure xen and kernel command line is also verified - similar
problem to initramfs. I'd strongly prefer to avoid hardcoding them at
the build time...
As you can see, meaningful implementation of this is much more than just
signing xen.efi and vmlinuz. If there is anyone who could help with any
of the above, we'd be very grateful.
(*) AFAIK in Fedora, if kernel is loaded with secure boot enabled, it
refuse to load not correctly signed kernel modules (and employ other
mitigations for modifying the kernel at runtime). But this is far from
enough, because it's still possible modify initramfs to for example
steal your disk passphrase. I don't know if there are other mitigations
against that.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlsXrYoACgkQ24/THMrX
1yx6+gf9ElVMEp+52yhwTP5iQA4A1SZAJMdbKzN0InyCY7VowxcVqPKJwma7Fc1l
WKipTaMBHj0FjqYRYQc7KeDcy76oldJr6aDk5SICJu5fCfySO3viNozAEYoP0bFr
sKujRZN/Jk49khugLpFSza43Flum8t/jDJrnpkbO3qVDzG/8DF5dHKcyr9VjPiI3
tgliLDsyMxfJWA/hprtw2DZUFIuYRW0koVf78IjeOPpfHikahqYwVTg5o760Vajr
5IU11QAWJ5r+oDpcswcXRONzohz6GucKSdKCGbBpQHmIEyx+CGnOUxjFQqix3RPn
vk2yvouv58IqnvbW1YN5c0AB1rDmig==
=kY5v
-----END PGP SIGNATURE-----
Hash: SHA256
On Fri, Jun 01, 2018 at 07:48:52AM -0700, kra...@gmail.com wrote:
> Just curious if there is any movement on this.
>
> It's mind boggling that an OS that claims to be "secure OS" does not implement binary signing.
>
> Unfortunately, as it is the system is not usable to me. Though it makes for a nice show with all different colors.
>
> Any chance this will be fast tracked?
Generally having signed xen/kernel binaries would be a good thing,
mostly because AEM is incompatible with UEFI, so there is no alternative
way of verifying /boot integrity boot time. In any case, you can verify
/boot files integrity using rpm database, which is derived from signed
rpm packages (see rpm -V). But that doesn't help during system boot.
Implementing this requires quite a bit of knowledge/research:
1. How to sign efi binaries (specific command), preferably in a
split-gpg compatible way (if that's using gpg at all, which AFAIK isn't
true). Preferable private key shouldn't be exposed directly to the build
environment, but in any case, it should be separate key from package
signing key.
2. Make sure kernel and initramfs also gets verified (the only binary
loaded directly is the xen.efi) - how to do that when initramfs is
dynamically generated? How other distributions do that(*)?
AFAIK xen.efi do have support for shim.efi (is that the correct name?)
for offloading signature verification, but still it isn't clear to me
how it helps here.
3. Make sure xen and kernel command line is also verified - similar
problem to initramfs. I'd strongly prefer to avoid hardcoding them at
the build time...
As you can see, meaningful implementation of this is much more than just
signing xen.efi and vmlinuz. If there is anyone who could help with any
of the above, we'd be very grateful.
(*) AFAIK in Fedora, if kernel is loaded with secure boot enabled, it
refuse to load not correctly signed kernel modules (and employ other
mitigations for modifying the kernel at runtime). But this is far from
enough, because it's still possible modify initramfs to for example
steal your disk passphrase. I don't know if there are other mitigations
against that.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlsXrYoACgkQ24/THMrX
1yx6+gf9ElVMEp+52yhwTP5iQA4A1SZAJMdbKzN0InyCY7VowxcVqPKJwma7Fc1l
WKipTaMBHj0FjqYRYQc7KeDcy76oldJr6aDk5SICJu5fCfySO3viNozAEYoP0bFr
sKujRZN/Jk49khugLpFSza43Flum8t/jDJrnpkbO3qVDzG/8DF5dHKcyr9VjPiI3
tgliLDsyMxfJWA/hprtw2DZUFIuYRW0koVf78IjeOPpfHikahqYwVTg5o760Vajr
5IU11QAWJ5r+oDpcswcXRONzohz6GucKSdKCGbBpQHmIEyx+CGnOUxjFQqix3RPn
vk2yvouv58IqnvbW1YN5c0AB1rDmig==
=kY5v
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Jun 6, 2018, 10:55:32 AM6/6/18
to cooloutac, qubes-users, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Wed, Jun 06, 2018 at 06:55:21AM -0700, cooloutac wrote:
Hash: SHA256
> On Wednesday, June 6, 2018 at 9:53:45 AM UTC-4, cooloutac wrote:
> > This article might help. They also talk about encrypted /boot.
> >
> > https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd
>
> Seems as if people have only implemented this for debian based systems.
Good find. This rely on grub loading all of those, which require
multiboot2 protocol support in Xen. This, on the other hand is supported
only in Xen>=4.9, so Xen 4.8 in Qubes 4.0 is too old for that.
In Qubes 4.1 we plan to use Xen 4.11, so it would be possible to
implement it there.
But still, there is quite a bit of work with it. For example key
management. Since the initramfs is generated on user machine, there
needs to be a private key to sign it. This means each installation needs
to have its own key. The public part of this key needs to be embedded
into grub standalone image, which means we can't generate signed build
binary build time. This means different secure boot signing key for each
installation, so yet another key to be generated during installation,
then to be manually imported into UEFI keyring...
The script in that article is a good base for such solution, but
obviously it needs to be modified for Qubes specifics.
In the meantime I've found that newest tboot supposedly support UEFI
boot, so it could be possible to make AEM works on UEFI too. This would
handle initramfs, kernel cmdline etc verification.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
1yx0fAf+KREox86t4xIqLXU+Y+h0tG8yL+WRWGvAbQG50Lpav3dLgwZCIGNp1RzN
dmneyOXGKZzw+YdiW/dC7oqp8QJwVG7akw+/U63csHCUkGJ7t8NHA+On4A0TvewA
7Q5dZTpdmda07aFR4vQqCCokmLCeqxROrYEMRSFDr1qRpWCRp1hGIcopxcrsUVyA
rYIONpNDVbI5C3Oo1Y7NUAJuUaLZJBm+U0JjEiHF8DL7JysM1fnonkHORWOt5/jL
YX+Ozlz9BpzoDYRtCIA4MZfvzBIQ3BV4rgl1ft57Y2YvGALd6EMg+DSmPzPl82zK
zbkvDTgT3riHi8AnB8JsH6aMe8+UJg==
=KGDd
-----END PGP SIGNATURE-----
Trammell Hudson
Jun 6, 2018, 11:25:07 AM6/6/18
to Marek Marczykowski-G??recki, cooloutac, qubes-devel
On Wed, Jun 06, 2018 at 04:55:25PM +0200, Marek Marczykowski-G??recki wrote:
> [...]
keys or passwords involved in the boot process and no easy way to
manage them.
> Since the initramfs is generated on user machine, there
> needs to be a private key to sign it. This means each installation needs
> to have its own key. [...]
How much does the initramfs vary between installations? Is it possible
to have an official one that is signed and distributed as part of the
updates instead of generating it locally?
My preference would be to adopt something like a read-only dom0 with
a signed dm-verity root hash to ensure that the filesystems are unmodified.
If users want to modify dom0, they would need to enroll their own keys
and handle updates, but otherwise the qubes signing key could be used
on the static dom0 root fs.
For systems with user keys, it might be worth looking at what the Librem
team is doing -- they have hooks to detect a kernel upgrade and initramfs
regeneratation and prompt the user to plug-in their hardware token to
re-sign the kernel/initramfs/config parameters. They also use the Heads
firmware and the TPM counter to detect rollback attempts.
--
Trammell
> [...]
> But still, there is quite a bit of work with it. For example key
> management.
The key management issues are really difficult - I count over a dozen
> management.
keys or passwords involved in the boot process and no easy way to
manage them.
> Since the initramfs is generated on user machine, there
> needs to be a private key to sign it. This means each installation needs
How much does the initramfs vary between installations? Is it possible
to have an official one that is signed and distributed as part of the
updates instead of generating it locally?
My preference would be to adopt something like a read-only dom0 with
a signed dm-verity root hash to ensure that the filesystems are unmodified.
If users want to modify dom0, they would need to enroll their own keys
and handle updates, but otherwise the qubes signing key could be used
on the static dom0 root fs.
For systems with user keys, it might be worth looking at what the Librem
team is doing -- they have hooks to detect a kernel upgrade and initramfs
regeneratation and prompt the user to plug-in their hardware token to
re-sign the kernel/initramfs/config parameters. They also use the Heads
firmware and the TPM counter to detect rollback attempts.
--
Trammell
Marek Marczykowski-G??recki
Jun 6, 2018, 3:27:57 PM6/6/18
to Trammell Hudson, cooloutac, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Wed, Jun 06, 2018 at 09:24:54AM -0600, Trammell Hudson wrote:
> On Wed, Jun 06, 2018 at 04:55:25PM +0200, Marek Marczykowski-G??recki wrote:
> > [...]
> > But still, there is quite a bit of work with it. For example key
> > management.
>
> The key management issues are really difficult - I count over a dozen
> keys or passwords involved in the boot process and no easy way to
> manage them.
>
> > Since the initramfs is generated on user machine, there
> > needs to be a private key to sign it. This means each installation needs
> > to have its own key. [...]
>
> How much does the initramfs vary between installations? Is it possible
> to have an official one that is signed and distributed as part of the
> updates instead of generating it locally?
- included hardware drivers (that's easy - we can include all of them)
- system configuration - including partition layout (partition UUID,
different values for root=, depending on LVM config or btrfs usage),
keyboard layout etc
The second point is partially embedded into initramfs (/etc/crypttab,
/etc/vconsole.conf) and partially provided via kernel command line. Both
things needs to be authenticated, so even if we reduce one of them (for
example move all the variables to the kernel command line), we will still
have a problem.
> My preference would be to adopt something like a read-only dom0 with
> a signed dm-verity root hash to ensure that the filesystems are unmodified.
> If users want to modify dom0, they would need to enroll their own keys
> and handle updates, but otherwise the qubes signing key could be used
> on the static dom0 root fs.
as user interface (window manager etc) is part of dom0, as those things
are highly customizable and require ability to install packages in dom0.
But when we move GUI to a separate domain (hopefully in Qubes 4.1), that
would be much more realistic. It isn't clear at this stage whether we
could get rid of X server from dom0 in all the configurations (means -
great reduction of dom0 system), depending on GPU passthrough
reliability. So, a static, minimal dom0 is further away.
> For systems with user keys, it might be worth looking at what the Librem
> team is doing -- they have hooks to detect a kernel upgrade and initramfs
> regeneratation and prompt the user to plug-in their hardware token to
> re-sign the kernel/initramfs/config parameters. They also use the Heads
> firmware and the TPM counter to detect rollback attempts.
with actual implementation yet.
- - --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
- -----BEGIN PGP SIGNATURE-----
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlsYNWoACgkQ24/THMrX
1yxt9gf/eTI2Qy6m8SdrIQStjCUnB+SC58o2G/ZlRqUjFwkeByQCLvpnt0HOEpzy
V4mh5rJZABWNXmtvcCMYNNK0FX2PUcbRLvX7KpSYYTSQ5TqriiJYXSDcGmuM2EDY
0Xi+3EZDhDJO7UqA/kETAXolrep1yTNkaDNjVi75Af6xeewoOp4V4TwXAktJm4Ih
ggXsBvOSDiKwuoCx4qAECkvws/6Spq4ZjwkSFQiN3lr32/Oga6lA/7qicDZsX1tJ
nVgfI6qceiUkYXkQ5EdPlEoHg3EegX1klxAvgxTlkgLlUb7qvjSwrV9QVTzCzSgG
hc51uiDT+1ivoGtARDzpcYSIMKSNrQ==
=4mXa
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlsYNbYACgkQ24/THMrX
1yyk2gf+MFg+sBCSQ1t+mMu2NCkhTIDsAF59tznfVZ8VgCD2utQk6fqy4TH8o3oi
bWRPvOjYqQ2CUrHlrF29gUYAKSjk/g9rrjP1j6GFcYRtzhZ3sstbASOTL/ZxbIQo
qKmcqmYBMxvkgY0vbnd6kLE1v79lu64+NICblRo2uf5tNCDlCAqLnOS9E4adaAKK
SYVJ+H0gQ8hscfYEp8hniQewMYJjtksOFiBNt7rRRsPBVPdXHh02+QoTQawPsSLw
E1XuTm/nuGUanN13a7t5IvzHMql503V+FxOqF/tZHAhXXGD2aDzLSFvR8GNFADBX
k4uQqxcHmG4N8uiej9rjX2iP1NonzA==
=55MY
-----END PGP SIGNATURE-----
Tai...@gmx.com
Jun 6, 2018, 4:14:49 PM6/6/18
to qubes...@googlegroups.com
On 06/06/2018 03:27 PM, Marek Marczykowski-G??recki wrote:
>
>> For systems with user keys, it might be worth looking at what the Librem
>> team is doing -- they have hooks to detect a kernel upgrade and initramfs
>> regeneratation and prompt the user to plug-in their hardware token to
>> re-sign the kernel/initramfs/config parameters. They also use the Heads
>> firmware and the TPM counter to detect rollback attempts.
>
> That's indeed interesting. I've seen a video of it, but haven't played
> with actual implementation yet.
I too think it is somewhat interesting but fundamentally useless on a
>
>> For systems with user keys, it might be worth looking at what the Librem
>> team is doing -- they have hooks to detect a kernel upgrade and initramfs
>> regeneratation and prompt the user to plug-in their hardware token to
>> re-sign the kernel/initramfs/config parameters. They also use the Heads
>> firmware and the TPM counter to detect rollback attempts.
>
> That's indeed interesting. I've seen a video of it, but haven't played
> with actual implementation yet.
system with proprietary firmware, for some reason they continually focus
on gimmicks instead of selling systems that have legitimately free
firmware not simply coreboot+FSP.
Most hardware crypto systems are full of security problems, many lack
open source firmware and there is also the very real issue of a usb
based attack as this system relies on people plugging in devices that
can access dom0 via a DMA using USB controller vs for instance using a
rs232 serial port which of course is not DMA capable.
I really don't think the qubes team should be wasting time implementing
MS designed systems such as "secure" boot which is designed to prevent
people from running linux entirely - SB 2.0 standards leave out the
owner control mandate and MS has tested the waters with their SB ARM
machines that arbitrary prohibit the user from installing their own OS
and firmware.
They first changed phones from owner controlled to a walled garden and
now they are coming for the general purpose PC too. I am old enough to
remember the palmOS era you could install anything you wanted on your
smartphone with no restrictions...
Tamas K Lengyel
Jun 7, 2018, 8:54:36 PM6/7/18
to Marek Marczykowski-Górecki, kra...@gmail.com, qubes...@googlegroups.com, qubes-devel
> On Fri, Jun 01, 2018 at 07:48:52AM -0700, kra...@gmail.com wrote:
> > Just curious if there is any movement on this.
> >
> > It's mind boggling that an OS that claims to be "secure OS" does not implement binary signing.
> >
> > Unfortunately, as it is the system is not usable to me. Though it makes for a nice show with all different colors.
> >
> > Any chance this will be fast tracked?
>
> Generally having signed xen/kernel binaries would be a good thing,
> mostly because AEM is incompatible with UEFI, so there is no alternative
> way of verifying /boot integrity boot time.
There are out-of-tree patches available for Xen and tboot that make it
> > Just curious if there is any movement on this.
> >
> > It's mind boggling that an OS that claims to be "secure OS" does not implement binary signing.
> >
> > Unfortunately, as it is the system is not usable to me. Though it makes for a nice show with all different colors.
> >
> > Any chance this will be fast tracked?
>
> Generally having signed xen/kernel binaries would be a good thing,
> mostly because AEM is incompatible with UEFI, so there is no alternative
> way of verifying /boot integrity boot time.
possible to enable both SecureBoot and AEM. Instruction and patches
are at https://github.com/tklengyel/xen-uefi
Cheers,
Tamas
Reply all
Reply to author
Forward
0 new messages