From: Jes Sorensen <jsorensen@fb.com>
To: Eric Biggers <ebiggers@kernel.org>,
Jes Sorensen <jes@trained-monkey.org>
Cc: <linux-fscrypt@vger.kernel.org>,
Jes Sorensen <jes.sorensen@gmail.com>, <kernel-team@fb.com>
Subject: Re: [PATCH 0/3] fsverity-utils: introduce libfsverity
Date: Wed, 20 May 2020 09:26:26 -0400 [thread overview]
Message-ID: <38c855ed-042c-2440-bf73-3b5a34feb931@fb.com> (raw)
In-Reply-To: <20200520030652.GC3510@sol.localdomain>
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@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.
OK, thanks for the explanation, it's not a big deal going one way or the
other.
Cheers,
Jes
prev parent reply other threads:[~2020-05-20 13:26 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
2020-05-20 13:26 ` Jes Sorensen [this message]
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=38c855ed-042c-2440-bf73-3b5a34feb931@fb.com \
--to=jsorensen@fb.com \
--cc=ebiggers@kernel.org \
--cc=jes.sorensen@gmail.com \
--cc=jes@trained-monkey.org \
--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).