Hello,
This is the newly reworked fscrypt support for btrfs. There have been a few
things changed since Sweet Tea's last post[1], and my RFC[2]. The changes from
Sweet Tea's patchset are mostly related to the fscrypt changes, but I'll detail
them here
- We have a fscrypt_extent_info struct that
From: Omar Sandoval
Initially, only normal data extents will be encrypted. This change
forbids various other bits:
- allows reflinking only if both inodes have the same encryption status
- disable inline data on encrypted inodes
Signed-off-by: Omar Sandoval
Signed-off-by: Sweet Tea Dorminy
Sig
Btrfs does checksumming, and the checksums need to match the bytes on
disk. In order to facilitate this add a process bio callback for the
blk-crypto layer. This allows the file system to specify a callback and
then can process the encrypted bio as necessary.
For btrfs, writes will have the chec
This adds the code necessary for per-extent encryption. We will store a
nonce for every extent we create, and then use the inode's policy and
the extents nonce to derive a per-extent key.
This is meant to be flexible, if we choose to expand the on-disk extent
information in the future we have a v
We are going to track per-extent information, so it'll be necessary to
distinguish between inode infos and extent infos. Rename fscrypt_info
to fscrypt_inode_info, adjusting any lines that now exceed 80
characters.
Signed-off-by: Josef Bacik
---
fs/crypto/crypto.c | 13 ++--
fs
The different encryption related options for fscrypt are too numerous to
support for extent based encryption. Support for a few of these options
could possibly be added, but since they're niche options simply reject
them for file systems using extent based encryption.
Signed-off-by: Josef Bacik
From: Sweet Tea Dorminy
Right now there isn't a way to encrypt things that aren't either
filenames in directories or data on blocks on disk with extent
encryption, so for now, disable verity usage with encryption on btrfs.
Signed-off-by: Sweet Tea Dorminy
Signed-off-by: Josef Bacik
---
fs/btr
From: Omar Sandoval
btrfs stores its data structures, including filenames in directories, in
its own buffer implementation, struct extent_buffer, composed of
several non-contiguous pages. We could copy filenames into a
temporary buffer and use fscrypt_match_name() against that buffer, such
extens
From: Omar Sandoval
As encrypted files will be incompatible with older filesystem versions,
new filesystems should be created with an incompat flag for fscrypt,
which will gate access to the encryption ioctls.
Signed-off-by: Omar Sandoval
Signed-off-by: Sweet Tea Dorminy
Signed-off-by: Josef B
From: Omar Sandoval
In order to appropriately encrypt, create, open, rename, and various
symlink operations must call fscrypt hooks. These determine whether the
inode should be encrypted and do other preparatory actions. The
superblock must have fscrypt operations registered, so implement the
min
Add a couple of sections to the fscrypt documentation about per-extent
encryption.
Signed-off-by: Josef Bacik
---
Documentation/filesystems/fscrypt.rst | 36 +++
1 file changed, 36 insertions(+)
diff --git a/Documentation/filesystems/fscrypt.rst
b/Documentation/filesyst
From: Omar Sandoval
In order to store encryption information for directories, symlinks,
etc., fscrypt stores a context item with each encrypted non-regular
inode. fscrypt provides an arbitrary blob for the filesystem to store,
and it does not clearly fit into an existing structure, so this goes i
When we add fscrypt support we're going to have fscrypt objects hanging
off of extent_maps. This includes a block key, which if we're the last
one freeing the key we may have to unregister it from the block layer.
This requires taking a semaphore in the block layer, which means we
can't free em's
From: Sweet Tea Dorminy
For encrypted or unencrypted names, we calculate the offset for the dir
item by hashing the name for the dir item. However, this doesn't work
for a long nokey name, where we do not have the complete ciphertext.
Instead, fscrypt stores the filesystem-provided hash in the no
From: Sweet Tea Dorminy
Since encryption is currently under BTRFS_DEBUG, this adds its
dependencies: inline encryption from fscrypt, and the inline encryption
fallback path from the block layer.
Signed-off-by: Sweet Tea Dorminy
Signed-off-by: Josef Bacik
---
fs/btrfs/ioctl.c | 2 ++
1 file ch
From: Omar Sandoval
Deleting an encrypted file must always be permitted, even if the user
does not have the appropriate key. Therefore, for listing an encrypted
directory, so-called 'nokey' names are provided, and these nokey names
must be sufficient to look up and delete the appropriate encrypte
From: Omar Sandoval
These ioctls allow encryption to actually be used.
The set_encryption_policy ioctl is the thing which actually turns on
encryption, and therefore sets the ENCRYPT flag in the superblock. This
prevents the filesystem from being loaded on older kernels.
fscrypt provides CONFIG
From: Sweet Tea Dorminy
This puts the long-preserved 1-byte encryption field to work, storing
whether the extent is encrypted. Update the tree-checker to allow for
the encryption bit to be set to our valid types.
Signed-off-by: Sweet Tea Dorminy
Signed-off-by: Josef Bacik
---
fs/btrfs/access
From: Sweet Tea Dorminy
Since extent encryption requires inline encryption, even though we
expect to use the inlinecrypt software fallback most of the time, we
need to enumerate all the devices in use by btrfs.
Signed-off-by: Sweet Tea Dorminy
Signed-off-by: Josef Bacik
---
fs/btrfs/fscrypt.c
From: Sweet Tea Dorminy
fscrypt's extent encryption requires the use of inline encryption or the
software fallback that the block layer provides; it is rather
complicated to allow software encryption with extent encryption due to
the timing of memory allocations. Thus, if btrfs has ever had a
enc
We're going to need these to update the file extent items once the
writes are complete. Add them and add the pieces necessary to assign
them and free everything.
Signed-off-by: Josef Bacik
---
fs/btrfs/ordered-data.c | 2 ++
fs/btrfs/ordered-data.h | 6 ++
2 files changed, 8 insertions(+)
We're going to be getting fscrypt_info from the extent maps, update the
helpers to take an fscrypt_info argument and use that to set the
encryption type on the ordered extent.
Signed-off-by: Josef Bacik
---
fs/btrfs/inode.c| 20 +++-
fs/btrfs/ordered-data.c | 32 +
We keep track of this information in the ordered extent for writes, but
we need it for reads as well. Add fscrypt_extent_info and orig_start to
the dio_data so we can populate this on reads. This will be used later
when we attach the fscrypt context to the bios.
Signed-off-by: Josef Bacik
---
From: Sweet Tea Dorminy
Each extent_map will end up with a pointer to its associated
fscrypt_info if any, which should have the same lifetime as the
extent_map. We are also going to need to track the encryption_type for
the file extent items. Add the fscrypt_info to the extent_map, and the
subse
The fscrypt_extent_info will be tied to the extent_map lifetime, so it
will be created when we create the IO em, or it'll already exist in the
NOCOW case. Use this fscrypt_info when creating the ordered extent to
make sure everything is passed through properly.
Signed-off-by: Josef Bacik
---
fs
The fscrypt encryption context can be extended to include different
things in the future. To facilitate future expansion add an optional
btrfs_encryption_info to the end of the file extent. This will hold the
size of the context and then will have the binary context tacked onto
the end of the ext
Now that we have the fscrypt_extnet_info in all of the supporting
structures, pass this through and set the file extent encryption bit
accordingly from the supporting structures. In subsequent patches code
will be added to populate these appropriately.
Signed-off-by: Josef Bacik
---
fs/btrfs/in
Prealloc uses the btrfs_replace_file_extents() infrastructure to insert
its new extents. We need to set the fscrypt context on these extents,
so pass this through the btrfs_replace_extent_info so it can be used in
a later patch when we hook in this infrastructure.
Signed-off-by: Josef Bacik
---
From: Sweet Tea Dorminy
With the advent of storing fscrypt contexts with each encrypted extent,
extents will have a variable length depending on encryption status.
Make sure the replace and drop file extent item helpers encode this
information so that everything gets updated properly.
Signed-off
New extents for encrypted inodes must have a fscrypt_extent_info, which
has the necessary keys and does all the registration at the block layer
for them. This is passed through all of the infrastructure we've
previously added to make sure the context gets saved properly with the
file extents.
Sig
For extent encryption we have to use a logical block nr as input for the
IV. For btrfs we're using the offset into the extent we're operating
on. For most ordered extents this is the same as the file_offset,
however for prealloc and NOCOW we have to use the original offset.
Add this as an argume
This patch implements the necessary hooks from fscrypt to support
per-extent encryption. There's two main entry points
btrfs_fscrypt_load_extent_info
btrfs_fscrypt_save_extent_info
btrfs_fscrypt_load_extent_info gets called when we create the extent
maps from the file extent item at btrfs_get_ex
We only ever needed the bbio in btrfs_csum_one_bio, since that has the
bio embedded in it. However with encryption we'll have a different bio
with the encrypted data in it, and the original bbio. Update
btrfs_csum_one_bio to take the bio we're going to csum as an argument,
which will allow us to
Now that we have the fscrypt_info plumbed through everywhere, add the
code to setup the bio encryption context from the extent context.
We use the per-extent fscrypt_extent_info for encryption/decryption.
We use the offset into the extent as the lblk for fscrypt. So the start
of the extent has th
When checksumming the encrypted bio on writes we need to know which
logical address this checksum is for. At the point where we get the
encrypted bio the bi_sector is the physical location on the target disk,
so we need to save the original logical offset in the btrfs_bio. Then
we can use this wh
We are going to be checksumming the encrypted data, so we have to
implement the ->process_bio fscrypt callback. This will provide us with
the original bio and the encrypted bio to do work on. For WRITE's this
will happen after the encrypted bio has been encrypted. For READ's this
will happen aft
36 matches
Mail list logo
