[LU-12275] Client-side file data encryption

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.14.0
• Fix Version/s: Lustre 2.14.0
• Type: New Feature
• Priority: Critical
• Reporter: Sebastien Buisson
• Assignee: Sebastien Buisson
• Resolution: Fixed
• Labels: encryption, sec

Description

This ticket is a place-holder to describe work to be done for client-side encryption.

The high-level requirements are the following:

• encrypt file content
• encrypt file name
• have a master key for encryption
  • per-file encryption key derived from master key
  • file data is no longer accessible after file is deleted
• able to change the user key without re-encrypting files
• deny access to encrypted data when master key is removed from memory on the client
• work in "batch scheduler" mode

We are proposing to address these requirements by:

• conforming to fscrypt kernel API
  • https://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt.git/tree/Documentation/filesystems/fscrypt.rst
  • https://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt.git/tree/fs/crypto
  • current users are ext4, F2FS, and UBIFS
  • https://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt.git/tree/include/linux/fscrypt.h
  • need to use newly pushed policy v2
  • https://patchwork.kernel.org/patch/10806461/
  • https://www.spinics.net/lists/linux-fscrypt/msg01357.html
• relying on ext4 encryption principles
  • file system block size = system page size
  • each filesystem block is encrypted independently in a separate block
  • pages in the page cache always contain clear text data
• mutualizing code infrastructure with compression work
  • same kind of operations, at same code locations

So the workflow would be the following:

• applications see clear text
• data is encrypted before being sent to servers
  • then remain untouched
• data is decrypted upon receipt from servers
  • untouched before that
• servers only see encrypted data
  • but do not need to be aware of it
• only client nodes have access to encryption keys

Further details will be added as the feature design makes progress.

Issue Links

• is related to: LU-16091 Set S_ENCRYPTED flag on OST objects f...
• is related to: LUDOC-477 Add documentation for client-side enc...
• is related to: LU-15003 use client enc_pool for fscrypt
• is related to: LU-14677 lfs migrate/mirror of encrypted files
• is related to: LU-7371 Wrong read length over isize
• is related to: LU-14045 Fix O_DIRECT and encrypted files
• is related to: LU-14149 FIEMAP should set FIEMAP_EXTENT_DATA_...
• is related to: LU-16085 Ubuntu 22.04 sanityn test_106c: suppo...
• is related to: LU-16091 Set S_ENCRYPTED flag on OST objects f...
• is related to: LU-13717 Client-side encryption - support file...

Comments

[Sebastien Buisson]

lustre_encryption_threat_model.txt is the description of the threat model for Lustre client-side encryption.
As we want to use kernel's fscrypt library for this feature, fscrypt's threat model is largely valid. This document is inspired from code submitted by Eric Biggers in his fscrypt-key-mgmt-improvements-v6 branch.
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/tree/Documentation/filesystems/fscrypt.rst?h=fscrypt-key-mgmt-improvements-v6

[Sebastien Buisson]

lustre_encryption_key_hierarchy.txt is the description of the key hierarchy for Lustre client-side encryption.
As we want to use kernel's fscrypt library for this feature, fscrypt's key hierarchy is largely valid. This document is inspired from code submitted by Eric Biggers in his fscrypt-key-mgmt-improvements-v6 branch.
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/tree/Documentation/filesystems/fscrypt.rst?h=fscrypt-key-mgmt-improvements-v6

[Sebastien Buisson]

lustre_encryption_modes_usage.txt is the description of the encryption modes and usage for Lustre client-side encryption.
As we want to use kernel's fscrypt library for this feature, fscrypt's description of encryption modes and usage is largely valid. This document is inspired from code submitted by Eric Biggers in his fscrypt-key-mgmt-improvements-v6 branch.
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/tree/Documentation/filesystems/fscrypt.rst?h=fscrypt-key-mgmt-improvements-v6

[Sebastien Buisson]

lustre_encryption_access_semantics.txt is the description of the access semantics for Lustre client-side encryption.
As we want to use kernel's fscrypt library for this feature, fscrypt's description of access semantics is largely valid. This document is inspired from code submitted by Eric Biggers in his fscrypt-key-mgmt-improvements-v6 branch.
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/tree/Documentation/filesystems/fscrypt.rst?h=fscrypt-key-mgmt-improvements-v6

