[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhR1gkiB=etUwgqnkZuBiSy1VD4ZgyUeTWvLQTowgQchFg@mail.gmail.com>
Date: Mon, 19 Aug 2024 15:40:58 -0400
From: Paul Moore <paul@...l-moore.com>
To: Fan Wu <wufan@...ux.microsoft.com>
Cc: Mikulas Patocka <mpatocka@...hat.com>, Mike Snitzer <snitzer@...nel.org>,
Alasdair Kergon <agk@...hat.com>, linux-doc@...r.kernel.org, linux-integrity@...r.kernel.org,
linux-security-module@...r.kernel.org, fsverity@...ts.linux.dev,
linux-block@...r.kernel.org, dm-devel@...ts.linux.dev, audit@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v20 12/20] dm verity: expose root hash digest and
signature data to LSMs
On Mon, Aug 19, 2024 at 1:47 PM Fan Wu <wufan@...ux.microsoft.com> wrote:
> On 8/18/2024 10:22 AM, Paul Moore wrote:
> > On Fri, Aug 16, 2024 at 3:11 PM Fan Wu <wufan@...ux.microsoft.com> wrote:
> >> On 8/16/2024 6:35 AM, Mikulas Patocka wrote:
> >
> > ...
> >
> >>>>>>
> >>>>>> +#ifdef CONFIG_SECURITY
> >>>>>> + u8 *root_digest_sig; /* signature of the root digest */
> >>>>>> +#endif /* CONFIG_SECURITY */
> >>>>>> unsigned int salt_size;
> >>>>>> sector_t data_start; /* data offset in 512-byte sectors */
> >>>>>> sector_t hash_start; /* hash start in blocks */
> >>>>>> @@ -58,6 +61,9 @@ struct dm_verity {
> >>>>>> bool hash_failed:1; /* set if hash of any block failed */
> >>>>>> bool use_bh_wq:1; /* try to verify in BH wq before normal work-queue */
> >>>>>> unsigned int digest_size; /* digest size for the current hash algorithm */
> >>>>>> +#ifdef CONFIG_SECURITY
> >>>>>> + unsigned int sig_size; /* root digest signature size */
> >>>>>> +#endif /* CONFIG_SECURITY */
> >>>>>> unsigned int hash_reqsize; /* the size of temporary space for crypto */
> >>>>>> enum verity_mode mode; /* mode for handling verification errors */
> >>>>>> unsigned int corrupted_errs;/* Number of errors for corrupted blocks */
> >>>
> >>> Just nit-picking: I would move "unsigned int sig_size" up, after "u8
> >>> *root_digest_sig" entry.
> >>>
> >>> Mikulas
> >>
> >> Sure, I can make these two fields together.
> >
> > Fan, do you want me to move the @sig_size field when merging or are
> > you planning to submit another revision? I'm happy to do it during
> > the merge, but I don't want to bother if you are going to post another
> > patchset.
>
> Thanks, Paul. It seems moving the field during the merge can expedite
> the process. Please go ahead with that. I appreciate your help with this!
No problem. I'm going to merge these this afternoon, I'll send
another note when they are in the repo.
--
paul-moore.com
Powered by blists - more mailing lists