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