[Andreas Dilger]

relying on ext4 encryption principles

• file system block size = system page size
• each filesystem block is encrypted independently in a separate block

It would be better to not tie the encryption directly to the filesystem blocksize, if possible, as this would break the network transparency of the filesystem compared to the backend storage. Also, for ZFS, the blocksize may be up to 1MB and possibly variable per file and per stripe of the file, while the ext4 blocksize is only 4KB. Instead, if we can pick a fixed blocksize for the crypto like 32KB, similar to how the data compression is done. Instead of using the block number as the IV, it should use the byte offset as the IV, since this is agnostic of the blocksize.

The drawback is that we may have to write/allocate a larger portion of the files data (rounded up to 32KB or similar), but this would already be true if we are using a feature like bigalloc on ext4, or recordsize for ZFS.

[Andreas Dilger]

In particular, currently there is no requirement to support unlocking a file
with multiple alternative master keys or to support rotating master keys.

I thought this was one of the features we were interested in having?

[Sebastien Buisson]

Being able to encrypt/decrypt a directory with multiple different keys is definitely something we would like to propose. But if we want to have it directly at the Lustre level, it means we cannot rely on fscrypt.

However, basing the Lustre client encryption feature on fscrypt kernel API means we would be able to leverage the fscrypt userspace tool https://github.com/google/fscrypt. This tool enables to manipulate encryption policies on directories, and makes use of key wrapping. One of the benefits of this technique is to support using multiple protectors for a policy:
https://github.com/google/fscrypt#using-multiple-protectors-for-a-policy

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/36143
Subject: LU-12275 sec: enable client encryption flag
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 14558d3d99362697deeee57e02618d5a2dd88e30

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/36144
Subject: LU-12275 sec: encryption for write path
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: da9ea1a9fd9b29608c9ce3bde8191abd4f74b98f

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/36145
Subject: LU-12275 sec: decryption for read path
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: ddd2bd2e44c7c5e661ef793dc4a78f17c56cae29

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/36146
Subject: LU-12275 sec: deal with encrypted object size
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 16ff787abef944b803f88f9acfd312cfeabf792a

[Patrick Farrell (Inactive)]

sebastien, what's your plan for tests for these?  I note that none of the patches seem to have tests today.  Are you planning to add a bunch of tests in a separate patch, or tests to each patch, etc?  They're also helpful for review because they show the reviewer the interface(s).

[Sebastien Buisson]

Given that all 4 patches are just here to serve one purpose, which is doing IOs (write and read) on encrypted files, I was planning to add a separate patch after them.

At the moment, there is no specific interface to exercise this code. You have to use the dummy encryption mode, as described in the mount.lustre man page. A dummy key can be added to the keyring thanks to the following script, after that you just need to mount the client with the 'test_dummy_encryption' option, and all files created under a subdirectory (not the root of the Lustre fs) will be encrypted.

#!/bin/bash

mode='\x00\x00\x00\x00'
raw="$(printf ""\\\\x%02x"" $(seq 0 63))"
if lscpu | grep "Byte Order" | grep -q Little ; then
        size='\x40\x00\x00\x00'
else
        size='\x00\x00\x00\x40'
fi
key="${mode}${raw}${size}"
echo -n -e "${key}" | keyctl padd logon fscrypt:4242424242424242 @s

[Patrick Farrell (Inactive)]

So it's not possible to apply encryption to the root?

[Patrick Farrell (Inactive)]

Also, that makes sense - thanks.

[Sebastien Buisson]

So far I have decided to apply the same restriction as ext4, which forbids encrypting the root of the file system. With ext4, having the root encrypted is a problem for file system check (lost+found cannot be encrypted), but I am not sure it would be a problem for Lustre. However, setting a policy on a directory imposes that this directory is empty. And this is an issue with Lustre's root directory, because it always contains .lustre directory.

