From: Eric Biggers <ebiggers@kernel.org>
To: linux-block@vger.kernel.org, linux-fscrypt@vger.kernel.org
Cc: kernel-team@android.com, Israel Rukshin <israelr@nvidia.com>
Subject: [RFC PATCH v7 0/4] Support for hardware-wrapped inline encryption keys
Date: Fri, 16 Dec 2022 12:36:32 -0800 [thread overview]
Message-ID: <20221216203636.81491-1-ebiggers@kernel.org> (raw)
[ This patchset is based on mainline commit 77856d911a8c.
It can also be retrieved from the tag "wrapped-keys-v7"
https://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git ]
This patchset adds the block and fscrypt support for hardware-wrapped
inline encryption keys, a security feature supported by recent Qualcomm
and Google SoCs. Unfortunately, although this feature has already been
working in Android for several years (with some slight differences in
the software design), the SoC-specific software support needed to
actually test and use this feature end-to-end with the upstream kernel
continues to not be ready, mostly for reasons outside my control.
Therefore, I've downgraded this patchset back to a RFC. Nevertheless,
I'd greatly appreciate feedback on it.
This feature is described in full detail in the included Documentation
changes. But to summarize, hardware-wrapped keys are inline encryption
keys that are wrapped (encrypted) by a key internal to the hardware so
that they can only be unwrapped (decrypted) by the hardware. Initially
keys are wrapped with a permanent hardware key, but during actual use
they are re-wrapped with a per-boot ephemeral key for improved security.
The hardware supports importing keys as well as generating keys itself.
This feature protects encryption keys from read-only compromises of
kernel memory, such as that which can occur during a cold boot attack.
It does this without limiting the number of keys that can be used, as
would be the case with solutions that didn't use key wrapping.
This differs from the existing support for hardware-wrapped keys in the
kernel crypto API (which also goes by names such as "hardware-bound
keys", depending on the driver) in the same way that the crypto API
differs from blk-crypto: the crypto API is for general crypto
operations, whereas blk-crypto is for inline storage encryption.
Changed v6 => v7:
- Rebased onto latest mainline.
- Fixed a bug in fscrypt_prepare_inline_crypt_key().
- Other cleanups.
Changed v5 => v6:
- Downgraded the patchset back to RFC status.
- Exposed the supported key types in sysfs.
- Shortened some field names, e.g. longterm_wrapped_key => lt_key.
- Avoided adding a new use of struct request_queue by fs/crypto/.
- Moved the blk-crypto ioctls to a new blk-crypto UAPI header file
and fixed their numbering.
- Other cleanups.
Changed v4 => v5:
- Dropped the RFC tag, now that these patches are actually testable.
- Split the BLKCRYPTOCREATEKEY ioctl into BLKCRYPTOIMPORTKEY and
BLKCRYPTOGENERATEKEY. (I'm thinking that these operations are
distinct enough that two separate ioctls would be best.)
- Added some warning messages in fscrypt_derive_sw_secret().
- Rebased onto v5.17-rc6.
Changed v3 => v4:
- Rebased onto v5.16-rc1 and dropped a few bits that were upstreamed.
- Updated cover letter to link to Gaurav's UFS driver patchset.
Changed v2 => v3:
- Dropped some fscrypt cleanups that were applied.
- Rebased on top of the latest linux-block and fscrypt branches.
- Minor cleanups.
Changed v1 => v2:
- Added new ioctls for creating and preparing hardware-wrapped keys.
- Rebased onto my patchset which renames blk_keyslot_manager to
blk_crypto_profile.
Eric Biggers (4):
blk-crypto: add basic hardware-wrapped key support
blk-crypto: show supported key types in sysfs
blk-crypto: add ioctls to create and prepare hardware-wrapped keys
fscrypt: add support for hardware-wrapped keys
Documentation/ABI/stable/sysfs-block | 18 ++
Documentation/block/inline-encryption.rst | 245 +++++++++++++++++-
Documentation/filesystems/fscrypt.rst | 154 +++++++++--
.../userspace-api/ioctl/ioctl-number.rst | 4 +-
block/blk-crypto-fallback.c | 5 +-
block/blk-crypto-internal.h | 10 +
block/blk-crypto-profile.c | 119 +++++++++
block/blk-crypto-sysfs.c | 35 +++
block/blk-crypto.c | 194 +++++++++++++-
block/ioctl.c | 5 +
drivers/md/dm-table.c | 1 +
drivers/mmc/host/cqhci-crypto.c | 2 +
drivers/ufs/core/ufshcd-crypto.c | 1 +
fs/crypto/fscrypt_private.h | 71 ++++-
fs/crypto/hkdf.c | 4 +-
fs/crypto/inline_crypt.c | 67 ++++-
fs/crypto/keyring.c | 122 ++++++---
fs/crypto/keysetup.c | 54 +++-
fs/crypto/keysetup_v1.c | 5 +-
fs/crypto/policy.c | 11 +-
include/linux/blk-crypto-profile.h | 73 ++++++
include/linux/blk-crypto.h | 78 +++++-
include/uapi/linux/blk-crypto.h | 44 ++++
include/uapi/linux/fs.h | 6 +-
include/uapi/linux/fscrypt.h | 7 +-
25 files changed, 1235 insertions(+), 100 deletions(-)
create mode 100644 include/uapi/linux/blk-crypto.h
base-commit: 77856d911a8c8724ee8e2b09d55979fc1de8f1c0
--
2.38.1
next reply other threads:[~2022-12-16 20:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 20:36 Eric Biggers [this message]
2022-12-16 20:36 ` [RFC PATCH v7 1/4] blk-crypto: add basic hardware-wrapped key support Eric Biggers
2022-12-16 20:36 ` [RFC PATCH v7 2/4] blk-crypto: show supported key types in sysfs Eric Biggers
2022-12-16 20:36 ` [RFC PATCH v7 3/4] blk-crypto: add ioctls to create and prepare hardware-wrapped keys Eric Biggers
2022-12-16 20:36 ` [RFC PATCH v7 4/4] fscrypt: add support for " Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221216203636.81491-1-ebiggers@kernel.org \
--to=ebiggers@kernel.org \
--cc=israelr@nvidia.com \
--cc=kernel-team@android.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).