A-Team_Digital_Solutions/android_kernel_motorola_sm6375
Watch
2
0
Fork
You've already forked android_kernel_motorola_sm6375
 0
mirror of https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git synced 2026-10-30 03:27:44 -04:00
Code Issues Projects Releases Packages Wiki Activity

Merge fbe changes from upstream 5.4

Browse source 
b7b3af9 BACKPORT: FROMLIST: Update Inline Encryption from v5 to v6 of patch series
4f6a1f4 ANDROID: ufshcd-crypto: export cap find API
e25d82c ANDROID: block: provide key size as input to inline crypto APIs
3e8cceb ANDROID: block: add KSM op to derive software secret from wrapped key
8173487 ANDROID: fscrypt: add support for hardware-wrapped keys
8aaaa67 ANDROID: block: fix some inline crypto bugs
9f8ee7b ANDROID: block: export symbols needed for modules to use inline crypto
0faba9a FROMLIST: scsi: ufs: add program_key() variant op
403731b ANDROID: ext4, f2fs: enable direct I/O with inline encryption
1fc06ba ANDROID: block: Introduce passthrough keyslot manager
695cfeb ANDROID: dm: add support for passing through inline crypto support
85942bc ANDROID: dm: enable may_passthrough_inline_crypto on some targets
5515324 ANDROID: dm: add dm-default-key target for metadata encryption
792b182 ANDROID: gki_defconfig: enable dm-default-key
3ab1972 ANDROID: block: Prevent crypto fallback for wrapped keys
a142356 ANDROID: dm: add support for passing through derive_raw_secret
0dccdc0 ANDROID: dm: Add wrapped key support in dm-default-key

Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-5.4
Change-Id: Ida31c27ac24457efc1aa0343806e2f32a056167b
Signed-off-by: Gaurav Kashyap <[email protected]>
This commit is contained in:
Satya Tangirala 2019-12-17 14:26:29 -08:00 • committed by Gaurav Kashyap
commit c83b552741
50 changed files with 48070 additions and 46599 deletions
Download patch file Download diff file Expand all files Collapse all files

8
Documentation/block/inline-encryption.rst
View file

@ -97,7 +97,7 @@ Blk-crypto ensures that:
- The bio's encryption context is programmed into a keyslot in the KSM of the
request queue that the bio is being submitted to (or the crypto API fallback
KSM if the request queue doesn't have a KSM), and that the ``processing_ksm``
KSM if the request queue doesn't have a KSM), and that the ``bc_ksm``
in the ``bi_crypt_context`` is set to this KSM
- That the bio has its own individual reference to the keyslot in this KSM.
@ -107,7 +107,7 @@ Blk-crypto ensures that:
ensuring that the bio has a valid reference to the keyslot when, for e.g., the
crypto API fallback KSM in blk-crypto performs crypto on the device's behalf.
The individual references are ensured by increasing the refcount for the
keyslot in the ``processing_ksm`` when a bio with a programmed encryption
keyslot in the ``bc_ksm`` when a bio with a programmed encryption
context is cloned.
@ -120,7 +120,7 @@ been programmed into any keyslot in any KSM (for e.g. a bio from the FS).
request queue the bio is being submitted to (and if this KSM does not exist,
then it will program it into blk-crypto's internal KSM for crypto API
fallback). The KSM that this encryption context was programmed into is stored
as the ``processing_ksm`` in the bio's ``bi_crypt_context``.
as the ``bc_ksm`` in the bio's ``bi_crypt_context``.
**Case 2:** blk-crypto is given a bio whose encryption context has already been
programmed into a keyslot in the *crypto API fallback* KSM.
@ -138,7 +138,7 @@ KSM).
This way, when a device driver is processing a bio, it can be sure that
the bio's encryption context has been programmed into some KSM (either the
device driver's request queue's KSM, or blk-crypto's crypto API fallback KSM).
It then simply needs to check if the bio's processing_ksm is the device's
It then simply needs to check if the bio's ``bc_ksm`` is the device's
request queue's KSM. If so, then it should proceed with IE. If not, it should
simply do nothing with respect to crypto, because some other KSM (perhaps the
blk-crypto crypto API fallback KSM) is handling the en/decryption.