From: Luca Boccassi <Luca.Boccassi@microsoft.com>
To: "ebiggers@kernel.org" <ebiggers@kernel.org>
Cc: "Jes.Sorensen@gmail.com" <Jes.Sorensen@gmail.com>,
"linux-fscrypt@vger.kernel.org" <linux-fscrypt@vger.kernel.org>
Subject: Re: [fsverity-utils RFC PATCH] Add libfsverity_enable() API
Date: Mon, 16 Nov 2020 11:53:47 +0000 [thread overview]
Message-ID: <6c8adbaada81eede82a73e56439d54b62f13bb80.camel@microsoft.com> (raw)
In-Reply-To: <X68jCECcvkXs5VWf@sol.localdomain>
[-- Attachment #1: Type: text/plain, Size: 4341 bytes --]
On Fri, 2020-11-13 at 16:21 -0800, Eric Biggers wrote:
> On Fri, Nov 13, 2020 at 02:35:27PM +0000, luca.boccassi@gmail.com wrote:
> > From: Luca Boccassi <luca.boccassi@microsoft.com>
> >
> > Factor out the 'fsverity enable' implementation in the library, to
> > give users a shortcut for reading signatures and enabling a file
> > with the default parameters.
> >
> > Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > ---
> > Marked as RFC to get guidance on how to deal with helper functions
> > duplication, that right now are part of the "programs" utility objects
> > and not usable from the "library" objects.
> > There's dozens of different ways to handle this, all equally valid, so
> > it's down to the preference of the maintainer (eg: new common helpers,
> > include helpers at build time, further splits of sources, etc).
> > Please provide a preference and I'll follow up.
> >
> > common/common_defs.h | 9 ++
> > include/libfsverity.h | 21 +++++
> > lib/enable.c | 191 ++++++++++++++++++++++++++++++++++++++++++
> > programs/cmd_enable.c | 66 ++-------------
> > programs/fsverity.h | 9 --
> > 5 files changed, 227 insertions(+), 69 deletions(-)
> > create mode 100644 lib/enable.c
> >
> > diff --git a/common/common_defs.h b/common/common_defs.h
> > index 279385a..871db2c 100644
> > --- a/common/common_defs.h
> > +++ b/common/common_defs.h
> > @@ -90,4 +90,13 @@ static inline int ilog2(unsigned long n)
> > # define le64_to_cpu(v) (__builtin_bswap64((__force u64)(v)))
> > #endif
> >
> > +/* The hash algorithm that 'fsverity' assumes when none is specified */
> > +#define FS_VERITY_HASH_ALG_DEFAULT FS_VERITY_HASH_ALG_SHA256
> > +
> > +/*
> > + * Largest digest size among all hash algorithms supported by fs-verity.
> > + * This can be increased if needed.
> > + */
> > +#define FS_VERITY_MAX_DIGEST_SIZE 64
> > +
> > #endif /* COMMON_COMMON_DEFS_H */
> > diff --git a/include/libfsverity.h b/include/libfsverity.h
> > index 8f78a13..8d1f93b 100644
> > --- a/include/libfsverity.h
> > +++ b/include/libfsverity.h
> > @@ -112,6 +112,27 @@ libfsverity_sign_digest(const struct libfsverity_digest *digest,
> > const struct libfsverity_signature_params *sig_params,
> > uint8_t **sig_ret, size_t *sig_size_ret);
> >
> > +/**
> > + * libfsverity_enable() - Enable fs-verity on a file
> > + * An fsverity_digest (also called a "file measurement") is the root of
> > + * a file's Merkle tree. Not to be confused with a traditional file
> > + * digest computed over the entire file.
> > + * @file: path to the file to enable
> > + * @signature: (optional) path to signature for @file
> > + * @params: struct libfsverity_merkle_tree_params specifying the fs-verity
> > + * version, the hash algorithm, the block size, and
> > + * optionally a salt. Reserved fields must be zero.
> > + * All fields bar the version are optional, and defaults will be used
> > + * if set to zero.
> > + *
> > + * Returns:
> > + * * 0 for success, -EINVAL for invalid input arguments, or a generic error
> > + * if the FS_IOC_ENABLE_VERITY ioctl fails.
> > + */
> > +int
> > +libfsverity_enable(const char *file, const char *signature,
> > + struct libfsverity_merkle_tree_params *params);
> > +
> > /**
> > * libfsverity_find_hash_alg_by_name() - Find hash algorithm by name
> > * @name: Pointer to name of hash algorithm
>
> Hi Luca, can you consider
> https://lkml.kernel.org/linux-fscrypt/20201114001529.185751-1-ebiggers@kernel.org/T/#u
> instead?
>
> It's somewhat useful to have a wrapper around FS_IOC_ENABLE_VERITY that takes
> 'struct libfsverity_merkle_tree_params', so that library users can deal with one
> common struct. (And I took advantage of that to simplify the code that parses
> the parameters.)
>
> But I think we should keep it as a thin wrapper, and not have file path
> parameters or set defaults in the libfsverity_merkle_tree_params. The library
> user is better suited to deal with those, like they already do for
> libfsverity_compute_digest().
>
> - Eric
Hi,
Sure, no problem, we can drop this, thanks for sending those series.
Left a comment in the other thread.
--
Kind regards,
Luca Boccassi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2020-11-16 12:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-13 14:35 [fsverity-utils RFC PATCH] Add libfsverity_enable() API luca.boccassi
2020-11-13 22:54 ` Marcus Hüwe
2020-11-14 0:21 ` Eric Biggers
2020-11-16 11:53 ` Luca Boccassi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6c8adbaada81eede82a73e56439d54b62f13bb80.camel@microsoft.com \
--to=luca.boccassi@microsoft.com \
--cc=Jes.Sorensen@gmail.com \
--cc=ebiggers@kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox