<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/next/linux-next.git/fs/crypto, branch akpm</title>
<subtitle>The linux-next integration testing tree</subtitle>
<id>https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=akpm</id>
<link rel='self' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=akpm'/>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/'/>
<updated>2022-06-28T01:26:37+00:00</updated>
<entry>
<title>Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git</title>
<updated>2022-06-28T01:26:37+00:00</updated>
<author>
<name>Stephen Rothwell</name>
<email>sfr@canb.auug.org.au</email>
</author>
<published>2022-06-28T01:26:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ad9dd1674d6bee8c27f02f6c61e5328cbc0bfb64'/>
<id>urn:sha1:ad9dd1674d6bee8c27f02f6c61e5328cbc0bfb64</id>
<content type='text'>
</content>
</entry>
<entry>
<title>fscrypt: add fscrypt_context_for_new_inode</title>
<updated>2022-06-15T12:25:03+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@kernel.org</email>
</author>
<published>2020-09-01T16:56:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=45d719fe75622bd436f15c468738dddf8ff227dd'/>
<id>urn:sha1:45d719fe75622bd436f15c468738dddf8ff227dd</id>
<content type='text'>
Most filesystems just call fscrypt_set_context on new inodes, which
usually causes a setxattr. That's a bit late for ceph, which can send
along a full set of attributes with the create request.

Doing so allows it to avoid race windows that where the new inode could
be seen by other clients without the crypto context attached. It also
avoids the separate round trip to the server.

Refactor the fscrypt code a bit to allow us to create a new crypto
context, attach it to the inode, and write it to the buffer, but without
calling set_context on it. ceph can later use this to marshal the
context into the attributes we send along with the create request.

Signed-off-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Reviewed-by: Xiubo Li &lt;xiubli@redhat.com&gt;
Acked-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
</content>
</entry>
<entry>
<title>fscrypt: export fscrypt_fname_encrypt and fscrypt_fname_encrypted_size</title>
<updated>2022-06-15T12:25:03+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@kernel.org</email>
</author>
<published>2021-01-08T20:34:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=1d381c626ac844eae14b98a6d50a633d6b4c28cc'/>
<id>urn:sha1:1d381c626ac844eae14b98a6d50a633d6b4c28cc</id>
<content type='text'>
For ceph, we want to use our own scheme for handling filenames that are
are longer than NAME_MAX after encryption and Base64 encoding. This
allows us to have a consistent view of the encrypted filenames for
clients that don't support fscrypt and clients that do but that don't
have the key.

Currently, fs/crypto only supports encrypting filenames using
fscrypt_setup_filename, but that also handles encoding nokey names. Ceph
can't use that because it handles nokey names in a different way.

Export fscrypt_fname_encrypt. Rename fscrypt_fname_encrypted_size to
__fscrypt_fname_encrypted_size and add a new wrapper called
fscrypt_fname_encrypted_size that takes an inode argument rather than a
pointer to a fscrypt_policy union.

Signed-off-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Reviewed-by: Xiubo Li &lt;xiubli@redhat.com&gt;
Acked-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
</content>
</entry>
<entry>
<title>fscrypt: Add HCTR2 support for filename encryption</title>
<updated>2022-06-10T08:40:18+00:00</updated>
<author>
<name>Nathan Huckleberry</name>
<email>nhuck@google.com</email>
</author>
<published>2022-05-20T18:15:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=6b2a51ff03bf0c54cbc699ee85a9a49eb203ebfc'/>
<id>urn:sha1:6b2a51ff03bf0c54cbc699ee85a9a49eb203ebfc</id>
<content type='text'>
HCTR2 is a tweakable, length-preserving encryption mode that is intended
for use on CPUs with dedicated crypto instructions.  HCTR2 has the
property that a bitflip in the plaintext changes the entire ciphertext.
This property fixes a known weakness with filename encryption: when two
filenames in the same directory share a prefix of &gt;= 16 bytes, with
AES-CTS-CBC their encrypted filenames share a common substring, leaking
information.  HCTR2 does not have this problem.

More information on HCTR2 can be found here: "Length-preserving
encryption with HCTR2": https://eprint.iacr.org/2021/1441.pdf

Signed-off-by: Nathan Huckleberry &lt;nhuck@google.com&gt;
Reviewed-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Acked-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>fscrypt: add new helper functions for test_dummy_encryption</title>
<updated>2022-05-09T23:18:54+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2022-05-01T05:08:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=218d921b581eadf312c8ef0e09113b111f104eeb'/>
<id>urn:sha1:218d921b581eadf312c8ef0e09113b111f104eeb</id>
<content type='text'>
Unfortunately the design of fscrypt_set_test_dummy_encryption() doesn't
work properly for the new mount API, as it combines too many steps into
one function:

  - Parse the argument to test_dummy_encryption
  - Check the setting against the filesystem instance
  - Apply the setting to the filesystem instance

