Re: [PATCH 0/3] fsverity-utils: introduce libfsverity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/19/20 11:06 PM, Eric Biggers wrote:
> 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.

OK, thanks for the explanation, it's not a big deal going one way or the
other.

Cheers,
Jes




[Index of Archives]     [linux Cryptography]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite News]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]

  Powered by Linux