Maybe we could think about how to release this restriction in the future, but I am not sure this is very limiting. And we still have the possibility to use subdirectory mount if we want clients to see only encrypted stuff.

[Andreas Dilger]

Since the Lustre-visible root directory is already the "ROOT/" subdirectory, it would be possible to set the encryption before the .lustre/ subdirectory is created.

However, I think this would also cause problems. LFSCK would need to have access to the keyring on the client in order to create files during LFSCK, since it would be against the fscrypt policy to have an unencrypted Lustre lost+found/ subdirectory where it could generate unencrypted filenames.

It probably makes the most sense to keep the root directory unencrypted, and only encrypt subdirectories. If users don't want to expose information about what those subdirectories are, they can use generic names like "dir1, dir2, dir3" (maybe matching the UID, since that is visible information anyway).

[Andreas Dilger]

from https://review.whamcloud.com/36146

As far as I understand, ext4 always writes or reads whole blocks, and then uses i_size to present the correct number of bytes to the upper layers. ext4 does not have to do something special regarding file size when encryption is on, because pages are encrypted just before being written to blocks, and decrypted right after being read from blocks.

Is it possible that the Lustre client/OSS always does the same thing as ext4, reading/writing the full PAGE_SIZE of data, but storing the actual file size on the object(s)? That means some data would be stored explicitly beyond EOF, but would avoid the complexity of storing a separate trusted.enc xattr, which could become out-of-sync with the actual file size in a number of ways.

Replying to my own comment:

It would be better to not tie the encryption directly to the filesystem blocksize, if possible, as this would break the network transparency of the filesystem compared to the backend storage. Also, for ZFS, the blocksize may be up to 1MB and possibly variable per file and per stripe of the file, while the ext4 blocksize is only 4KB. Instead, if we can pick a fixed blocksize for the crypto like 32KB, similar to how the data compression is done. Instead of using the block number as the IV, it should use the byte offset as the IV, since this is agnostic of the blocksize.

The drawback is that we may have to write/allocate a larger portion of the files data (rounded up to 32KB or similar), but this would already be true if we are using a feature like bigalloc on ext4, or recordsize for ZFS.

One possible option would be to do the encryption in chunks of the minimum PAGE_SIZE=4KiB, and use the IV for each chunk based on the 4KB index and not the actual PAGE_SIZE if it is different. This means that for the common PAGE_SIZE=4KiB the encryption would work exactly the same (i.e. compatible with files written by x86 clients), but for PAGE_SIZE=64KiB there would be 16 4KiB chunks within the page that are encrypted/decrypted separately.

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/36191
Subject: LU-12275 tests: exercise file content encryption/decryption
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: d3ee36219e28a8ca7d4e5e9782eb9a21c19af106

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/36238
Subject: LU-12275 osd: make osd layer always send full pages
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 26cdc0abb9d74d92a86c6fcb28efc78d97b39517

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/36360
Subject: LU-12275 sec: reserve flags for client side encryption
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 4cc6598e2cd2959efb86b0c741b7a518217254e0

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/36361
Subject: LU-12275 sec: deal with encrypted object size
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: bbeb3c24bf69dae3e9b1c2fbf84061e8ba191cc5

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/36433
Subject: LU-12275 sec: control client-side 'encrypt' mount option
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 2c3d2f44ad1e4d5ea8cd0cc5434caff9281fde96

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/36360/
Subject: LU-12275 sec: reserve flags for client side encryption
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 4f9632f9701130afc245810dde54035ab7caf2d3

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/36238/
Subject: LU-12275 osd: make osd layer always send complete pages
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 7b136af8f46024fd48a773e5a79b817bca05d9e8

[Patrick Farrell]

Question for Sebastien and/or Andreas:

Would this be incompatible with allowing unaligned direct i/o?  It seems clear the answer is yes - Today, buffered i/o can easily be forced to work in full pages (which this code does) and direct i/o must work in full pages due to alignment requirements.

I had some interest a while back in lifting the alignment requirement for DIO, which could improve performance for some scenarios of interest in certain cases.

So it seems it would be necessary to prevent unaligned DIO on encrypted files, which would be relatively straightforward, if potentially a little confusing.

