This converts inodes, direct nodes, and indirect nodes over to not being
based on a 4K page size. f2fs_inode's i_nids field should now be
accessed via a macro, as it's location depends on block size.
Access to direct nodes and indirect nodes is unchanged.
The node footer's location is also based
This converts the various block size based constants to be defined in
terms of the block size. This makes it possible to change the block size
by changing only F2FS_BLKSIZE_BITS in f2fs_fs.h
Signed-off-by: Daniel Rosenberg
---
fsck/fsck.h | 2 +-
fsck/mount.c| 4 +-
inc
This converts f2fs_nat_block and f2fs_sit_block to be variable length
arrays. This does not change the way they are accessed, but removes a
misleading statment that these sizes are fixed, as opposed to deriving
from F2FS_BLKSIZE
Signed-off-by: Daniel Rosenberg
---
include/f2fs_fs.h | 20
This splits off access to the orphan block's footer into a macro call
as its location is dependent on block size. Because of this, you should
use F2FS_BLKSIZE instead of sizeof(struct f2fs_orphan_block)
Signed-off-by: Daniel Rosenberg
---
fsck/fsck.c | 4 ++--
fsck/main.c | 1 +
in
This splits off access to the summary block's journal and footer into a
macro call, as their location is dependent on block size. Because of
this you should use F2FS_BLKSIZE instead of sizeof(struct summary_block)
Signed-off-by: Daniel Rosenberg
---
fsck/f2fs.h| 4 +--
fsck/fsck.c
F2fs filesystems currently have two large restrictions around block size.
The block size must equal the page size, and the block size must be 4096.
The following patch, along with the associated f2fs-tools patch set, relax the
latter restriction, allowing you to use 16K block size f2fs on a 16K pa
This allows f2fs to support cases where the block size = page size for
both 4K and 16K block sizes. Other sizes should work as well, should the
need arise. This does not currently support 4K Block size filesystems if
the page size is 16K.
Signed-off-by: Daniel Rosenberg
---
fs/f2fs/data.c
This moves access to f2fs_dentry_block's dentry list and filename list
behind a macro, as their locations depend on block size.
Since struct f2fs_dentry_block no longer represents the full block, use
F2FS_BLKSIZE instead of sizeof(struct f2fs_dentry_block)
Signed-off-by: Daniel Rosenberg
---
fs
This adds support for different block sizes to f2fs-tools.
The first patch redefines all block size based constants to be based on the
block size. After this patch, you should be able to compile a version of
f2fs-tools that works for a given blocksize by just setting F2FS_BLKSIZE_BITS
in f2fs_fs.h
This adds support for 4K and 16K block size using the same binary.
mkfs can choose block size via the -b option, with other tools getting
the blocksize from the superblock.
On mount time, we can't rely on block size for the location for the
superblock, since that information is in the superblock.
This adds support for different block sizes to f2fs-tools.
The first patch redefines all block size based constants to be based on the
block size. After this patch, you should be able to compile a version of
f2fs-tools that works for a given blocksize by just setting F2FS_BLKSIZE_BITS
in f2fs_fs.h
This converts f2fs_nat_block and f2fs_sit_block to be variable length
arrays. This does not change the way they are accessed, but removes a
misleading statment that these sizes are fixed, as opposed to deriving
from F2FS_BLKSIZE
Signed-off-by: Daniel Rosenberg
---
include/f2fs_fs.h | 20
This splits off access to the orphan block's footer into a macro call
as its location is dependent on block size. Because of this, you should
use F2FS_BLKSIZE instead of sizeof(struct f2fs_orphan_block)
Signed-off-by: Daniel Rosenberg
---
fsck/fsck.c | 4 ++--
fsck/main.c | 1 +
in
This moves access to f2fs_dentry_block's dentry list and filename list
behind a macro, as their locations depend on block size.
Since struct f2fs_dentry_block no longer represents the full block, use
F2FS_BLKSIZE instead of sizeof(struct f2fs_dentry_block)
Signed-off-by: Daniel Rosenberg
---
fs
This converts the various block size based constants to be defined in
terms of the block size. This makes it possible to change the block size
by changing only F2FS_BLKSIZE_BITS in f2fs_fs.h
Signed-off-by: Daniel Rosenberg
---
fsck/dir.c | 2 +-
fsck/dump.c | 4 +-
f
On Fri, Aug 25, 2023 at 10:39 AM Jaegeuk Kim wrote:
>
> Hi Daniel,
>
> f2fs_format_main.c: In function ‘add_default_options’:
> f2fs_format_main.c:142:41: error: ‘struct f2fs_configuration’ has no member
> named ‘blksize’
> 142 | c.wanted_sector_size = c.blksize;
> |
This adds support for 4K and 16K block size using the same binary.
mkfs can choose block size via the -b option, with other tools getting
the blocksize from the superblock.
On mount time, we can't rely on block size for the location for the
superblock, since that information is in the superblock.
This converts inodes, direct nodes, and indirect nodes over to not being
based on a 4K page size. f2fs_inode's i_nids field should now be
accessed via a macro, as it's location depends on block size.
Access to direct nodes and indirect nodes is unchanged.
The node footer's location is also based
This splits off access to the summary block's journal and footer into a
macro call, as their location is dependent on block size. Because of
this you should use F2FS_BLKSIZE instead of sizeof(struct summary_block)
Signed-off-by: Daniel Rosenberg
---
fsck/f2fs.h| 4 +--
fsck/fsck.c
On Mon, Aug 28, 2023 at 11:08 AM Jaegeuk Kim wrote:
>
> Hi Daniel,
>
> Could you please check this?
>
> mount.c: In function ‘move_one_curseg_info’:
> mount.c:3037:9: warning: ‘memcpy’ offset [0, 3583] is out of the bounds [0,
> 0] of object ‘buf’ with type ‘struct f2fs_summary_block’ [-Warray-bo
On Mon, Aug 28, 2023 at 1:27 PM Jaegeuk Kim wrote:
>
> This patch somehow reveals struct size assertions.
> You can get it when running fsck from the used f2fs partition.
>
Seems the binary I was testing had the asserts set to noops. I was
missing the 2 bytes from n_nats/n_sits, and had a few nat/
This adds support for 4K and 16K block size using the same binary.
mkfs can choose block size via the -b option, with other tools getting
the blocksize from the superblock.
On mount time, we can't rely on block size for the location for the
superblock, since that information is in the superblock.
This converts the various block size based constants to be defined in
terms of the block size. This makes it possible to change the block size
by changing only F2FS_BLKSIZE_BITS in f2fs_fs.h
Signed-off-by: Daniel Rosenberg
---
fsck/dir.c | 2 +-
fsck/dump.c | 4 +-
f
This splits off access to the orphan block's footer into a macro call
as its location is dependent on block size. Because of this, you should
use F2FS_BLKSIZE instead of sizeof(struct f2fs_orphan_block)
Signed-off-by: Daniel Rosenberg
---
fsck/fsck.c | 4 ++--
fsck/main.c
This splits off access to the summary block's journal and footer into a
macro call, as their location is dependent on block size. Because of
this you should use F2FS_BLKSIZE instead of sizeof(struct summary_block)
Signed-off-by: Daniel Rosenberg
---
fsck/f2fs.h| 4 +--
fsck/fsck.c
This adds support for different block sizes to f2fs-tools.
The first patch redefines all block size based constants to be based on the
block size. After this patch, you should be able to compile a version of
f2fs-tools that works for a given blocksize by just setting F2FS_BLKSIZE_BITS
in f2fs_fs.h
This converts f2fs_nat_block and f2fs_sit_block to be variable length
arrays. This does not change the way they are accessed, but removes a
misleading statment that these sizes are fixed, as opposed to deriving
from F2FS_BLKSIZE
Signed-off-by: Daniel Rosenberg
---
include/f2fs_fs.h | 20
This converts inodes, direct nodes, and indirect nodes over to not being
based on a 4K page size. f2fs_inode's i_nids field should now be
accessed via a macro, as it's location depends on block size.
Access to direct nodes and indirect nodes is unchanged.
The node footer's location is also based
This moves access to f2fs_dentry_block's dentry list and filename list
behind a macro, as their locations depend on block size.
Since struct f2fs_dentry_block no longer represents the full block, use
F2FS_BLKSIZE instead of sizeof(struct f2fs_dentry_block)
Signed-off-by: Daniel Rosenberg
---
fs
F2fs filesystems currently have two large restrictions around block size.
The block size must equal the page size, and the block size must be 4096.
The following patch, along with the associated f2fs-tools patch set, relax the
latter restriction, allowing you to use 16K block size f2fs on a 16K pa
This allows f2fs to support cases where the block size = page size for
both 4K and 16K block sizes. Other sizes should work as well, should the
need arise. This does not currently support 4K Block size filesystems if
the page size is 16K.
Signed-off-by: Daniel Rosenberg
---
fs/f2fs/data.c
The cache is initialized during the first read, however, it requires the
block size to establish its buffer. This disables the cache until the
block size is known.
Signed-off-by: Daniel Rosenberg
---
fsck/mount.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fsck/mount.c b/fsck/mount.
The conversion from block size to MB in this debug statement assumes a
block size of 4K. This switches it to properly use the filesystem's
block size.
Signed-off-by: Daniel Rosenberg
---
fsck/fsck.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fsck/fsck.c b/fsck/fsck.c
i
I missed a couple things in my previous patch set. This fixes Quotas,
the -c cache option, and a debug print. The issues can be seen by running:
truncate test.dat --size 256M
make_f2fs -g android -O project_quota,extra_attr -w 16384 -b 16384 test.dat
16384
fsck.f2fs -f -c 1 --debug-cache test
The initial sizes for dqblk.dqb_curspace should reflect the block size,
as that's the minimal filesize.
Signed-off-by: Daniel Rosenberg
---
mkfs/f2fs_format.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mkfs/f2fs_format.c b/mkfs/f2fs_format.c
index f2840c8..b46bc15 10
On Sun, Nov 26, 2023 at 5:42 PM Chao Yu wrote:
>
> Hi Daniel,
>
> How about this? It be more explicit to indicate the logic?
>
> ---
> fsck/mount.c | 2 ++
> include/f2fs_fs.h | 3 +++
> lib/libf2fs_io.c | 4
> 3 files changed, 9 insertions(+)
>
> diff --git a/fsck/mount.c b/fsck/m
Describes the block size option -b. This sets the block size, which is
restricted to powers of 2. The linux kernel currently requires that the
block size be equal to the page size to mount.
Change-Id: I27ec4f909f8d27327b48373f0a4a4e8593626804
Signed-off-by: Daniel Rosenberg
---
man/mkfs.f2fs.8 |
Describes the block size option -b. This sets the block size, which is
restricted to powers of 2. The linux kernel currently requires that the
block size be equal to the page size to mount.
Change-Id: I27ec4f909f8d27327b48373f0a4a4e8593626804
Signed-off-by: Daniel Rosenberg
---
man/mkfs.f2fs.8 |
Blocks are tracked by u32, so the max permitted filesize is
U32_MAX * BLOCK_SIZE. Additionally, in order to support crypto block
sizes of 4K with a 16K block size, we must further restrict max filesize
to U32_MAX * 4096. This does not affect 4K blocksize f2fs as the natural
limits for those are wel
Blocks are tracked by u32, so the max permitted filesize is
U32_MAX * BLOCK_SIZE. Additionally, in order to support crypto data unit
sizes of 4K with a 16K block size with IV_INO_LBLK_{32,63}, we must
further restrict max filesize to U32_MAX * 4096. This does not affect 4K
blocksize f2fs as the nat
Blocks are tracked by u32, so the max permitted filesize is
(U32_MAX + 1) * BLOCK_SIZE. Additionally, in order to support crypto
data unit sizes of 4K with a 16K block with IV_INO_LBLK_{32,64}, we must
further restrict max filesize to (U32_MAX + 1) * 4096. This does not
affect 4K blocksize f2fs as
If sparse files is set along with multiple devices, we initialize
sparse file data multiple times without freeing the previously allocated
data. This skips the initialization for subsequent devices, as sparse
file mode currently only deals with device 0 anyways.
Signed-off-by: Daniel Rosenberg
--
Since we may not know the block size when initializing sparse files, we
should assume that the sparse file's blocksize is correct.
Signed-off-by: Daniel Rosenberg
---
fsck/mount.c | 20 +---
lib/libf2fs_io.c | 11 +++
2 files changed, 20 insertions(+), 11 deletions(-)
Xattrs for files with inline data were being skipped. This dumps those,
as well as xattrs for folders.
Signed-off-by: Daniel Rosenberg
---
fsck/dump.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/fsck/dump.c b/fsck/dump.c
index f60f6f9..3bd17e3 1
This adds the ability to dump folders as well as files. Folders are
dumped recursively. Additionally, dumped files/folders may be directed
to a folder specified by -o [path] instead of ./lost_found. The -r flag
will dump the entire fs from the root inode. -f or -y will skip the
prompt before dumpin
This adds the ability to dump folders as well as files. Folders are
dumped recursively. Additionally, dumped files/folders may be directed
to a folder specified by -o [path] instead of ./lost_found. The -r flag
will dump the entire fs from the root inode. -f or -y will skip the
prompt before dumpin
Xattrs for files with inline data were being skipped. This dumps those,
as well as xattrs for folders.
Signed-off-by: Daniel Rosenberg
---
fsck/dump.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/fsck/dump.c b/fsck/dump.c
index aecc293..17680d9 1
This adds the ability to dump folders as well as files. Folders are
dumped recursively. Additionally, dumped files/folders may be directed
to a folder specified by -o [path] instead of ./lost_found. The -r flag
will dump the entire fs from the root inode. -f or -y will skip the
prompt before dumpin
Xattrs for files with inline data were being skipped. This dumps those,
as well as xattrs for folders.
Signed-off-by: Daniel Rosenberg
Reviewed-by: Daeho Jeong
---
fsck/dump.c | 39 +++
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/fsck/dump
Xattrs for files with inline data were being skipped. This dumps those,
as well as xattrs for folders.
Signed-off-by: Daniel Rosenberg
Reviewed-by: Daeho Jeong
---
fsck/dump.c | 39 +++
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/fsck/dump
This adds the ability to dump folders as well as files. Folders are
dumped recursively. Additionally, dumped files/folders may be directed
to a folder specified by -o [path] instead of ./lost_found. The -r flag
will dump the entire fs from the root inode. -f or -y will skip the
prompt before dumpin
The code for dumping files was ignoring i_extra_isize, leading to
invalid data for some inlined files after dumping. This swaps inode
dumping to use the common inline_data_addr function.
Signed-off-by: Daniel Rosenberg
---
fsck/dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
These were described in man pages, but not within the help message.
Signed-off-by: Daniel Rosenberg
---
fsck/main.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fsck/main.c b/fsck/main.c
index 6edc902..901fa7a 100644
--- a/fsck/main.c
+++ b/fsck/main.c
@@ -97,6 +97,11 @@ void dump_us
On Tue, Jun 18, 2024 at 6:30 PM Chao Yu wrote:
>
> On 2024/6/19 9:25, Daniel Rosenberg wrote:
> > These were described in man pages, but not within the help message.
> >
> > Signed-off-by: Daniel Rosenberg
>
> Can you please check below patch?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/j
Previously, dumped symlinks would always create regular files instead.
This allows symlinks to be dumped as symlinks with the -L option.
The i_name field's name may not be the same as the actual name from the
dirent, so we use the dirent name when available.
Currently hardlinks aren't detected, s
Previously, dumped symlinks would always create regular files instead.
This allows symlinks to be dumped as symlinks with the -L option.
The i_name field's name may not be the same as the actual name from the
dirent, so we use the dirent name when available.
Currently hardlinks aren't detected, s
Previously, dumped symlinks would always create regular files instead.
This allows symlinks to be dumped as symlinks with the -L option.
The i_name field's name may not be the same as the actual name from the
dirent, so we use the dirent name when available.
Currently hardlinks aren't detected, s
These look good to me. It will be nice to have negative dentries back for
casefolded directories.
-Daniel Rosenberg
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Add charset encoding to f2fs to support casefolding. It is modeled after
the same feature introduced in commit c83ad55eaa91 ("ext4: include charset
encoding information in the superblock")
Currently this is not compatible with encryption, similar to the current
ext4 imlpementation. This will chang
Modeled after commit b886ee3e778e ("ext4: Support case-insensitive file
name lookups")
"""
This patch implements the actual support for case-insensitive file name
lookups in f2fs, based on the feature bit and the encoding stored in the
superblock.
A filesystem that has the casefold feature set is
Modeled after commit b886ee3e778e ("ext4: Support case-insensitive file
name lookups")
"""
This patch implements the actual support for case-insensitive file name
lookups in f2fs, based on the feature bit and the encoding stored in the
superblock.
A filesystem that has the casefold feature set is
Add charset encoding to f2fs to support casefolding. It is modeled after
the same feature introduced in commit c83ad55eaa91 ("ext4: include charset
encoding information in the superblock")
Currently this is not compatible with encryption, similar to the current
ext4 imlpementation. This will chang
These patches are largely based on the casefolding patches for ext4
v2: Rebased patches again master, changed f2fs_msg to f2fs_info/f2fs_err
Daniel Rosenberg (2):
f2fs: include charset encoding information in the superblock
f2fs: Support case-insensitive file name lookups
fs/f2fs/dir.c
On 7/17/19 3:11 AM, Chao Yu wrote:
We need to add one more entry f2fs_fsflags_map[] to map F2FS_CASEFOLD_FL to
FS_CASEFOLD_FL correctly and adapt F2FS_GETTABLE_FS_FL/F2FS_SETTABLE_FS_FL as
well.
I don't see FS_CASEFOLD_FL. It would make sense for it to exist, but unless
it's in some recent
Add charset encoding to f2fs to support casefolding. It is modeled after
the same feature introduced in commit c83ad55eaa91 ("ext4: include charset
encoding information in the superblock")
Currently this is not compatible with encryption, similar to the current
ext4 imlpementation. This will chang
Modeled after commit b886ee3e778e ("ext4: Support case-insensitive file
name lookups")
"""
This patch implements the actual support for case-insensitive file name
lookups in f2fs, based on the feature bit and the encoding stored in the
superblock.
A filesystem that has the casefold feature set is
These patches are largely based on the casefolding patches for ext4
v3: Addressed feedback, apart from F2FS_CASEFOLD_FL/FS_CASEFOLD_FL
Added sysfs file "encoding" to see the encoding set on a filesystem
v2: Rebased patches again master, changed f2fs_msg to f2fs_info/f2fs_err
Daniel Rosenberg
These patches are largely based on the casefolding patches for ext4
v4: Added FS_CASEFOLD_FL flag, added documentation that escaped the last
format-patch, moved setting dentry ops to f2fs_setup_casefold
v3: Addressed feedback, apart from F2FS_CASEFOLD_FL/FS_CASEFOLD_FL
Added sysfs file "en
Modeled after commit b886ee3e778e ("ext4: Support case-insensitive file
name lookups")
"""
This patch implements the actual support for case-insensitive file name
lookups in f2fs, based on the feature bit and the encoding stored in the
superblock.
A filesystem that has the casefold feature set is
In preparation for including the casefold feature within f2fs, elevate
the EXT4_CASEFOLD_FL flag to FS_CASEFOLD_FL.
Signed-off-by: Daniel Rosenberg
---
include/uapi/linux/fs.h | 1 +
tools/include/uapi/linux/fs.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/uapi/linux/fs.h
Add charset encoding to f2fs to support casefolding. It is modeled after
the same feature introduced in commit c83ad55eaa91 ("ext4: include charset
encoding information in the superblock")
Currently this is not compatible with encryption, similar to the current
ext4 imlpementation. This will chang
This adds support for encryption with casefolding.
Since the name on disk is case preserving, and also encrypted, we can no
longer just recompute the hash on the fly. Additionally, to avoid
leaking extra information from the hash of the unencrypted name, we use
siphash via an fscrypt v2 policy.
T
When using casefolding along with encryption, we need to use a
cryptographic hash to allow fast filesystem operations while not knowing
the case of the name stored on disk while not revealing extra
information about the name if the key is not present.
When a v2 policy is used on a directory, we de
Switch over to using the struct entries added to the VFS, and
remove the redundant dentry operations.
Signed-off-by: Daniel Rosenberg
---
fs/ext4/dir.c | 47 ---
fs/ext4/ext4.h | 4
fs/ext4/hash.c | 2 +-
fs/ext4/namei.c | 16 ---
This expands f2fs's casefolding support to include encrypted
directories. For encrypted directories, we use the siphash of the
casefolded name. This ensures there is no direct way to go from an
unencrypted name to the stored hash on disk without knowledge of the
encryption policy keys.
Additionall
Encrypted and casefolded names always require a dirtree hash, since
their hash values cannot be generated without the key.
In the new format, we always base64 encode the same structure. For names
that are less than 149 characters, we concatenate the provided hash and
ciphertext. If the name is lon
Casefolding requires a derived key for computing the siphash.
This is available for v2 policies, but not v1, so we disallow it for v1.
Signed-off-by: Daniel Rosenberg
---
fs/crypto/policy.c | 26 +++---
fs/inode.c | 8
include/linux/fscrypt.h | 7
Matching names with casefolded encrypting directories requires
decrypting entries to confirm case since we are case preserving. We can
avoid needing to decrypt if our hash values don't match.
Signed-off-by: Daniel Rosenberg
---
fs/ext4/ext4.h | 17 ---
fs/ext4/namei.c | 57 +
Ext4 and F2fs are both using casefolding, and they, along with any other
filesystem that adds the feature, will be using identical dentry_ops.
Additionally, those dentry ops interfere with the dentry_ops required
for fscrypt once we add support for casefolding and encryption.
Moving this into the v
Ext4 and F2FS currently both support casefolding and encryption, but not at the
same time. These patches aim to rectify that.
Since directory names are stored case preserved, we cannot just take the hash
of the ciphertext. Instead we use the siphash of the casefolded name. With this
we no longer h
This is a placeholder patch for the patches that were based
on the fscypt dev patch. The only affect for the other
patches is that they're missing a const or two that top of
tree fscrypt would allow.
Signed-off-by: Daniel Rosenberg
---
This patch is just a placeholder so the rest don't need to be
Matching names with casefolded encrypting directories requires
decrypting entries to confirm case since we are case preserving. We can
avoid needing to decrypt if our hash values don't match.
Signed-off-by: Daniel Rosenberg
---
fs/ext4/ext4.h | 17 ---
fs/ext4/namei.c | 55 +
Switch over to using the struct entries added to the VFS
Signed-off-by: Daniel Rosenberg
---
fs/ext4/dir.c | 47 ---
fs/ext4/ext4.h | 4
fs/ext4/hash.c | 2 +-
fs/ext4/namei.c | 20
fs/ext4/super.c | 15 +--
Ext4 and F2fs are both using casefolding, and they, along with any other
filesystem that adds the feature, will be using identical dentry_ops.
Additionally, those dentry ops interfere with the dentry_ops required
for fscrypt once we add support for casefolding and encryption.
Moving this into the v
Ext4 and F2FS currently both support casefolding and encryption, but not at
the same time. These patches aim to rectify that.
Since directory names are stored case preserved, we cannot just take the hash
of the ciphertext. Instead we use the siphash of the casefolded name. With this
we no longer h
This expands f2fs's casefolding support to include encrypted
directories. For encrypted directories, we use the siphash of the
casefolded name. This ensures there is no direct way to go from an
unencrypted name to the stored hash on disk without knowledge of the
encryption policy keys.
Additionall
This adds support for encryption with casefolding.
Since the name on disk is case preserving, and also encrypted, we can no
longer just recompute the hash on the fly. Additionally, to avoid
leaking extra information from the hash of the unencrypted name, we use
siphash via an fscrypt v2 policy.
T
On Wed, Jan 8, 2020 at 10:50 AM Theodore Y. Ts'o wrote:
>
> On Mon, Jan 06, 2020 at 09:16:32PM -0800, Daniel Rosenberg wrote:
> > changes:
> > fscrypt moved to separate thread to rebase on fscrypt dev branch
> > addressed feedback, plus some minor fixes
>
> What branch was this based on? There is
These patches are all on top of fscrypt's developement branch
Ext4 and F2FS currently both support casefolding and encryption, but not at
the same time. These patches aim to rectify that.
Since directory names are stored case preserved, we cannot just take the hash
of the ciphertext. Instead we u
This adds support for encryption with casefolding.
Since the name on disk is case preserving, and also encrypted, we can no
longer just recompute the hash on the fly. Additionally, to avoid
leaking extra information from the hash of the unencrypted name, we use
siphash via an fscrypt v2 policy.
T
Ext4 and F2fs are both using casefolding, and they, along with any other
filesystem that adds the feature, will be using identical dentry_ops.
Additionally, those dentry ops interfere with the dentry_ops required
for fscrypt once we add support for casefolding and encryption.
Moving this into the v
Switch over to using the struct entries added to the VFS
Signed-off-by: Daniel Rosenberg
---
fs/ext4/dir.c | 47 ---
fs/ext4/ext4.h | 4
fs/ext4/hash.c | 2 +-
fs/ext4/namei.c | 20
fs/ext4/super.c | 15 +--
Matching names with casefolded encrypting directories requires
decrypting entries to confirm case since we are case preserving. We can
avoid needing to decrypt if our hash values don't match.
Signed-off-by: Daniel Rosenberg
---
fs/ext4/ext4.h | 17 ---
fs/ext4/namei.c | 55 +
Casefolding currently requires a derived key for computing the siphash.
This is available for v2 policies, but not v1, so we disallow it for v1.
Signed-off-by: Daniel Rosenberg
---
fs/crypto/policy.c | 28
fs/inode.c | 3 ++-
include/linux/fscrypt.
Fscrypt supplies a no-key token in place of file names when the name is
encrypted and the key is not present. In the current scheme, the no-key
token is the base64 encoded ciphertext of the name, unless the name is
longer than a certain amount, after which it uses an alternative scheme
which includ
With encryption and casefolding, we cannot simply take the hash of the
ciphertext because of case insensitivity, and we can't take the hash of
the unencrypted name since that would leak information about the
encrypted name. Instead we can use siphash to compute a keyed hash of
the file names.
When
This expands f2fs's casefolding support to include encrypted
directories. For encrypted directories, we use the siphash of the
casefolded name. This ensures there is no direct way to go from an
unencrypted name to the stored hash on disk without knowledge of the
encryption policy keys.
Additionall
If a directory isn't casefolded, it doesn't need the hash key. Skip
deriving it unless we enable it later.
Signed-off-by: Daniel Rosenberg
---
fs/crypto/keysetup.c | 2 +-
fs/crypto/policy.c | 25 +
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/fs/cryp
On Mon, Jan 20, 2020 at 2:34 PM Eric Biggers wrote:
>
> From: Eric Biggers
>
> Now that there's sometimes a second type of per-file key (the dirhash
> key), clarify some function names, macros, and documentation that
> specifically deal with per-file *encryption* keys.
>
> Signed-off-by: Eric Big
On Wed, Jan 22, 2020 at 3:06 PM Eric Biggers wrote:
>
> I've applied this series to fscrypt.git#master; however I'd still like
> Acked-bys
> from the UBIFS maintainers on the two UBIFS patches, as well as more
> Reviewed-bys from anyone interested. If I don't hear anything from anyone, I
> might
1 - 100 of 200 matches
Mail list logo
