This patchset exposes the verity bit (a.k.a. FS_VERITY_FL) via statx().
This is useful because it allows applications to check whether a file is
a verity file without opening it. Opening a verity file can be
expensive because the fsverity_info is set up on open, which involves
parsing metadata and optionally verifying a cryptographic signature.
This is analogous to how various other bits are exposed through both
FS_IOC_GETFLAGS and statx(), e.g. the encrypt bit.
This patchset applies to v5.4-rc5.
Eric Biggers (4):
statx: define STATX_ATTR_VERITY
ext4: support STATX_ATTR_VERITY
f2fs: support STATX_ATTR_VERITY
docs: fs-verity: mention statx() support
Documentation/filesystems/fsverity.rst | 8 ++++++++
fs/ext4/inode.c | 5 ++++-
fs/f2fs/file.c | 5 ++++-
include/linux/stat.h | 3 ++-
include/uapi/linux/stat.h | 2 +-
5 files changed, 19 insertions(+), 4 deletions(-)
--
2.24.0.rc1.363.gb1bccd3e3d-goog
From: Eric Biggers <[email protected]>
Set the STATX_ATTR_VERITY bit when the statx() system call is used on a
verity file on ext4.
Signed-off-by: Eric Biggers <[email protected]>
---
fs/ext4/inode.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 516faa280ceda8..a7ca6517798008 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5717,12 +5717,15 @@ int ext4_getattr(const struct path *path, struct kstat *stat,
stat->attributes |= STATX_ATTR_IMMUTABLE;
if (flags & EXT4_NODUMP_FL)
stat->attributes |= STATX_ATTR_NODUMP;
+ if (flags & EXT4_VERITY_FL)
+ stat->attributes |= STATX_ATTR_VERITY;
stat->attributes_mask |= (STATX_ATTR_APPEND |
STATX_ATTR_COMPRESSED |
STATX_ATTR_ENCRYPTED |
STATX_ATTR_IMMUTABLE |
- STATX_ATTR_NODUMP);
+ STATX_ATTR_NODUMP |
+ STATX_ATTR_VERITY);
generic_fillattr(inode, stat);
return 0;
--
2.24.0.rc1.363.gb1bccd3e3d-goog
From: Eric Biggers <[email protected]>
Set the STATX_ATTR_VERITY bit when the statx() system call is used on a
verity file on f2fs.
Signed-off-by: Eric Biggers <[email protected]>
---
fs/f2fs/file.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 29bc0a542759a2..6a2e5b7d8fc74c 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -726,11 +726,14 @@ int f2fs_getattr(const struct path *path, struct kstat *stat,
stat->attributes |= STATX_ATTR_IMMUTABLE;
if (flags & F2FS_NODUMP_FL)
stat->attributes |= STATX_ATTR_NODUMP;
+ if (IS_VERITY(inode))
+ stat->attributes |= STATX_ATTR_VERITY;
stat->attributes_mask |= (STATX_ATTR_APPEND |
STATX_ATTR_ENCRYPTED |
STATX_ATTR_IMMUTABLE |
- STATX_ATTR_NODUMP);
+ STATX_ATTR_NODUMP |
+ STATX_ATTR_VERITY);
generic_fillattr(inode, stat);
--
2.24.0.rc1.363.gb1bccd3e3d-goog
From: Eric Biggers <[email protected]>
Add a statx attribute bit STATX_ATTR_VERITY which will be set if the
file has fs-verity enabled. This is the statx() equivalent of
FS_VERITY_FL which is returned by FS_IOC_GETFLAGS.
This is useful because it allows applications to check whether a file is
a verity file without opening it. Opening a verity file can be
expensive because the fsverity_info is set up on open, which involves
parsing metadata and optionally verifying a cryptographic signature.
This is analogous to how various other bits are exposed through both
FS_IOC_GETFLAGS and statx(), e.g. the encrypt bit.
Signed-off-by: Eric Biggers <[email protected]>
---
include/linux/stat.h | 3 ++-
include/uapi/linux/stat.h | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/stat.h b/include/linux/stat.h
index 765573dc17d659..528c4baad09146 100644
--- a/include/linux/stat.h
+++ b/include/linux/stat.h
@@ -33,7 +33,8 @@ struct kstat {
STATX_ATTR_IMMUTABLE | \
STATX_ATTR_APPEND | \
STATX_ATTR_NODUMP | \
- STATX_ATTR_ENCRYPTED \
+ STATX_ATTR_ENCRYPTED | \
+ STATX_ATTR_VERITY \
)/* Attrs corresponding to FS_*_FL flags */
u64 ino;
dev_t dev;
diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
index 7b35e98d3c58b1..ad80a5c885d598 100644
--- a/include/uapi/linux/stat.h
+++ b/include/uapi/linux/stat.h
@@ -167,8 +167,8 @@ struct statx {
#define STATX_ATTR_APPEND 0x00000020 /* [I] File is append-only */
#define STATX_ATTR_NODUMP 0x00000040 /* [I] File is not to be dumped */
#define STATX_ATTR_ENCRYPTED 0x00000800 /* [I] File requires key to decrypt in fs */
-
#define STATX_ATTR_AUTOMOUNT 0x00001000 /* Dir: Automount trigger */
+#define STATX_ATTR_VERITY 0x00100000 /* [I] Verity protected file */
#endif /* _UAPI_LINUX_STAT_H */
--
2.24.0.rc1.363.gb1bccd3e3d-goog
From: Eric Biggers <[email protected]>
Document that the statx() system call can now be used to check whether a
file is a verity file.
Signed-off-by: Eric Biggers <[email protected]>
---
Documentation/filesystems/fsverity.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst
index 42a0b6dd9e0b68..3355377a24398d 100644
--- a/Documentation/filesystems/fsverity.rst
+++ b/Documentation/filesystems/fsverity.rst
@@ -226,6 +226,14 @@ To do so, check for FS_VERITY_FL (0x00100000) in the returned flags.
The verity flag is not settable via FS_IOC_SETFLAGS. You must use
FS_IOC_ENABLE_VERITY instead, since parameters must be provided.
+statx
+-----
+
+Since Linux v5.5, the statx() system call sets STATX_ATTR_VERITY if
+the file has fs-verity enabled. This can perform better than
+FS_IOC_GETFLAGS and FS_IOC_MEASURE_VERITY because it doesn't require
+opening the file, and opening verity files can be expensive.
+
Accessing verity files
======================
--
2.24.0.rc1.363.gb1bccd3e3d-goog
On Oct 29, 2019, at 2:41 PM, Eric Biggers <[email protected]> wrote:
>
> From: Eric Biggers <[email protected]>
>
> Add a statx attribute bit STATX_ATTR_VERITY which will be set if the
> file has fs-verity enabled. This is the statx() equivalent of
> FS_VERITY_FL which is returned by FS_IOC_GETFLAGS.
>
> This is useful because it allows applications to check whether a file is
> a verity file without opening it. Opening a verity file can be
> expensive because the fsverity_info is set up on open, which involves
> parsing metadata and optionally verifying a cryptographic signature.
>
> This is analogous to how various other bits are exposed through both
> FS_IOC_GETFLAGS and statx(), e.g. the encrypt bit.
>
> Signed-off-by: Eric Biggers <[email protected]>
Reviewed-by: Andreas Dilger <[email protected]>
> ---
> include/linux/stat.h | 3 ++-
> include/uapi/linux/stat.h | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/stat.h b/include/linux/stat.h
> index 765573dc17d659..528c4baad09146 100644
> --- a/include/linux/stat.h
> +++ b/include/linux/stat.h
> @@ -33,7 +33,8 @@ struct kstat {
> STATX_ATTR_IMMUTABLE | \
> STATX_ATTR_APPEND | \
> STATX_ATTR_NODUMP | \
> - STATX_ATTR_ENCRYPTED \
> + STATX_ATTR_ENCRYPTED | \
> + STATX_ATTR_VERITY \
> )/* Attrs corresponding to FS_*_FL flags */
> u64 ino;
> dev_t dev;
> diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
> index 7b35e98d3c58b1..ad80a5c885d598 100644
> --- a/include/uapi/linux/stat.h
> +++ b/include/uapi/linux/stat.h
> @@ -167,8 +167,8 @@ struct statx {
> #define STATX_ATTR_APPEND 0x00000020 /* [I] File is append-only */
> #define STATX_ATTR_NODUMP 0x00000040 /* [I] File is not to be dumped */
> #define STATX_ATTR_ENCRYPTED 0x00000800 /* [I] File requires key to decrypt in fs */
> -
> #define STATX_ATTR_AUTOMOUNT 0x00001000 /* Dir: Automount trigger */
> +#define STATX_ATTR_VERITY 0x00100000 /* [I] Verity protected file */
>
>
> #endif /* _UAPI_LINUX_STAT_H */
> --
> 2.24.0.rc1.363.gb1bccd3e3d-goog
>
Cheers, Andreas
> On Oct 29, 2019, at 2:41 PM, Eric Biggers <[email protected]> wrote:
>
> From: Eric Biggers <[email protected]>
>
> Set the STATX_ATTR_VERITY bit when the statx() system call is used on a
> verity file on ext4.
>
> Signed-off-by: Eric Biggers <[email protected]>
Reviewed-by: Andreas Dilger <[email protected]>
> ---
> fs/ext4/inode.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 516faa280ceda8..a7ca6517798008 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -5717,12 +5717,15 @@ int ext4_getattr(const struct path *path, struct kstat *stat,
> stat->attributes |= STATX_ATTR_IMMUTABLE;
> if (flags & EXT4_NODUMP_FL)
> stat->attributes |= STATX_ATTR_NODUMP;
> + if (flags & EXT4_VERITY_FL)
> + stat->attributes |= STATX_ATTR_VERITY;
>
> stat->attributes_mask |= (STATX_ATTR_APPEND |
> STATX_ATTR_COMPRESSED |
> STATX_ATTR_ENCRYPTED |
> STATX_ATTR_IMMUTABLE |
> - STATX_ATTR_NODUMP);
> + STATX_ATTR_NODUMP |
> + STATX_ATTR_VERITY);
>
> generic_fillattr(inode, stat);
> return 0;
> --
> 2.24.0.rc1.363.gb1bccd3e3d-goog
>
Cheers, Andreas
On Tue, Oct 29, 2019 at 01:41:37PM -0700, Eric Biggers wrote:
> This patchset exposes the verity bit (a.k.a. FS_VERITY_FL) via statx().
>
> This is useful because it allows applications to check whether a file is
> a verity file without opening it. Opening a verity file can be
> expensive because the fsverity_info is set up on open, which involves
> parsing metadata and optionally verifying a cryptographic signature.
>
> This is analogous to how various other bits are exposed through both
> FS_IOC_GETFLAGS and statx(), e.g. the encrypt bit.
>
> This patchset applies to v5.4-rc5.
>
> Eric Biggers (4):
> statx: define STATX_ATTR_VERITY
> ext4: support STATX_ATTR_VERITY
> f2fs: support STATX_ATTR_VERITY
> docs: fs-verity: mention statx() support
>
> Documentation/filesystems/fsverity.rst | 8 ++++++++
> fs/ext4/inode.c | 5 ++++-
> fs/f2fs/file.c | 5 ++++-
> include/linux/stat.h | 3 ++-
> include/uapi/linux/stat.h | 2 +-
> 5 files changed, 19 insertions(+), 4 deletions(-)
>
Any more comments on this?
- Eric
On Tue, Oct 29, 2019 at 01:41:38PM -0700, Eric Biggers wrote:
> From: Eric Biggers <[email protected]>
>
> Add a statx attribute bit STATX_ATTR_VERITY which will be set if the
> file has fs-verity enabled. This is the statx() equivalent of
> FS_VERITY_FL which is returned by FS_IOC_GETFLAGS.
>
> This is useful because it allows applications to check whether a file is
> a verity file without opening it. Opening a verity file can be
> expensive because the fsverity_info is set up on open, which involves
> parsing metadata and optionally verifying a cryptographic signature.
>
> This is analogous to how various other bits are exposed through both
> FS_IOC_GETFLAGS and statx(), e.g. the encrypt bit.
>
> Signed-off-by: Eric Biggers <[email protected]>
> ---
> include/linux/stat.h | 3 ++-
> include/uapi/linux/stat.h | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/stat.h b/include/linux/stat.h
> index 765573dc17d659..528c4baad09146 100644
> --- a/include/linux/stat.h
> +++ b/include/linux/stat.h
> @@ -33,7 +33,8 @@ struct kstat {
> STATX_ATTR_IMMUTABLE | \
> STATX_ATTR_APPEND | \
> STATX_ATTR_NODUMP | \
> - STATX_ATTR_ENCRYPTED \
> + STATX_ATTR_ENCRYPTED | \
> + STATX_ATTR_VERITY \
> )/* Attrs corresponding to FS_*_FL flags */
> u64 ino;
> dev_t dev;
> diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
> index 7b35e98d3c58b1..ad80a5c885d598 100644
> --- a/include/uapi/linux/stat.h
> +++ b/include/uapi/linux/stat.h
> @@ -167,8 +167,8 @@ struct statx {
> #define STATX_ATTR_APPEND 0x00000020 /* [I] File is append-only */
> #define STATX_ATTR_NODUMP 0x00000040 /* [I] File is not to be dumped */
> #define STATX_ATTR_ENCRYPTED 0x00000800 /* [I] File requires key to decrypt in fs */
> -
> #define STATX_ATTR_AUTOMOUNT 0x00001000 /* Dir: Automount trigger */
> +#define STATX_ATTR_VERITY 0x00100000 /* [I] Verity protected file */
Any reason why this wasn't 0x2000?
If there's a manpage update that goes with this, then...
Acked-by: Darrick J. Wong <[email protected]>
--D
>
>
> #endif /* _UAPI_LINUX_STAT_H */
> --
> 2.24.0.rc1.363.gb1bccd3e3d-goog
>
On Nov 6, 2019, at 6:44 PM, Darrick J. Wong <[email protected]> wrote:
>
> On Tue, Oct 29, 2019 at 01:41:38PM -0700, Eric Biggers wrote:
>> From: Eric Biggers <[email protected]>
>>
>> Add a statx attribute bit STATX_ATTR_VERITY which will be set if the
>> file has fs-verity enabled. This is the statx() equivalent of
>> FS_VERITY_FL which is returned by FS_IOC_GETFLAGS.
>>
>> This is useful because it allows applications to check whether a file is
>> a verity file without opening it. Opening a verity file can be
>> expensive because the fsverity_info is set up on open, which involves
>> parsing metadata and optionally verifying a cryptographic signature.
>>
>> This is analogous to how various other bits are exposed through both
>> FS_IOC_GETFLAGS and statx(), e.g. the encrypt bit.
>>
>> Signed-off-by: Eric Biggers <[email protected]>
>> ---
>> include/linux/stat.h | 3 ++-
>> include/uapi/linux/stat.h | 2 +-
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/stat.h b/include/linux/stat.h
>> index 765573dc17d659..528c4baad09146 100644
>> --- a/include/linux/stat.h
>> +++ b/include/linux/stat.h
>> @@ -33,7 +33,8 @@ struct kstat {
>> STATX_ATTR_IMMUTABLE | \
>> STATX_ATTR_APPEND | \
>> STATX_ATTR_NODUMP | \
>> - STATX_ATTR_ENCRYPTED \
>> + STATX_ATTR_ENCRYPTED | \
>> + STATX_ATTR_VERITY \
>> )/* Attrs corresponding to FS_*_FL flags */
>> u64 ino;
>> dev_t dev;
>> diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
>> index 7b35e98d3c58b1..ad80a5c885d598 100644
>> --- a/include/uapi/linux/stat.h
>> +++ b/include/uapi/linux/stat.h
>> @@ -167,8 +167,8 @@ struct statx {
>> #define STATX_ATTR_APPEND 0x00000020 /* [I] File is append-only */
>> #define STATX_ATTR_NODUMP 0x00000040 /* [I] File is not to be dumped */
>> #define STATX_ATTR_ENCRYPTED 0x00000800 /* [I] File requires key to decrypt in fs */
>> -
>> #define STATX_ATTR_AUTOMOUNT 0x00001000 /* Dir: Automount trigger */
>> +#define STATX_ATTR_VERITY 0x00100000 /* [I] Verity protected file */
>
> Any reason why this wasn't 0x2000?
A few lines earlier in this file it states:
* Note that the flags marked [I] correspond to generic FS_IOC_FLAGS
* semantically. Where possible, the numerical value is picked to
* correspond also.
Cheers, Andreas
From: Eric Biggers <[email protected]>
Document the verity attribute for statx().
Signed-off-by: Eric Biggers <[email protected]>
---
man2/statx.2 | 4 ++++
1 file changed, 4 insertions(+)
RFC since the kernel patches are currently under review.
The kernel patches can be found here:
https://lkml.kernel.org/linux-fscrypt/[email protected]/T/#u
diff --git a/man2/statx.2 b/man2/statx.2
index d2f1b07b8..713bd1260 100644
--- a/man2/statx.2
+++ b/man2/statx.2
@@ -461,6 +461,10 @@ See
.TP
.B STATX_ATTR_ENCRYPTED
A key is required for the file to be encrypted by the filesystem.
+.TP
+.B STATX_ATTR_VERITY
+The file has fs-verity enabled. It cannot be written to, and all reads from it
+will be verified against a Merkle tree.
.SH RETURN VALUE
On success, zero is returned.
On error, \-1 is returned, and
--
2.24.0.rc1.363.gb1bccd3e3d-goog
On Wed, Nov 06, 2019 at 05:44:20PM -0800, Darrick J. Wong wrote:
> On Tue, Oct 29, 2019 at 01:41:38PM -0700, Eric Biggers wrote:
> > From: Eric Biggers <[email protected]>
> >
> > Add a statx attribute bit STATX_ATTR_VERITY which will be set if the
> > file has fs-verity enabled. This is the statx() equivalent of
> > FS_VERITY_FL which is returned by FS_IOC_GETFLAGS.
> >
> > This is useful because it allows applications to check whether a file is
> > a verity file without opening it. Opening a verity file can be
> > expensive because the fsverity_info is set up on open, which involves
> > parsing metadata and optionally verifying a cryptographic signature.
> >
> > This is analogous to how various other bits are exposed through both
> > FS_IOC_GETFLAGS and statx(), e.g. the encrypt bit.
> >
> > Signed-off-by: Eric Biggers <[email protected]>
> > ---
> > include/linux/stat.h | 3 ++-
> > include/uapi/linux/stat.h | 2 +-
> > 2 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/stat.h b/include/linux/stat.h
> > index 765573dc17d659..528c4baad09146 100644
> > --- a/include/linux/stat.h
> > +++ b/include/linux/stat.h
> > @@ -33,7 +33,8 @@ struct kstat {
> > STATX_ATTR_IMMUTABLE | \
> > STATX_ATTR_APPEND | \
> > STATX_ATTR_NODUMP | \
> > - STATX_ATTR_ENCRYPTED \
> > + STATX_ATTR_ENCRYPTED | \
> > + STATX_ATTR_VERITY \
> > )/* Attrs corresponding to FS_*_FL flags */
> > u64 ino;
> > dev_t dev;
> > diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
> > index 7b35e98d3c58b1..ad80a5c885d598 100644
> > --- a/include/uapi/linux/stat.h
> > +++ b/include/uapi/linux/stat.h
> > @@ -167,8 +167,8 @@ struct statx {
> > #define STATX_ATTR_APPEND 0x00000020 /* [I] File is append-only */
> > #define STATX_ATTR_NODUMP 0x00000040 /* [I] File is not to be dumped */
> > #define STATX_ATTR_ENCRYPTED 0x00000800 /* [I] File requires key to decrypt in fs */
> > -
> > #define STATX_ATTR_AUTOMOUNT 0x00001000 /* Dir: Automount trigger */
> > +#define STATX_ATTR_VERITY 0x00100000 /* [I] Verity protected file */
>
> Any reason why this wasn't 0x2000?
Yes, as Andreas pointed out, the value is chosen to match the corresponding
FS_IOC_GETFLAGS bit, like the other bits above marked [I].
>
> If there's a manpage update that goes with this, then...
> Acked-by: Darrick J. Wong <[email protected]>
>
It's pretty trivial to add it to the statx(2) man page.
I've sent out a patch for comment:
https://lkml.kernel.org/linux-fscrypt/[email protected]/
- Eric
On Thu, Nov 07, 2019 at 02:02:48PM -0800, Eric Biggers wrote:
> From: Eric Biggers <[email protected]>
>
> Document the verity attribute for statx().
>
> Signed-off-by: Eric Biggers <[email protected]>
> ---
> man2/statx.2 | 4 ++++
> 1 file changed, 4 insertions(+)
>
> RFC since the kernel patches are currently under review.
> The kernel patches can be found here:
> https://lkml.kernel.org/linux-fscrypt/[email protected]/T/#u
>
> diff --git a/man2/statx.2 b/man2/statx.2
> index d2f1b07b8..713bd1260 100644
> --- a/man2/statx.2
> +++ b/man2/statx.2
> @@ -461,6 +461,10 @@ See
> .TP
> .B STATX_ATTR_ENCRYPTED
> A key is required for the file to be encrypted by the filesystem.
> +.TP
> +.B STATX_ATTR_VERITY
> +The file has fs-verity enabled. It cannot be written to, and all reads from it
> +will be verified against a Merkle tree.
mkerrisk might ask you to start the new sentence on a separate line, but
otherwise looks good to me. :)
--D
> .SH RETURN VALUE
> On success, zero is returned.
> On error, \-1 is returned, and
> --
> 2.24.0.rc1.363.gb1bccd3e3d-goog
>
Am 07.11.2019 23:02, schrieb Eric Biggers:
> From: Eric Biggers <[email protected]>
>
> Document the verity attribute for statx().
>
> Signed-off-by: Eric Biggers <[email protected]>
> ---
> man2/statx.2 | 4 ++++
> 1 file changed, 4 insertions(+)
>
> RFC since the kernel patches are currently under review.
> The kernel patches can be found here:
> https://lkml.kernel.org/linux-fscrypt/[email protected]/T/#u
>
> diff --git a/man2/statx.2 b/man2/statx.2
> index d2f1b07b8..713bd1260 100644
> --- a/man2/statx.2
> +++ b/man2/statx.2
> @@ -461,6 +461,10 @@ See
> .TP
> .B STATX_ATTR_ENCRYPTED
> A key is required for the file to be encrypted by the filesystem.
> +.TP
> +.B STATX_ATTR_VERITY
> +The file has fs-verity enabled. It cannot be written to, and all reads from it
> +will be verified against a Merkle tree.
Using "Merkle tree" opens a can of worm and what will happen when the methode will change ?
Does it matter at all ? i would suggest "filesystem" here.
re,
wh
> .SH RETURN VALUE
> On success, zero is returned.
> On error, \-1 is returned, and
On Fri, Nov 08, 2019 at 09:23:04AM +0100, walter harms wrote:
>
>
> Am 07.11.2019 23:02, schrieb Eric Biggers:
> > From: Eric Biggers <[email protected]>
> >
> > Document the verity attribute for statx().
> >
> > Signed-off-by: Eric Biggers <[email protected]>
> > ---
> > man2/statx.2 | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > RFC since the kernel patches are currently under review.
> > The kernel patches can be found here:
> > https://lkml.kernel.org/linux-fscrypt/[email protected]/T/#u
> >
> > diff --git a/man2/statx.2 b/man2/statx.2
> > index d2f1b07b8..713bd1260 100644
> > --- a/man2/statx.2
> > +++ b/man2/statx.2
> > @@ -461,6 +461,10 @@ See
> > .TP
> > .B STATX_ATTR_ENCRYPTED
> > A key is required for the file to be encrypted by the filesystem.
> > +.TP
> > +.B STATX_ATTR_VERITY
> > +The file has fs-verity enabled. It cannot be written to, and all reads from it
> > +will be verified against a Merkle tree.
>
> Using "Merkle tree" opens a can of worm and what will happen when the methode will change ?
> Does it matter at all ? i would suggest "filesystem" here.
>
Fundamentally, fs-verity guarantees that all data read is verified against a
cryptographic hash that covers the entire file. I think it will be helpful to
convey that here, e.g. to avoid confusion with non-cryptographic, individual
block checksums supported by filesystems like btrfs and zfs.
Now, the only sane way to implement this model is with a Merkle tree, and this
is part of the fs-verity UAPI (via the file hash), so that's where I'm coming
from here. Perhaps the phrase "Merkle tree" could be interpreted too strictly,
though, so it would be better to emphasize the more abstract model. How about
the following?:
The file has fs-verity enabled. It cannot be written to, and all reads
from it will be verified against a cryptographic hash that covers the
entire file, e.g. via a Merkle tree.
- Eric
Am 08.11.2019 20:35, schrieb Eric Biggers:
> On Fri, Nov 08, 2019 at 09:23:04AM +0100, walter harms wrote:
>>
>>
>> Am 07.11.2019 23:02, schrieb Eric Biggers:
>>> From: Eric Biggers <[email protected]>
>>>
>>> Document the verity attribute for statx().
>>>
>>> Signed-off-by: Eric Biggers <[email protected]>
>>> ---
>>> man2/statx.2 | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> RFC since the kernel patches are currently under review.
>>> The kernel patches can be found here:
>>> https://lkml.kernel.org/linux-fscrypt/[email protected]/T/#u
>>>
>>> diff --git a/man2/statx.2 b/man2/statx.2
>>> index d2f1b07b8..713bd1260 100644
>>> --- a/man2/statx.2
>>> +++ b/man2/statx.2
>>> @@ -461,6 +461,10 @@ See
>>> .TP
>>> .B STATX_ATTR_ENCRYPTED
>>> A key is required for the file to be encrypted by the filesystem.
>>> +.TP
>>> +.B STATX_ATTR_VERITY
>>> +The file has fs-verity enabled. It cannot be written to, and all reads from it
>>> +will be verified against a Merkle tree.
>>
>> Using "Merkle tree" opens a can of worm and what will happen when the methode will change ?
>> Does it matter at all ? i would suggest "filesystem" here.
>>
>
> Fundamentally, fs-verity guarantees that all data read is verified against a
> cryptographic hash that covers the entire file. I think it will be helpful to
> convey that here, e.g. to avoid confusion with non-cryptographic, individual
> block checksums supported by filesystems like btrfs and zfs.
>
> Now, the only sane way to implement this model is with a Merkle tree, and this
> is part of the fs-verity UAPI (via the file hash), so that's where I'm coming
> from here. Perhaps the phrase "Merkle tree" could be interpreted too strictly,
> though, so it would be better to emphasize the more abstract model. How about
> the following?:
>
> The file has fs-verity enabled. It cannot be written to, and all reads
> from it will be verified against a cryptographic hash that covers the
> entire file, e.g. via a Merkle tree.
>
"feels" better,. but from a programmers perspective it is important at what level
this is actually done. To see my point look at the line before.
"encrypted by the filesystem" mean i have to read the documentation of the fs first
so if encryption is supported at all. Or do i think to complicated ?
jm2c,
re
wh
On Tue, Oct 29, 2019 at 01:41:37PM -0700, Eric Biggers wrote:
> This patchset exposes the verity bit (a.k.a. FS_VERITY_FL) via statx().
>
> This is useful because it allows applications to check whether a file is
> a verity file without opening it. Opening a verity file can be
> expensive because the fsverity_info is set up on open, which involves
> parsing metadata and optionally verifying a cryptographic signature.
>
> This is analogous to how various other bits are exposed through both
> FS_IOC_GETFLAGS and statx(), e.g. the encrypt bit.
>
> This patchset applies to v5.4-rc5.
>
> Eric Biggers (4):
> statx: define STATX_ATTR_VERITY
> ext4: support STATX_ATTR_VERITY
> f2fs: support STATX_ATTR_VERITY
> docs: fs-verity: mention statx() support
>
> Documentation/filesystems/fsverity.rst | 8 ++++++++
> fs/ext4/inode.c | 5 ++++-
> fs/f2fs/file.c | 5 ++++-
> include/linux/stat.h | 3 ++-
> include/uapi/linux/stat.h | 2 +-
> 5 files changed, 19 insertions(+), 4 deletions(-)
Applied to fscrypt.git#fsverity for 5.5.
- Eric
On Sat, Nov 09, 2019 at 08:34:51PM +0100, walter harms wrote:
> Am 08.11.2019 20:35, schrieb Eric Biggers:
> > On Fri, Nov 08, 2019 at 09:23:04AM +0100, walter harms wrote:
> >>
> >>
> >> Am 07.11.2019 23:02, schrieb Eric Biggers:
> >>> From: Eric Biggers <[email protected]>
> >>>
> >>> Document the verity attribute for statx().
> >>>
> >>> Signed-off-by: Eric Biggers <[email protected]>
> >>> ---
> >>> man2/statx.2 | 4 ++++
> >>> 1 file changed, 4 insertions(+)
> >>>
> >>> RFC since the kernel patches are currently under review.
> >>> The kernel patches can be found here:
> >>> https://lkml.kernel.org/linux-fscrypt/[email protected]/T/#u
> >>>
> >>> diff --git a/man2/statx.2 b/man2/statx.2
> >>> index d2f1b07b8..713bd1260 100644
> >>> --- a/man2/statx.2
> >>> +++ b/man2/statx.2
> >>> @@ -461,6 +461,10 @@ See
> >>> .TP
> >>> .B STATX_ATTR_ENCRYPTED
> >>> A key is required for the file to be encrypted by the filesystem.
> >>> +.TP
> >>> +.B STATX_ATTR_VERITY
> >>> +The file has fs-verity enabled. It cannot be written to, and all reads from it
> >>> +will be verified against a Merkle tree.
> >>
> >> Using "Merkle tree" opens a can of worm and what will happen when the methode will change ?
> >> Does it matter at all ? i would suggest "filesystem" here.
> >>
> >
> > Fundamentally, fs-verity guarantees that all data read is verified against a
> > cryptographic hash that covers the entire file. I think it will be helpful to
> > convey that here, e.g. to avoid confusion with non-cryptographic, individual
> > block checksums supported by filesystems like btrfs and zfs.
> >
> > Now, the only sane way to implement this model is with a Merkle tree, and this
> > is part of the fs-verity UAPI (via the file hash), so that's where I'm coming
> > from here. Perhaps the phrase "Merkle tree" could be interpreted too strictly,
> > though, so it would be better to emphasize the more abstract model. How about
> > the following?:
> >
> > The file has fs-verity enabled. It cannot be written to, and all reads
> > from it will be verified against a cryptographic hash that covers the
> > entire file, e.g. via a Merkle tree.
> >
>
> "feels" better,. but from a programmers perspective it is important at what level
> this is actually done. To see my point look at the line before.
> "encrypted by the filesystem" mean i have to read the documentation of the fs first
> so if encryption is supported at all. Or do i think to complicated ?
>
It's filesystem-specific whether encryption and verity are supported. I'm not
sure what your concern is, as statx() won't return the bits if the filesystem
doesn't support them.
Also note, if someone really wants the details about fscrypt and fsverity, they
really should read the documentation we maintain in the kernel tree [1][2].
[1] https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html
[2] https://www.kernel.org/doc/html/latest/filesystems/fsverity.html
- Eric