[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230207235243.GA5107@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Date: Tue, 7 Feb 2023 15:52:43 -0800
From: Fan Wu <wufan@...ux.microsoft.com>
To: Roberto Sassu <roberto.sassu@...weicloud.com>
Cc: corbet@....net, zohar@...ux.ibm.com, jmorris@...ei.org,
serge@...lyn.com, tytso@....edu, ebiggers@...nel.org,
axboe@...nel.dk, agk@...hat.com, snitzer@...nel.org,
eparis@...hat.com, paul@...l-moore.com, linux-doc@...r.kernel.org,
linux-integrity@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-fscrypt@...r.kernel.org, linux-block@...r.kernel.org,
dm-devel@...hat.com, linux-audit@...hat.com,
roberto.sassu@...wei.com, linux-kernel@...r.kernel.org,
Deven Bowers <deven.desai@...ux.microsoft.com>
Subject: Re: [RFC PATCH v9 10/16] dm-verity: consume root hash digest and
signature data via LSM hook
On Thu, Feb 02, 2023 at 09:21:24AM +0100, Roberto Sassu wrote:
> On Wed, 2023-02-01 at 15:26 -0800, Fan Wu wrote:
> > On Tue, Jan 31, 2023 at 02:22:01PM +0100, Roberto Sassu wrote:
> > > On Mon, 2023-01-30 at 14:57 -0800, Fan Wu wrote:
> > > > From: Deven Bowers <deven.desai@...ux.microsoft.com>
> > > >
> > > > dm-verity provides a strong guarantee of a block device's integrity. As
> > > > a generic way to check the integrity of a block device, it provides
> > > > those integrity guarantees to its higher layers, including the filesystem
> > > > level.
> > >
> > > I think you could reuse most of is_trusted_verity_target(), in
> > > particular dm_verity_get_root_digest().
> > >
> > > And probably, the previous patch is not necessary.
> > >
> > > Roberto
> > >
> > Thanks for the info. This function seems could be used to get the roothash
> > but for saving the signature we still need the hook function in the previous
> > patch.
>
> Uhm, look at the LoadPin case. It does not need to temporarily store
> the root digest in a security blob. It evaluates it directly.
>
> Well, ok, dm_verity_loadpin_is_bdev_trusted() looks for trusted digests
> in the dm_verity_loadpin_trusted_root_digests list. So, something
> equivalent needs to be made for IPE (or you just get the digest).
> However, I find not introducing new hooks and evaluating the
> information directly more efficient.
>
> Roberto
Thanks for the input. I did a deeper dive into the source code and did some
experiements, my conclusion is the hook is still the preferred way for us.
For the root digest part, dm_verity_loadpin_is_bdev_trusted is able to query
the root digest is because the root digest is saved in struct dm_verity.
Specifically it will call dm_verity_get_root_digest to kmemdup the digest.
If every binary execution will trigger a kmemdup to copy a digest,
the overhead will be noticeable.
Using a hook can let us copy the root digest exactly once when
the block device is created and free the copied digest when
the block device is unmounted.
For the signature, it is currently an optional parameter and it is not
saved in struct dm_verity. But even if we let struct dm_verity saves
the signature it will still have the kmemdup problem above.
So using the hook will be the cleanest way.
-Fan
Powered by blists - more mailing lists