[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json"
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json" |
Date: |
Wed, 18 Apr 2018 16:03:03 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
On 04/18/18 15:53, Daniel P. Berrangé wrote:
> On Wed, Apr 18, 2018 at 03:30:36PM +0200, Laszlo Ersek wrote:
>> On 04/18/18 15:06, Gerd Hoffmann wrote:
>>>>> Other question: Do we want allow to specify which certs/keys are
>>>>> enrolled? Which would probably mean to drop "enrolled-keys" from
>>>>> features and make it an optional string instead,
>>>>
>>>> Not an enum? "Microsoft" below should be an enum constant, shouldn't it?
>>>
>>> I don't think so. If we want allow other certificate providers (not
>>> sure it makes sense as all physical hardware actually runs with the
>>> microsoft certificates), then we don't want a fixed list here. So any
>>> CA can be listed, be it microsoft, redhat, canonical, verisign or
>>> kraxel.org ;)
>>
>> I agree (obviously), but then, at what detail do we stop?
>>
>> Because, if we go for full flexibility, then we should formalize:
>> - the certificate that goes into PK,
>> - the list of certificates that go into KEK,
>> - the list of certificates that go into db,
>>
>> and we should likely formalize "certificate" itself as the following pair:
>> - human-readable description (possibly the Common Name of the Subject),
>> - SHA256 digest (fingerprint) of the certificate.
>>
>> I do think this would totally be overkill, but I don't know where to
>> draw the line
>> - between the currently proposed @enrolled-keys (or similar enums that
>> stand for well-defined "constellations")
>> - and the full details as described above.
>>
>> A simple string like "Microsoft" doesn't seem to me helpful for either
>> the user or management software -- the former won't know what
>> "Microsoft" stands for, and the latter won't want to look for free-form
>> strings. (Same issue as with @tags vs. @features.)
>
> Ignoring secboot cert name for a minute, ultimately no matter what we do
> in terms of metadata there is always going to be the possibility that
> many firmware images all match the criteria libvirt is searching on.
>
> Apps thus need rules to pick one of the many matches, and users need the
> ability to override distro defaults. We can achieve that as follows:
>
> Recommend that firmware files are created with a double-digit prefix
> eg 50-ovmf.json 50-seabios-256k.json, etc, etc, so they can be
> sorted in predictable order
>
> Second, we should define three well known directory locations
>
> - /usr/share/qemu/firmware (used by distros packages)
> - /etc/qemu/firmware (exclusively for sysadmin local additions)
> - $HOME/.config/qemu/firmware (exclusively for per-user local additions)
>
> Apps like libvirt should build list of files from all three locations,
> then sort by filename. If a local directory has a file with same
> name as the distro directory, then it should replace the distro provided
> file. A zero length file should be simply hide the distro provided file
>
> So for example, distro ships
>
> /usr/share/qemu/firmware/50-ovmf.json
> /usr/share/qemu/firmware/50-seabios-256k.json
>
> The sysadmin can now prevent the default ovmf being used at all with
>
> $ touch /etc/qemu/firmware/50-ovmf.json
>
> The sysadmin can replace/alter the distro default ovmf with
>
> $ vim /etc/qemu/firmware/50-ovmf.json
>
> Or they can provide a parallel ovmf with higher priority
>
> $ vim /etc/qemu/firmware/10-ovmf.json
>
> Or they can provide a parallel ovmf with lower priority
>
> $ vim /etc/qemu/firmware/99-ovmf.json
>
> $HOME/.config/qemu/firmware would take prior over /etc/qemu and
> /usr/share/qemu.
>
>
> Getting back to the question of many ovmf images with various different
> secboot keys. The distro can now provide many ovmf images each with
> different keys, if desired and determine which one is picked by default.
>
> The end user can provide their over ovmf with personal keys that replaces
> the distro microsoft enrolled one entirely, etc.
>
> IOW, don't think we need to record which certs are use for secboot in
> the JSON metadata. Just lets overrides & ordering take care of it.
OK, thank you. Three more questions:
- Would you like me to capture the directory paths in the firmware.json
file, or in the commit message for the patch?
- Should we keep @secure-boot-enrolled-keys (or, as Gerd suggests,
@enrolled-keys) in the schema, as a feature enum constant, but remove
the documentation of the actual certificates? (I.e., say "an
unspecified set of certificates has been enrolled and SB mode has been
enabled".)
- Or else, should we drop the feature flag that stands for enrollment
completely?
Thanks,
Laszlo
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", (continued)
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Laszlo Ersek, 2018/04/18
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Daniel P . Berrangé, 2018/04/18
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Gerd Hoffmann, 2018/04/18
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Daniel P . Berrangé, 2018/04/18
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Laszlo Ersek, 2018/04/18
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Gerd Hoffmann, 2018/04/18
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Laszlo Ersek, 2018/04/18
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Gerd Hoffmann, 2018/04/18
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Laszlo Ersek, 2018/04/18
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Daniel P . Berrangé, 2018/04/18
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json",
Laszlo Ersek <=
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Daniel P . Berrangé, 2018/04/18
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Laszlo Ersek, 2018/04/18
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", David Gibson, 2018/04/18
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Laszlo Ersek, 2018/04/19
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", David Gibson, 2018/04/19
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Paolo Bonzini, 2018/04/20
- Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Laszlo Ersek, 2018/04/20
Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Thomas Huth, 2018/04/19
Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json", Markus Armbruster, 2018/04/18