All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.