Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
On 10/26/2016 10:35 PM, Theodore Ts'o wrote: > In the case of firmware which is flashed into non-volatile memory, I > would guess that the it probably wouldn't necessarliy use the > Microsoft signing key at all. (For example, for a long time most > printers were not bothering to do any digital signature checking at > all before installing a firmware update.) I think this is pretty much untrue, bugs non-withstanding. If the machine is booting in Secure Boot mode, the UEFI firmware is supposed to validate Option ROMs found on addon cards (PXE boot ROM, VGA BIOS, RAID adapter ROM) if executed on the main CPU. The printer example is not particularly relevant to that. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
On Wed, Oct 26, 2016 at 08:42:07AM +0200, Philipp Kern wrote: > > To the extent that we could easily support this particular use case, > > it might be a good thing. (I doubt Debian is going to want to get > > into the business of verifying and then resigning firmware blobs.) > > Depends if you are then able to flash it into the addon card you have > (think VGA BIOS on an NVIDIA graphics card), which requires a) access to > some flash process and b) depending on that potentially a signature > trusted by the device to accept the update. So I guess I was assuming the use case where the firmware is dynamically loaded into RAM each time the machine boot. For example, this is how the Intel Wireless drivers' firmware is handled. I need to have the binary blob iwlwifi-8000C-22.ucode available on my system each time it boots, or the wifi card no talkee to the network. Since it is needed each time the system boots, and certain cases (for example, a firewire device which can do arbitrary, unrestricted, device-initiated DMA requests anywhere in host memory[1]), it would make sense that the firmware needs to be signed before it can be loaded. In the case of firmware which is flashed into non-volatile memory, I would guess that the it probably wouldn't necessarliy use the Microsoft signing key at all. (For example, for a long time most printers were not bothering to do any digital signature checking at all before installing a firmware update.) > Otherwise you end up with no graphics output on bootup because the > system is not trusting the blob on your graphics card to run. If you > screw it up too heavily, you can render your machine unbootable as well. > (I know a coworker succeeded in doing that when modifying the key set.) > Nothing a SPI programmer can't fix, but it'd be annoying nonetheless. I suspect that most firmwares that have to be flashed will need to be done using vendor-provided software. For example, on Lenovo systems, where you have to get the BIOS update on a bootable USB stick which you then boot. In that case it's largely orthogonal to Linux and Debian altogether. The problem would be more for firmwares which have to be loaded each time you boot Linux. Cheers, - Ted
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
On 10/24/2016 06:20 PM, Theodore Ts'o wrote: > On Tue, Oct 18, 2016 at 07:52:13PM +0800, Paul Wise wrote: >> It was posted to bug #820036, which is tracking Debian support for >> secure boot. Peter was advocating quite correctly that as well as >> having our copy of shim (the first-stage bootloader on secure boot >> systems) signed by Microsoft, we should also have a copy signed by a >> Debian signing authority, so that users can theoretically choose to >> distrust the Microsoft key. IIRC, unfortunately in practice that is >> unlikely to be possible since various firmware blobs are only >> Microsoft-signed. > It's probably not possible for Debian to deal with this, but I could > imagine a user (perhaps someone who is using Debian for their entire > organization, etc.) who is willing to download firmware blobs from a > trusted source (e.g., directly from the vendor), and then verify the > Microsoft signature as a double check, and then resign it with their > own signing authority key. > > To the extent that we could easily support this particular use case, > it might be a good thing. (I doubt Debian is going to want to get > into the business of verifying and then resigning firmware blobs.) Depends if you are then able to flash it into the addon card you have (think VGA BIOS on an NVIDIA graphics card), which requires a) access to some flash process and b) depending on that potentially a signature trusted by the device to accept the update. Otherwise you end up with no graphics output on bootup because the system is not trusting the blob on your graphics card to run. If you screw it up too heavily, you can render your machine unbootable as well. (I know a coworker succeeded in doing that when modifying the key set.) Nothing a SPI programmer can't fix, but it'd be annoying nonetheless. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
On Tue, Oct 18, 2016 at 07:52:13PM +0800, Paul Wise wrote: > > It was posted to bug #820036, which is tracking Debian support for > secure boot. Peter was advocating quite correctly that as well as > having our copy of shim (the first-stage bootloader on secure boot > systems) signed by Microsoft, we should also have a copy signed by a > Debian signing authority, so that users can theoretically choose to > distrust the Microsoft key. IIRC, unfortunately in practice that is > unlikely to be possible since various firmware blobs are only > Microsoft-signed. It's probably not possible for Debian to deal with this, but I could imagine a user (perhaps someone who is using Debian for their entire organization, etc.) who is willing to download firmware blobs from a trusted source (e.g., directly from the vendor), and then verify the Microsoft signature as a double check, and then resign it with their own signing authority key. To the extent that we could easily support this particular use case, it might be a good thing. (I doubt Debian is going to want to get into the business of verifying and then resigning firmware blobs.) Cheers, - Ted
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
Tollef Fog Heen writes ("Re: Bug#820036: No bug mentioning a Debian KEK and
booting use it."):
> ]] Ian Jackson
> > this is rather discouraging, at least for those who think this signed
> > image malarkey is useful.
>
> Just so we're not misunderstanding each other: I'd love for there to be
> something free in this space, and I think signed images are useful. My
> statement is just pointing out that (AFAIK), there aren't, and so
> spending effort that benefits no users doesn't sound like a terribly
> good way to expend effort. I'd love to be proven wrong about there
> being a free (and useful) implementation out there.
Yes, indeed.
I'm sorry for my use of the word `malarkey' which Wiktionary tells me
means some quite negative things. That's not what I meant. I just
meant something like `this signed image stuff'. I appreciate that
some people find it useful and wasn't meaning to say they were wrong.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
On Fri, 2016-10-21 at 14:44 +0800, Paul Wise wrote: > On Fri, Oct 21, 2016 at 2:35 PM, Ian Campbell wrote: > > > I think there are also physical arm64 systems using EDK2/Tianocore as > > their firmware. > > Unmodified upstream versions that you can re-flash? Some of the 96boards.org offerings I think? In a previous employment I had seen source for some other arm64 UEFI things, but I don't remember which ones were truly Open Source vs "I have seen the source" so I don't want to mislead by offering other possibilities, there might be people on the list who have a better grasp on reality than me... > I got the > impression most UEFI firmware is based on EDK2/Tianocore, even on x86, > but it has proprietary modifications. I think that's basically universally true on x86 and for a lot of arm64 systems, but arm64 seems to be a lot more open (due to Linaro's influence I guess). FWIW I'm not actually sure that the shipping x86 firmwares aren't actually based on some internal Intel thing which is more like a common ancestor of both those firmwares and Tianocore. It makes little practical difference here though. Ian.
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
On Fri, Oct 21, 2016 at 2:35 PM, Ian Campbell wrote: > I think there are also physical arm64 systems using EDK2/Tianocore as > their firmware. Unmodified upstream versions that you can re-flash? I got the impression most UEFI firmware is based on EDK2/Tianocore, even on x86, but it has proprietary modifications. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
On Fri, 2016-10-21 at 12:22 +0800, Paul Wise wrote: > On Fri, Oct 21, 2016 at 4:20 AM, Tollef Fog Heen wrote: > > > If there are machines with free firmware that also support secure boot, > > we can look at this. So far, I don't believe there are any. > > Tianocore (edk2 in Debian) supports virtual machines and also any > device that supports coreboot could chainload to Tianocore. > > https://wiki.ubuntu.com/SecurityTeam/SecureBoot > https://github.com/tianocore/tianocore.github.io/wiki/Coreboot_UEFI_payload I think there are also physical arm64 systems using EDK2/Tianocore as their firmware. Ian.
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
On Fri, Oct 21, 2016 at 4:20 AM, Tollef Fog Heen wrote: > If there are machines with free firmware that also support secure boot, > we can look at this. So far, I don't believe there are any. Tianocore (edk2 in Debian) supports virtual machines and also any device that supports coreboot could chainload to Tianocore. https://wiki.ubuntu.com/SecurityTeam/SecureBoot https://github.com/tianocore/tianocore.github.io/wiki/Coreboot_UEFI_payload -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
]] Ian Jackson
> Tollef Fog Heen writes ("Re: Bug#820036: No bug mentioning a Debian KEK and
> booting use it."):
>
> > So far, I don't believe there are any.
>
> this is rather discouraging, at least for those who think this signed
> image malarkey is useful.
Just so we're not misunderstanding each other: I'd love for there to be
something free in this space, and I think signed images are useful. My
statement is just pointing out that (AFAIK), there aren't, and so
spending effort that benefits no users doesn't sound like a terribly
good way to expend effort. I'd love to be proven wrong about there
being a free (and useful) implementation out there.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
Tollef Fog Heen writes ("Re: Bug#820036: No bug mentioning a Debian KEK and
booting use it."):
] Ian Jackson
> > Ah. Maybe it would be worth doing anyway. There might be machines
> > which work with some kind of libre firmware. But of course actually
> > doing this depends on someone having the effort.
>
> If there are machines with free firmware that also support secure boot,
> we can look at this.
That's a very sensible, even encouraging, response, thanks.
Of course on another level
> So far, I don't believe there are any.
this is rather discouraging, at least for those who think this signed
image malarkey is useful.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
]] Ian Jackson > Ah. Maybe it would be worth doing anyway. There might be machines > which work with some kind of libre firmware. But of course actually > doing this depends on someone having the effort. If there are machines with free firmware that also support secure boot, we can look at this. So far, I don't believe there are any. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
Paul Wise writes ("Re: Bug#820036: No bug mentioning a Debian KEK and booting
use it."):
> On Tue, Oct 18, 2016 at 7:36 PM, Ian Jackson wrote:
> > I'm afraid I can't make sense of this. You have posted it to
> > debian-devel, but without any kind of sensible explanation of the
> > context.
>
> It was posted to bug #820036, which is tracking Debian support for
> secure boot. Peter was advocating quite correctly that as well as
> having our copy of shim (the first-stage bootloader on secure boot
> systems) signed by Microsoft, we should also have a copy signed by a
> Debian signing authority, so that users can theoretically choose to
> distrust the Microsoft key. IIRC, unfortunately in practice that is
> unlikely to be possible since various firmware blobs are only
> Microsoft-signed.
Ah. Maybe it would be worth doing anyway. There might be machines
which work with some kind of libre firmware. But of course actually
doing this depends on someone having the effort.
Anyway, thanks for the explanation.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
On Tue, Oct 18, 2016 at 7:36 PM, Ian Jackson wrote: > I'm afraid I can't make sense of this. You have posted it to > debian-devel, but without any kind of sensible explanation of the > context. It was posted to bug #820036, which is tracking Debian support for secure boot. Peter was advocating quite correctly that as well as having our copy of shim (the first-stage bootloader on secure boot systems) signed by Microsoft, we should also have a copy signed by a Debian signing authority, so that users can theoretically choose to distrust the Microsoft key. IIRC, unfortunately in practice that is unlikely to be possible since various firmware blobs are only Microsoft-signed. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#820036: No bug mentioning a Debian KEK and booting use it.
Peter Dolding writes ("Bug#820036: No bug mentioning a Debian KEK and booting
use it."):
> Yes it one thing to get shim signed by Microsoft. Do remember
> Microsoft is free to push out updates to the The Forbidden Signatures
> Database(dbx).
>
> [etc.]
I'm afraid I can't make sense of this. You have posted it to
debian-devel, but without any kind of sensible explanation of the
context.
Ian.
Bug#820036: No bug mentioning a Debian KEK and booting use it.
Yes it one thing to get shim signed by Microsoft. Do remember Microsoft is free to push out updates to the The Forbidden Signatures Database(dbx). Sign a new shim in case of current one being black listed for some reason could take weeks/months from Microsoft. The process to replace PK(platform key) and replace the KEK can be done faster than getting a new shim. Its also a safe guard against Microsoft changing the rules how shims are constructions. Please be aware when Microsoft signing shims they do not use the KEK that is used to sign the windows boot loader. So windows bootloaders are signed with Microsoft Windows Production PCA 2011 and debian shim will be signed with Microsoft Corporation UEFI CA 2011. https://technet.microsoft.com/en-au/library/dn747883.aspx Now there is a line to OEM that should worry the heck out of us. ---On non-Windows RT PCs the OEM should consider including the Microsoft Corporation UEFI CA 2011--- Key words "should consider" so making the "Microsoft Corporation UEFI CA" key and everything signed by optional if it works or not. Microsoft does not mandate OEM install "Microsoft Corporation UEFI CA" only the "Microsoft Windows Production PCA" the one the debian shim will not be signed with .So getting the shim signed by Microsoft does not promise it works on every motherboard. Manually installing Microsoft Corporation UEFI CA if OEM did not include is replace PK(platform key) and upload new KEK set. At this point might has well have the set of processes to install own KEK and will require to provide users with the complete instructions to replace the PK anyhow. Also there appears to be no bug saying to put a system in place to check that the shim had not been added revocation list as Microsoft publishes it here http://www.uefi.org/revocationlistfile to allow early response in case for some reason shim gets blacklist. Secureboot is a mess. A single plan is not going to work.2 plans are required. 1) A signed shim by Microsoft to reduce the number of people who have to replace PK at first. 2) A plan to replace PK and use own KEK set containing the KEKs debian needs. The interesting point from Microsoft OEM documentation is the PK(platform key) rules. Yes this is again https://technet.microsoft.com/en-au/library/dn747883.aspx 1.3.3.3 PK generation Two entries of very big interest. --One per product line. If a key is compromised a whole product line would be vulnerable-- And --One per OEM. While this may be the simplest to set up, if the key is compromised, every PC you manufacture would be vulnerable. To speed up operation on the factory floor, the PK and potentially other keys could be pre-generated and stored in a safe location. -- Debian is a product line or a OEM right so Debian install images can ship with it own premade PK and KEK set/sets so user if required can delete the PK and attempt an alternate functional set particularly if the motherboard lacks the KEK the shim needs .Of course this does not stop users making their own PK and KEK set latter and it not against the rules to-do this. Peter Dolding