The new mount API has split these into separate steps.  ext4 partially
worked around this by duplicating some of the logic, but it still had
some bugs.  To address this, add some new helper functions that split up
the steps of fscrypt_set_test_dummy_encryption():

  - fscrypt_parse_test_dummy_encryption()
  - fscrypt_dummy_policies_equal()
  - fscrypt_add_test_dummy_key()

While we're add it, also add a function fscrypt_is_dummy_policy_set()
which will be useful to avoid some #ifdef's.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Link: https://lore.kernel.org/r/20220501050857.538984-5-ebiggers@kernel.org
</content>
</entry>
<entry>
<title>fscrypt: factor out fscrypt_policy_to_key_spec()</title>
<updated>2022-05-09T23:18:54+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2022-05-01T05:08:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=bfb9700bdf35417454a9bb8b67221d89d7c6e75a'/>
<id>urn:sha1:bfb9700bdf35417454a9bb8b67221d89d7c6e75a</id>
<content type='text'>
Factor out a function that builds the fscrypt_key_specifier for an
fscrypt_policy.  Before this was only needed when finding the key for a
file, but now it will also be needed for test_dummy_encryption support.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Link: https://lore.kernel.org/r/20220501050857.538984-4-ebiggers@kernel.org
</content>
</entry>
<entry>
<title>fscrypt: log when starting to use inline encryption</title>
<updated>2022-04-14T05:35:25+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2022-04-14T05:34:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a7a5bc5fe8acc9381e38a34ef18f1115c5c22079'/>
<id>urn:sha1:a7a5bc5fe8acc9381e38a34ef18f1115c5c22079</id>
<content type='text'>
When inline encryption is used, the usual message "fscrypt: AES-256-XTS
using implementation &lt;impl&gt;" doesn't appear in the kernel log.  Add a
similar message for the blk-crypto case that indicates that inline
encryption was used, and whether blk-crypto-fallback was used or not.
This can be useful for debugging performance problems.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Link: https://lore.kernel.org/r/20220414053415.158986-1-ebiggers@kernel.org
</content>
</entry>
<entry>
<title>fscrypt: split up FS_CRYPTO_BLOCK_SIZE</title>
<updated>2022-04-13T22:03:09+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2022-04-05T01:09:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=63cec1389e116ae0e2a15e612a5b49651e04be3f'/>
<id>urn:sha1:63cec1389e116ae0e2a15e612a5b49651e04be3f</id>
<content type='text'>
FS_CRYPTO_BLOCK_SIZE is neither the filesystem block size nor the
granularity of encryption.  Rather, it defines two logically separate
constraints that both arise from the block size of the AES cipher:

- The alignment required for the lengths of file contents blocks
- The minimum input/output length for the filenames encryption modes

Since there are way too many things called the "block size", and the
connection with the AES block size is not easily understood, split
FS_CRYPTO_BLOCK_SIZE into two constants FSCRYPT_CONTENTS_ALIGNMENT and
FSCRYPT_FNAME_MIN_MSG_LEN that more clearly describe what they are.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Link: https://lore.kernel.org/r/20220405010914.18519-1-ebiggers@kernel.org
</content>
</entry>
<entry>
<title>fs: Remove -&gt;readpages address space operation</title>
<updated>2022-04-01T17:45:33+00:00</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
<email>willy@infradead.org</email>
</author>
<published>2022-03-24T01:29:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=704528d895dd3e7b173e672116b4eb2b0a0fceb0'/>
<id>urn:sha1:704528d895dd3e7b173e672116b4eb2b0a0fceb0</id>
<content type='text'>
All filesystems have now been converted to use -&gt;readahead, so
remove the -&gt;readpages operation and fix all the comments that
used to refer to it.

Signed-off-by: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Acked-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>Merge tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt</title>
<updated>2022-03-22T16:50:16+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-03-22T16:50:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=881b568756ae55ce7d87b9f001cbbe9d1289893e'/>
<id>urn:sha1:881b568756ae55ce7d87b9f001cbbe9d1289893e</id>
<content type='text'>
Pull fscrypt updates from Eric Biggers:
 "Add support for direct I/O on encrypted files when blk-crypto (inline
  encryption) is being used for file contents encryption"

* tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt:
  fscrypt: update documentation for direct I/O support
  f2fs: support direct I/O with fscrypt using blk-crypto
  ext4: support direct I/O with fscrypt using blk-crypto
  iomap: support direct I/O with fscrypt using blk-crypto
  fscrypt: add functions for direct I/O support
</content>
</entry>
</feed>
