Re: [RFC PATCH v1 3/6] schema: Extend schema for TPM emulator profile node
On 9/24/24 4:35 AM, Daniel P. Berrangé wrote:
On Mon, Sep 23, 2024 at 01:30:50PM -0400, Stefan Berger wrote:
>
>
> On 9/23/24 12:55 PM, Daniel P. Berrangé wrote:
>> On Fri, Sep 20, 2024 at 10:00:40AM -0400, Stefan Berger wrote:
>>>
>>>
>>> On 9/20/24 8:55 AM, Daniel P. Berrangé wrote:
>>>> Instead I think there should be a defined standard for how an distro
>>>> package, or host sysadmin, would "drop in" a profile definition
to
>>>> a well defined directory, where upon we can reference it by name in
>>>> libvirt,
>>>>
>>>> eg define two dirs
>>>>
>>>> /usr/share/swptm/profiles/<name>.json (for os distro)
>>>> /etc/swptm/profiles/<name>.json (for local
deployment)
>>>
>>> With the above:
>>>
>>> <profile name='null' type='built-in'/>
>>> <profile name='default-v1' type='built-in'/>
>>> <profile name='custom' type='built-in'
remove_disabled='check'/>
>>>
>>> <profile name='restricted' type='distro'/> -->
name is a filename now
>>> <profile name='test' type='local'
remove_disabled='check'/> --> name is a
>>> filename now
>>
>> Do we really need to express a "type" attribute ? How about if
>> swtpm itself were to load profiles from the /usr/share/swtpm
>> and /etc/swtpm directories, so that from a users' POV there
>> is no distinction between built-in & file defined profiles ?
>>
>> I guess you want to resolve naming clashes. A couple of options
>>
>> - <name>.json in /etc/ overrides <name>.json in /usr/
>> which overrides <name> built-in.
>>
>
> I think this makes it easier for a user to choose from:
>
> <profile builtin="null"/>
> <profile builtin="default-v1"/>
> <profile builtin=custom" remove_disabled='check'/>
> <profile distro='restricted'/>
> <profile local='test' remove_disabled='check'/>
I think that creates unneccessary upgrade drama. Consider that new
swtpm defines a new built-in profile "default-v3", but your current
host does not have "default-v3" as a built-in profile. You should
Exactly these default-v{1,2,3,...} profiles will all be built into
libtpms and the latest one will be activated if the user chooses no
profile when starting swtpm the first time and it creates initial state.
swtpm_setup, which is used to 'manufacture' a TPM, tries to read a
default profile from its configuration file (/etc/swtpm_setup.conf) and
set that one if the user didn't provide one on the swtpm_setup command
line. If nothing is set it's back to the default-v{1,..} profile on
libtpms level enabling the latest crypto algorithms the TPM 2 supports.
The profile default-v3 would be there because new crypto algorithms etc,
were added to (future) libtpms v0.12 and they are then enable in this
profile. If there weren't any new crypto algorithms or other verbs added
to the profile language, libtpms would still be offering only default-v2
(from future libtpms v0.11 presumably). So you will need to have
(future) v0.12 of libtpms to run default-v3. And it won't be possible to
run this instance on a previous version of libtpms, for this you would
have to pick an older default-v{1,2} profile that will still be made
available as built-in's.
Maybe a search order through directories should be supported on the
swtpm_setup level using its configuration file that is either picked up
from /etc/swtpm_local.conf or ~/.config/swtpm_setup.conf where one can
then specify a local and a distro directory (or the distro one hardcoded
in swtpm_setup?) for profiles to search through.
The tricky part about other than the built-in profiles will be to decide
which algorithms to disable without upsetting applications. But I agree,
access to local or distro profiles will be useful along with
'swtpm_setup --tpm2 --print-profiles' for displaying them. I was going
to do the directory configuration on the libvirt level...
> be able to define that as a local profile or system profile with
> the same name, and have an upgrade path to future swtpm which has
> it as a built-in profile *without* having to change the XML. >
>
> With regards,
> Daniel