From: Laszlo Ersek <lersek@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>
Cc: ipxe-devel@lists.ipxe.org, qemu-devel@nongnu.org, crobinso@redhat.com
Subject: Re: https booting
Date: Wed, 22 Jul 2020 20:47:19 +0200 [thread overview]
Message-ID: <05b7332c-cea1-dacc-5082-ffbfb8fb13b5@redhat.com> (raw)
In-Reply-To: <20200722141318.GJ2324845@redhat.com>
On 07/22/20 16:13, Daniel P. Berrangé wrote:
> On Wed, Jul 22, 2020 at 03:55:38PM +0200, Gerd Hoffmann wrote:
>>>> How does edk2 handle the root ca problem?
>>>
>>> There are two fw_cfg paths
>>>
>>> - etc/edk2/https/ciphers
>>> - etc/edk2/https/cacerts
>>>
>>> The first sets the cipher algorithms that are permitted and their
>>> priority, the second sets the CA certificate bundle.
>>
>> Ok, ipxe should be able to fetch them. Would be roughly the same as
>> compiling in the certificates, except that they don't take up space in
>> the rom and are much easier to update.
>
>
>
>>
>> What is in cacerts?
>> Basically /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem of the host
>> machine?
>
> Not that file exactly. Instead
>
> /etc/pki/ca-trust/extracted/edk2/cacerts.bin
>
> which is the same certs, but in a different format:
>
> [quote man update-ca-trust]
> The directory /etc/pki/ca-trust/extracted/edk2/ contains a
> CA certificate bundle ("cacerts.bin") in the "sequence of
> EFI_SIGNATURE_LISTs" format, defined in the UEFI-2.7
> specification, sections "31.4.1 Signature Database" and
> "EFI_CERT_X509_GUID". Distrust information cannot be
> represented in this file format, and distrusted certificates
> are missing from these files. File "cacerts.bin" contains CA
> certificates trusted for TLS server authentication.
> [/quote]
>
> On Fedora/RHEL the "update-ca-trust" tool creates the file in this
> format automatically now.
>
> I don't know if that's a useful format for iPXE or not.
>
> We could easily define etc/ipxe/https/{ciphers,cacerts} paths in a
> different format if better suited for iPXE.
I agree.
The p11-kit extractor for edk2 was implemented in p11-kit commit range ba6ebb05fc0c..de963b96929b:
https://github.com/p11-glue/p11-kit/commit/59054e4f9fe3
https://github.com/p11-glue/p11-kit/commit/ee27f9153a14
https://github.com/p11-glue/p11-kit/commit/de963b96929b
https://github.com/p11-glue/p11-kit/pull/137
https://github.com/p11-glue/p11-kit/pull/139
The dependent "update-ca-trust" changes are here:
https://src.fedoraproject.org/rpms/ca-certificates/c/6220683f7640?branch=master
https://src.fedoraproject.org/rpms/ca-certificates/c/34c0da9058d6?branch=master
I think these commits could be used as model for an "iPXE extractor" if necessary.
Thanks,
Laszlo
> Libvirt can set the right
> path depending on whether its booting a VM with EDK2 vs legacy BIOS
>
> Regards,
> Daniel
>
next prev parent reply other threads:[~2020-07-22 18:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-22 12:08 https booting Gerd Hoffmann
2020-07-22 12:23 ` Daniel P. Berrangé
2020-07-22 13:55 ` Gerd Hoffmann
2020-07-22 14:13 ` Daniel P. Berrangé
2020-07-22 18:47 ` Laszlo Ersek [this message]
2020-07-24 16:19 ` [ipxe-devel] " Michael Brown
2020-08-03 7:37 ` Gerd Hoffmann
2020-07-22 13:21 ` Michael Brown
2020-07-22 13:45 ` Michael Brown
2020-08-03 8:04 ` Gerd Hoffmann
2020-07-22 18:34 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=05b7332c-cea1-dacc-5082-ffbfb8fb13b5@redhat.com \
--to=lersek@redhat.com \
--cc=berrange@redhat.com \
--cc=crobinso@redhat.com \
--cc=ipxe-devel@lists.ipxe.org \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).