Looking at LU-12275 osd: make osd layer always send complete pages / https://review.whamcloud.com/36238/ it doesn't seem like it would cause trouble, in that it uses the lnb_len provided, so it doesn't so much force sending complete pages as it forces filling the client buffer, which I think doesn't have to be full pages...

Actually, it occurs to me that we could fall back to buffered i/o for DIO on encrypted files, if we decide that's important.  It's unusual, but it's something that GPFS already does, so it's not unprecedented.

Any strong reactions to this or aspects I've missed in the context of this work?

[Sebastien Buisson]

Hi Patrick,

As explained in the attachment https://jira.whamcloud.com/secure/attachment/32658/lustre_encryption_access_semantics.txt, "direct I/O is not supported on encrypted files. Attempts to use direct I/O on such files will fall back to buffered I/O."

So yes, just like GPFS

[Patrick Farrell]

Ah, OK!  Well that's easy, then.  Thanks.

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/37672
Subject: LU-12275 sec: avoid encrypted files corruption with truncate
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: a46c9b790b338109b2aa685287f88cf39d951b62

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/37673
Subject: LU-12275 sec: ioctls to handle encryption policies
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 304c015b3778759ed1f6af5f229ece5ce5ccc4c7

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/37794
Subject: LU-12275 sec: attempt to support truncate
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 10c7a8979fb3f1230ac254ec4a9a45f51ca4afaa

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/38127
Subject: LU-12275 sec: add llcrypt as file encryption library
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 609fe7b1c72b2d60367ae128889925a879a017a1

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/38430
Subject: LU-12275 sec: atomicity of encryption context getting/setting
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 5238d2ac56268a200e5ed1df89679964cd52735b

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/38127/
Subject: LU-12275 sec: add llcrypt as file encryption library
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: a813e81870096bcfecbe12aeeed8e1b0114cd474

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/38702
Subject: LU-12275 sec: encryption support for DoM files
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 2d9d85e86a77bfb09ad96e9dd7c2ac6add711f30

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/38759
Subject: LU-12275 sec: documentation for client-side encryption
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 63ff8c506a0a7941e03545519e9242078fa198c4

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/38759/
Subject: LU-12275 sec: documentation for client-side encryption
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: f2bf564e691ea8f64843f5c77ae1a8bd60f1b70b

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/36143/
Subject: LU-12275 sec: enable client side encryption
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 28be31137cd22223113e461f74098c92ba6d71e4

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/38881
Subject: LU-12275 sec: introduce null alg for client side encryption
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 0f5daebd7911e8c4568d255b6ec14e7627bc116c

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/38882
Subject: LU-12275 sec: force file name encryption policy to null
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: cf114541eda591fc2cf66ae45b0b85fec37b4588

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/36433/
Subject: LU-12275 sec: control client side encryption
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 3042bcd709ebfea4cf543eb6e8aca330a6cafe9f

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/38918
Subject: LU-12275 sec: check if page is empty with ZERO_PAGE
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 1f0a7547c7e8e8d6984ed591cac3671fe51179ac

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/36144/
Subject: LU-12275 sec: encryption for write path
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: a9ed5b149646f91f23839bbe2d755542d129f5b7

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/36145/
Subject: LU-12275 sec: decryption for read path
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: eecf86131d099242d2e8c1f5d6be241ec1416c9a

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/36146/
Subject: LU-12275 sec: deal with encrypted object size
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 83d660436a164758fd4a29c1433d11c0f4591196

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/37794/
Subject: LU-12275 sec: support truncate for encrypted files
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: adf46db962f657b74bd38db27e7b320aaee3cdd5

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/38967
Subject: LU-12275 sec: O_DIRECT for encrypted file
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 7a42ab045b26bc52f0ae13cac929c1476ab38224

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/36191/
Subject: LU-12275 tests: exercise file content encryption/decryption
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 598c48707cffbb813058f74bb1e663bcdde3c80e

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/37673/
Subject: LU-12275 sec: ioctls to handle encryption policies
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 3973cf8dc955c773a5f9da13216252644aa3949f

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/39220
Subject: LU-12275 sec: restrict fallocate on encrypted files
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 9725d412c9af1996342afbab5b0dc8e19a176ddb

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/39315
Subject: LU-12275 tests: encryption with different client PAGE_SIZE
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: f9cc5e3a68fa597b4ee368f7dd3b71152c8ad2c5

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/38881/
Subject: LU-12275 sec: introduce null algo for filename encryption
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: c60b7d9f571748fb055d29cd019709f9e965a84d

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/38882/
Subject: LU-12275 sec: force file name encryption policy to null
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 11fcbfa9de4a5170abc2c5df2a6e4e02f0f84268

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/38430/
Subject: LU-12275 sec: atomicity of encryption context getting/setting
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 40d91eafe257fb407d27c54cd2f7ae9961672f60

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/38702/
Subject: LU-12275 sec: encryption support for DoM files
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: a71586d4ee8d6f039a413e2a0fd791db847a3c19

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/38918/
Subject: LU-12275 sec: check if page is empty with ZERO_PAGE
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 45c26bc11b7b1ec6b6b4773fb9a40e0a655f7d33

