fscryptctl: add support for adding key by serial (ID)#23
Open
a3f wants to merge 1 commit intogoogle:masterfrom
Open
fscryptctl: add support for adding key by serial (ID)#23a3f wants to merge 1 commit intogoogle:masterfrom
a3f wants to merge 1 commit intogoogle:masterfrom
Conversation
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jul 27, 2021
For both v1 and v2 key setup mechanisms, userspace supplies the raw key material to the kernel after which it is never again disclosed to userspace. Use of encrypted and trusted keys offers stronger guarantees: The key material is generated within the kernel and is never disclosed to userspace in clear text and, in the case of trusted keys, can be directly rooted to a trust source like a TPM chip. Add support for trusted and encrypted keys by repurposing fscrypt_add_key_arg::raw to hold the key description when the new FSCRYPT_KEY_ARG_TYPE_DESC flag is supplied. The location of the flag was previously reserved and enforced by ioctl code to be zero, so this change won't break backwards compatibility. Corresponding userspace patches are available for fscryptctl: google/fscryptctl#23 Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Author
|
@googlebot I signed it! |
Since Linux commit 93edd392ca ("fscrypt: support passing a keyring key
to FS_IOC_ADD_ENCRYPTION_KEY"), it's possible to pass the key ID of
a "fscrypt-provisioning" key that Linux should retrieve the raw key
material from instead of passing it directly from userspace.
This is useful to add fscrypt keys after unmounting and re-mounting.
It would also prove useful should additional key types like trusted keys
be allowed in future.
Thus add a new --serial parameter to add_key to facilitate this.
--serial was chosen over --id to avoid confusion with the KEY_IDENTIFIER
used in the remove_key, key_status and set_policy documentation, which
it is not interchangeable with.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Since Linux commit torvalds/linux@93edd392ca ("fscrypt: support passing a keyring key
to FS_IOC_ADD_ENCRYPTION_KEY"), it's possible to pass the key ID of
a "fscrypt-provisioning" key that Linux should retrieve the raw key
material from instead of passing it directly from userspace.
This is useful to add fscrypt keys after unmounting and re-mounting.
It would also prove useful should additional key types like trusted keys
be allowed in future.
Thus add a new
--serialparameter toadd_keyto facilitate this.--serialwas chosen over--idto avoid confusion with theKEY_IDENTIFIERused in the
remove_key,key_statusandset_policydocumentation, whichit is not interchangeable with.
This is PR is applicable regardless of my patch for adding fscrypt support for
trusted keys.
Should a revised version of that patch be applied, I'll create a new pull request to adjust the documentation here appropriately. There is no code change necessary however, because the API used for fscrypt-provisioning keys is reused.