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 PATCH 1/2] lib: add libfsverity_enable() and libfsverity_enable_with_sig()
Date: Mon, 16 Nov 2020 19:28:03 +0000 [thread overview]
Message-ID: <8f78926bb24a7b987cc586973592a2c49dccf645.camel@microsoft.com> (raw)
In-Reply-To: <20201116184207.GA1750990@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4878 bytes --]
On Mon, 2020-11-16 at 10:42 -0800, Eric Biggers wrote:
> On Mon, Nov 16, 2020 at 05:50:45PM +0000, Luca Boccassi wrote:
> > On Mon, 2020-11-16 at 09:41 -0800, Eric Biggers wrote:
> > > On Mon, Nov 16, 2020 at 11:52:57AM +0000, Luca Boccassi wrote:
> > > > On Fri, 2020-11-13 at 16:15 -0800, Eric Biggers wrote:
> > > > > From: Eric Biggers <ebiggers@google.com>
> > > > >
> > > > > Add convenience functions that wrap FS_IOC_ENABLE_VERITY but take a
> > > > > 'struct libfsverity_merkle_tree_params' instead of
> > > > > 'struct fsverity_enable_arg'. This is useful because it allows
> > > > > libfsverity users to deal with one common struct.
> > > > >
> > > > > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > > > > ---
> > > > > include/libfsverity.h | 36 ++++++++++++++++++++++++++++++++++
> > > > > lib/enable.c | 45 +++++++++++++++++++++++++++++++++++++++++++
> > > > > programs/cmd_enable.c | 28 +++++++++++++++------------
> > > > > 3 files changed, 97 insertions(+), 12 deletions(-)
> > > > > create mode 100644 lib/enable.c
> > > > >
> > > > > diff --git a/include/libfsverity.h b/include/libfsverity.h
> > > > > index 8f78a13..a8aecaf 100644
> > > > > --- a/include/libfsverity.h
> > > > > +++ b/include/libfsverity.h
> > > > > @@ -112,6 +112,42 @@ 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
> > > > > + * @fd: read-only file descriptor to the file
> > > > > + * @params: pointer to the Merkle tree parameters
> > > > > + *
> > > > > + * This is a simple wrapper around the FS_IOC_ENABLE_VERITY ioctl.
> > > > > + *
> > > > > + * Return: 0 on success, -EINVAL for invalid arguments, or a negative errno
> > > > > + * value from the FS_IOC_ENABLE_VERITY ioctl. See
> > > > > + * Documentation/filesystems/fsverity.rst in the kernel source tree for
> > > > > + * the possible error codes from FS_IOC_ENABLE_VERITY.
> > > > > + */
> > > > > +int
> > > > > +libfsverity_enable(int fd, const struct libfsverity_merkle_tree_params *params);
> > > > > +
> > > > > +/**
> > > > > + * libfsverity_enable_with_sig() - Enable fs-verity on a file, with a signature
> > > > > + * @fd: read-only file descriptor to the file
> > > > > + * @params: pointer to the Merkle tree parameters
> > > > > + * @sig: pointer to the file's signature
> > > > > + * @sig_size: size of the file's signature in bytes
> > > > > + *
> > > > > + * Like libfsverity_enable(), but allows specifying a built-in signature (i.e. a
> > > > > + * singature created with libfsverity_sign_digest()) to associate with the file.
> > > > > + * This is only needed if the in-kernel signature verification support is being
> > > > > + * used; it is not needed if signatures are being verified in userspace.
> > > > > + *
> > > > > + * If @sig is NULL and @sig_size is 0, this is the same as libfsverity_enable().
> > > > > + *
> > > > > + * Return: See libfsverity_enable().
> > > > > + */
> > > > > +int
> > > > > +libfsverity_enable_with_sig(int fd,
> > > > > + const struct libfsverity_merkle_tree_params *params,
> > > > > + const uint8_t *sig, size_t sig_size);
> > > > > +
> > > >
> > > > I don't have a strong preference either way, but any specific reason
> > > > for a separate function rather than treating sig == NULL and sig_size
> > > > == 0 as a signature-less enable? For clients deploying files, it would
> > > > appear easier to me to just use empty parameters to choose between
> > > > signed/not signed, without having to also change which API to call. But
> > > > maybe there's some use case I'm missing where it's better to be
> > > > explicit.
> > >
> > > libfsverity_enable_with_sig() works since that; it allows sig == NULL and
> > > sig_size == 0.
> > >
> > > The reason I don't want the regular libfsverity_enable() to take the signature
> > > parameters is that I'd like to encourage people to do userspace signature
> > > verification instead. I want to avoid implying that the in-kernel signature
> > > verification is something that everyone should use. Same reason I didn't want
> > > 'fsverity digest' to output fsverity_formatted_digest by default.
> >
> > Ok, I understand - makes sense to me, thanks.
> >
> > Maybe it's worth documenting in the the header description of the API
> > that empty/null values are accepted and will result in enabling without
> > signature check?
> >
>
> It's already there:
>
> * If @sig is NULL and @sig_size is 0, this is the same as libfsverity_enable().
Ah of course, sorry, right under my nose and still missed it :-)
--
Kind regards,
Luca Boccassi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-11-16 19:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-14 0:15 [fsverity-utils PATCH 0/2] Add libfsverity_enable() API Eric Biggers
2020-11-14 0:15 ` [fsverity-utils PATCH 1/2] lib: add libfsverity_enable() and libfsverity_enable_with_sig() Eric Biggers
2020-11-16 11:52 ` Luca Boccassi
2020-11-16 17:41 ` Eric Biggers
2020-11-16 17:50 ` Luca Boccassi
2020-11-16 18:42 ` Eric Biggers
2020-11-16 19:28 ` Luca Boccassi [this message]
2020-11-14 0:15 ` [fsverity-utils PATCH 2/2] programs/fsverity: share code to parse tree parameters Eric Biggers
2020-11-16 11:32 ` Luca Boccassi
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=8f78926bb24a7b987cc586973592a2c49dccf645.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