From: Eric Biggers <ebiggers@kernel.org>
To: Jes Sorensen <jes@trained-monkey.org>
Cc: linux-fscrypt@vger.kernel.org,
Jes Sorensen <jes.sorensen@gmail.com>,
jsorensen@fb.com, kernel-team@fb.com
Subject: Re: [PATCH 0/3] fsverity-utils: introduce libfsverity
Date: Tue, 19 May 2020 20:06:52 -0700 [thread overview]
Message-ID: <20200520030652.GC3510@sol.localdomain> (raw)
In-Reply-To: <6fd1ea1f-d6e6-c423-4a52-c987f172bb50@trained-monkey.org>
On Fri, May 15, 2020 at 04:50:49PM -0400, Jes Sorensen wrote:
> On 5/15/20 12:10 AM, Eric Biggers wrote:
> > From the 'fsverity' program, split out a library 'libfsverity'.
> > Currently it supports computing file measurements ("digests"), and
> > signing those file measurements for use with the fs-verity builtin
> > signature verification feature.
> >
> > Rewritten from patches by Jes Sorensen <jsorensen@fb.com>.
> > I made a lot of improvements; see patch 2 for details.
> >
> > Jes, can you let me know whether this works for you? Especially take a
> > close look at the API in libfsverity.h.
>
> Hi Eric,
>
> Thanks for looking at this. I have gone through this and managed to get
> my RPM code to work with it. I will push the updated code to my rpm
> github repo shortly. I have two fixes for the Makefile I will send to
> you in a separate email.
>
> One comment I have is that you changed the size of version and
> hash_algorithm to 32 bit in struct libfsverity_merkle_tree_params, but
> the kernel API only takes 8 bit values anyway. I had them at 16 bit to
> handle the struct padding, but if anything it seems to make more sense
> to make them 8 bit and pad the struct?
>
> struct libfsverity_merkle_tree_params {
> uint32_t version;
> uint32_t hash_algorithm;
>
> That said, not a big deal.
>
Well, they're 32-bit in 'struct fsverity_enable_arg' (the argument to
FS_IOC_ENABLE_VERITY), but 8-bit in 'struct fsverity_descriptor'.
The reason for the difference is that 'struct fsverity_enable_arg' is just an
in-memory structure for the ioctl, so there was no reason not to use larger
fields. But fsverity_descriptor is stored on-disk and hashed, and it has to
have a specific byte order, so just using 8-bit fields for it seemed best.
'struct libfsverity_merkle_tree_params' is just an in-memory structure too, so I
think going with the 32-bits convention makes sense.
- Eric
next prev parent reply other threads:[~2020-05-20 3:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-15 4:10 [PATCH 0/3] fsverity-utils: introduce libfsverity Eric Biggers
2020-05-15 4:10 ` [PATCH 1/3] Split up cmd_sign.c Eric Biggers
2020-05-21 15:26 ` Jes Sorensen
2020-05-15 4:10 ` [PATCH 2/3] Introduce libfsverity Eric Biggers
2020-05-21 15:24 ` Jes Sorensen
2020-05-21 16:08 ` Eric Biggers
2020-05-21 16:45 ` Jes Sorensen
2020-05-21 16:59 ` Eric Biggers
2020-05-21 17:13 ` Jes Sorensen
2020-05-15 4:10 ` [PATCH 3/3] Add some basic test programs for libfsverity Eric Biggers
2020-05-21 15:29 ` Jes Sorensen
2020-05-15 20:50 ` [PATCH 0/3] fsverity-utils: introduce libfsverity Jes Sorensen
2020-05-20 3:06 ` Eric Biggers [this message]
2020-05-20 13:26 ` Jes Sorensen
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=20200520030652.GC3510@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=jes.sorensen@gmail.com \
--cc=jes@trained-monkey.org \
--cc=jsorensen@fb.com \
--cc=kernel-team@fb.com \
--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;
as well as URLs for NNTP newsgroup(s).