[Gerrit Updater]

Neil Brown ([e-mail]) uploaded a new patch: https://review.whamcloud.com/39459
Subject: LU-12275 sec: use memchr_inv() to check if page is zero.
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 5a36eee3767f27e0bf5065c2dc1785e6c2d7aa5a

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/39558
Subject: LU-12275 sec: ldiskfs not aware of client-side encryption
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: c24b7479f476d371cc6b8c2e852a8579e3808a4b

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: https://review.whamcloud.com/39617
Subject: LU-12275 sec: verify dir is empty when setting enc policy
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 9cbe9dfd7da0fc57c643eea2d95ebf4d3fb98491

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/39459/
Subject: LU-12275 sec: use memchr_inv() to check if page is zero.
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: afee2380c105c37e440aaa9ec588cd27189bc18e

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/38967/
Subject: LU-12275 sec: O_DIRECT for encrypted file
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 728036f25635a9b14310eded1761cf6cd0bacb1a

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/39220/
Subject: LU-12275 sec: restrict fallocate on encrypted files
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: a7870fb9568bf753d50eeead71a59dfe07db1d20

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/39558/
Subject: LU-12275 sec: ldiskfs not aware of client-side encryption
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: ad444ed9836320c6ae8b770ff96edd6b0fe4f0d4

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/39315/
Subject: LU-12275 sec: encryption with different client PAGE_SIZE
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: ac5fcdce025b4825500c0308d89dfdab1faece51

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/39617/
Subject: LU-12275 sec: verify dir is empty when setting enc policy
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: e8f74fb0f5c9306ee5a099133799e03e09ca8e47

[Peter Jones]

I believe that everything planned for 2.14 has now landed

[Gerrit Updater]

"Andreas Dilger <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/49828
Subject: LU-12275 tests: skip new nodemap params on old MGS
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: f69c3cd23c4d6e128d95de781f1db5cfe68dec6f

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/49828/
Subject: LU-12275 tests: skip new nodemap params on old MGS
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 93230059abe9dfe39a8b72cb8fc31bab1cadc7b6

[Gerrit Updater]

"Andreas Dilger <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/50023
Subject: LU-12275 sec: disable bio functions on client
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 0ebb7e37b85f8e881985bdcb45d3e16ace37c1f0

[Gerrit Updater]

"Andreas Dilger <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/50140
Subject: LU-12275 sec: disable bio functions on client
Project: fs/lustre-release
Branch: b2_15
Current Patch Set: 1
Commit: 546cb30c00fb1db1af59cb88396e84e362370dcf

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/50023/
Subject: LU-12275 sec: remove bio functions in fscrypt compat
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: d328818a456daf30c20c8df0aa0be9dd2a2b6a9e

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/50140/
Subject: LU-12275 sec: remove bio functions in fscrypt compat
Project: fs/lustre-release
Branch: b2_15
Current Patch Set:
Commit: 6ce5b0bc881389003e90d1201d468bc099251ada