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@xxxxxx>.
> > 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
|