Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for file-backend locking #932

Merged
merged 8 commits into from
Oct 15, 2024

Conversation

stefanberger
Copy link
Owner

This PR adds support for optional file-backend locking using a new lock option parameter that is to be used with the --tpmstate option.

@stefanberger
Copy link
Owner Author

@elmarco @berrange This PR adds file-backend storage locking.

Since 0 is a valid file descriptor and checks for valid file descriptors
is typically '>= 0', initialize the file descriptor to -1 to indicate
that it is unused.

Signed-off-by: Stefan Berger <[email protected]>
Remove the broken logic to check for neither dir:// nor file:// backend.
If an unknow backend type is used, then it will be detected later on
and an error message will be printed out. Even though the logic was
broken it didn't seem to cause failures.

Also have tpmstate_set_mode return void since it cannot fail.

Signed-off-by: Stefan Berger <[email protected]>
@stefanberger stefanberger force-pushed the stefanberger/add_support_for_filebackend_lock branch from dd01c38 to 0b1c03e Compare October 14, 2024 21:52
@elmarco
Copy link
Contributor

elmarco commented Oct 15, 2024

LGTM, although patches ordering and atomicity isn't optimal, np

Add support for locking the storage file using fcntl(fd, F_SETLK, ...).
Since fcntl needs a file descriptor of the actual storage file, call
SWTPM_NVRAM_LinearFile_DoOpenURI() to open the file in case it has not
been opened, yet. In case of error close the file again but be careful
about the fact that it may not have been mmap'ed, yet.

Since now all backends have .lock and .unlock nvram_backend_ops, they can
be called without checking for a NULL pointer.

Extend an existing test case with a file-backend storage lock test.

Signed-off-by: Stefan Berger <[email protected]>
To support storage backend locking on the file backend, add support for a
lock option parameter to the --tpmstate option. By default the value of
this option (if not given) has to be 'true' for the dir backend, since this
backend has always been locking, and 'false' on the file backend, since
this backend did not lock so far.

If the user chooses no storage backend locking then SWTPM_NVRAM_Unlock &
SWTPM_NVRAM_Lock_Storage do not call the backend for locking at all
anymore.

Document the new option parameter in the swtpm man page.

Signed-off-by: Stefan Berger <[email protected]>
Display the new capability tpmstate-opt-lock, adjust test cases,
and document it in the swptm man page.

Signed-off-by: Stefan Berger <[email protected]>
@stefanberger stefanberger force-pushed the stefanberger/add_support_for_filebackend_lock branch from 0b1c03e to b82cbf3 Compare October 15, 2024 13:17
@stefanberger
Copy link
Owner Author

LGTM, although patches ordering and atomicity isn't optimal, np

Reordered the patches. With cli option support coming now after the enablement of file backend locking this should take care of the issue.Will merge soon.

I haven't used this backend much. So needs some extra testing in libvirt environment with suspend/resume etc..

@stefanberger stefanberger merged commit 1eb06b6 into master Oct 15, 2024
5 checks passed
@stefanberger stefanberger deleted the stefanberger/add_support_for_filebackend_lock branch October 15, 2024 14:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants