From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Fan Wu <wufan@linux.microsoft.com>
Cc: corbet@lwn.net, zohar@linux.ibm.com, jmorris@namei.org,
serge@hallyn.com, tytso@mit.edu, ebiggers@kernel.org,
axboe@kernel.dk, agk@redhat.com, snitzer@kernel.org,
eparis@redhat.com, paul@paul-moore.com,
linux-doc@vger.kernel.org, linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fscrypt@vger.kernel.org, linux-block@vger.kernel.org,
dm-devel@redhat.com, linux-audit@redhat.com,
roberto.sassu@huawei.com, linux-kernel@vger.kernel.org,
Deven Bowers <deven.desai@linux.microsoft.com>
Subject: Re: [RFC PATCH v9 13/16] ipe: enable support for fs-verity as a trust provider
Date: Thu, 02 Feb 2023 10:51:56 +0100 [thread overview]
Message-ID: <6ddfa7344d01b21a93d3909af9dac0ae5e2a79ee.camel@huaweicloud.com> (raw)
In-Reply-To: <20230201235031.GC9075@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On Wed, 2023-02-01 at 15:50 -0800, Fan Wu wrote:
> On Tue, Jan 31, 2023 at 03:00:08PM +0100, Roberto Sassu wrote:
> > On Mon, 2023-01-30 at 14:57 -0800, Fan Wu wrote:
> > > +/**
> > > + * evaluate_fsv_sig_false - Analyze @ctx against a fsv sig false property.
> > > + * @ctx: Supplies a pointer to the context being evaluated.
> > > + * @p: Supplies a pointer to the property being evaluated.
> > > + *
> > > + * Return:
> > > + * * true - The current @ctx match the @p
> > > + * * false - The current @ctx doesn't match the @p
> > > + */
> > > +static bool evaluate_fsv_sig_false(const struct ipe_eval_ctx *const ctx,
> > > + struct ipe_prop *p)
> > > +{
> > > + return !ctx->ino ||
> > > + !IS_VERITY(ctx->ino) ||
> > > + !ctx->ipe_inode ||
> > > + !ctx->ipe_inode->fs_verity_signed;
> > > +}
> > > +
> > > +/**
> > > + * evaluate_fsv_sig_true - Analyze @ctx against a fsv sig true property.
> > > + * @ctx: Supplies a pointer to the context being evaluated.
> > > + * @p: Supplies a pointer to the property being evaluated.
> > > + *
> > > + * Return:
> > > + * * true - The current @ctx match the @p
> > > + * * false - The current @ctx doesn't match the @p
> > > + */
> > > +static bool evaluate_fsv_sig_true(const struct ipe_eval_ctx *const ctx,
> > > + struct ipe_prop *p)
> > > +{
> > > + return ctx->ino &&
> > > + IS_VERITY(ctx->ino) &&
> > > + ctx->ipe_inode &&
> > > + ctx->ipe_inode->fs_verity_signed;
> > > +}
> >
> > Isn't better to just define one function and prepend a ! in
> > evaluate_property()?
> Yes that's a better way to do it, I will take this idea.
>
> > Not sure about the usefulness of the fsverity_signature= property as it
> > is. I would at minimum allow to specify which keyring signatures are
> > verified against, and ensure that the keyring has a restriction.
> >
> > And maybe I would call fsverity_verify_signature() directly, after
> > extending it to pass the desired keyring.
> >
> Thanks for the suggestion.
> For the initial version we only have the fsverity_signature property
> to enable the policy can make decision based on the existence of the
> signature. In the future we plan to add more properties to leverage
> the remaining signature information so we can have the restrictions
> you mentioned.
Uhm, these boolean properties feel like something is missing. In my
opinion, one cannot accept just any signature, but should be able to
specify the approved signers.
Roberto
> -Fan
>
> > I would also split this patch in two, one for fsverity_digest= and one
> > for fsverity_signature=.
> >
> > Roberto
WARNING: multiple messages have this Message-ID (diff)
From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Fan Wu <wufan@linux.microsoft.com>
Cc: axboe@kernel.dk, linux-block@vger.kernel.org, tytso@mit.edu,
dm-devel@redhat.com, corbet@lwn.net, roberto.sassu@huawei.com,
Deven Bowers <deven.desai@linux.microsoft.com>,
linux-doc@vger.kernel.org, snitzer@kernel.org, jmorris@namei.org,
zohar@linux.ibm.com, linux-kernel@vger.kernel.org,
ebiggers@kernel.org, linux-security-module@vger.kernel.org,
linux-audit@redhat.com, eparis@redhat.com,
linux-fscrypt@vger.kernel.org, linux-integrity@vger.kernel.org,
agk@redhat.com, serge@hallyn.com
Subject: Re: [RFC PATCH v9 13/16] ipe: enable support for fs-verity as a trust provider
Date: Thu, 02 Feb 2023 10:51:56 +0100 [thread overview]
Message-ID: <6ddfa7344d01b21a93d3909af9dac0ae5e2a79ee.camel@huaweicloud.com> (raw)
In-Reply-To: <20230201235031.GC9075@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On Wed, 2023-02-01 at 15:50 -0800, Fan Wu wrote:
> On Tue, Jan 31, 2023 at 03:00:08PM +0100, Roberto Sassu wrote:
> > On Mon, 2023-01-30 at 14:57 -0800, Fan Wu wrote:
> > > +/**
> > > + * evaluate_fsv_sig_false - Analyze @ctx against a fsv sig false property.
> > > + * @ctx: Supplies a pointer to the context being evaluated.
> > > + * @p: Supplies a pointer to the property being evaluated.
> > > + *
> > > + * Return:
> > > + * * true - The current @ctx match the @p
> > > + * * false - The current @ctx doesn't match the @p
> > > + */
> > > +static bool evaluate_fsv_sig_false(const struct ipe_eval_ctx *const ctx,
> > > + struct ipe_prop *p)
> > > +{
> > > + return !ctx->ino ||
> > > + !IS_VERITY(ctx->ino) ||
> > > + !ctx->ipe_inode ||
> > > + !ctx->ipe_inode->fs_verity_signed;
> > > +}
> > > +
> > > +/**
> > > + * evaluate_fsv_sig_true - Analyze @ctx against a fsv sig true property.
> > > + * @ctx: Supplies a pointer to the context being evaluated.
> > > + * @p: Supplies a pointer to the property being evaluated.
> > > + *
> > > + * Return:
> > > + * * true - The current @ctx match the @p
> > > + * * false - The current @ctx doesn't match the @p
> > > + */
> > > +static bool evaluate_fsv_sig_true(const struct ipe_eval_ctx *const ctx,
> > > + struct ipe_prop *p)
> > > +{
> > > + return ctx->ino &&
> > > + IS_VERITY(ctx->ino) &&
> > > + ctx->ipe_inode &&
> > > + ctx->ipe_inode->fs_verity_signed;
> > > +}
> >
> > Isn't better to just define one function and prepend a ! in
> > evaluate_property()?
> Yes that's a better way to do it, I will take this idea.
>
> > Not sure about the usefulness of the fsverity_signature= property as it
> > is. I would at minimum allow to specify which keyring signatures are
> > verified against, and ensure that the keyring has a restriction.
> >
> > And maybe I would call fsverity_verify_signature() directly, after
> > extending it to pass the desired keyring.
> >
> Thanks for the suggestion.
> For the initial version we only have the fsverity_signature property
> to enable the policy can make decision based on the existence of the
> signature. In the future we plan to add more properties to leverage
> the remaining signature information so we can have the restrictions
> you mentioned.
Uhm, these boolean properties feel like something is missing. In my
opinion, one cannot accept just any signature, but should be able to
specify the approved signers.
Roberto
> -Fan
>
> > I would also split this patch in two, one for fsverity_digest= and one
> > for fsverity_signature=.
> >
> > Roberto
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
WARNING: multiple messages have this Message-ID (diff)
From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Fan Wu <wufan@linux.microsoft.com>
Cc: axboe@kernel.dk, linux-block@vger.kernel.org, tytso@mit.edu,
paul@paul-moore.com, dm-devel@redhat.com, corbet@lwn.net,
roberto.sassu@huawei.com,
Deven Bowers <deven.desai@linux.microsoft.com>,
linux-doc@vger.kernel.org, snitzer@kernel.org, jmorris@namei.org,
zohar@linux.ibm.com, linux-kernel@vger.kernel.org,
ebiggers@kernel.org, linux-security-module@vger.kernel.org,
linux-audit@redhat.com, eparis@redhat.com,
linux-fscrypt@vger.kernel.org, linux-integrity@vger.kernel.org,
agk@redhat.com, serge@hallyn.com
Subject: Re: [dm-devel] [RFC PATCH v9 13/16] ipe: enable support for fs-verity as a trust provider
Date: Thu, 02 Feb 2023 10:51:56 +0100 [thread overview]
Message-ID: <6ddfa7344d01b21a93d3909af9dac0ae5e2a79ee.camel@huaweicloud.com> (raw)
In-Reply-To: <20230201235031.GC9075@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On Wed, 2023-02-01 at 15:50 -0800, Fan Wu wrote:
> On Tue, Jan 31, 2023 at 03:00:08PM +0100, Roberto Sassu wrote:
> > On Mon, 2023-01-30 at 14:57 -0800, Fan Wu wrote:
> > > +/**
> > > + * evaluate_fsv_sig_false - Analyze @ctx against a fsv sig false property.
> > > + * @ctx: Supplies a pointer to the context being evaluated.
> > > + * @p: Supplies a pointer to the property being evaluated.
> > > + *
> > > + * Return:
> > > + * * true - The current @ctx match the @p
> > > + * * false - The current @ctx doesn't match the @p
> > > + */
> > > +static bool evaluate_fsv_sig_false(const struct ipe_eval_ctx *const ctx,
> > > + struct ipe_prop *p)
> > > +{
> > > + return !ctx->ino ||
> > > + !IS_VERITY(ctx->ino) ||
> > > + !ctx->ipe_inode ||
> > > + !ctx->ipe_inode->fs_verity_signed;
> > > +}
> > > +
> > > +/**
> > > + * evaluate_fsv_sig_true - Analyze @ctx against a fsv sig true property.
> > > + * @ctx: Supplies a pointer to the context being evaluated.
> > > + * @p: Supplies a pointer to the property being evaluated.
> > > + *
> > > + * Return:
> > > + * * true - The current @ctx match the @p
> > > + * * false - The current @ctx doesn't match the @p
> > > + */
> > > +static bool evaluate_fsv_sig_true(const struct ipe_eval_ctx *const ctx,
> > > + struct ipe_prop *p)
> > > +{
> > > + return ctx->ino &&
> > > + IS_VERITY(ctx->ino) &&
> > > + ctx->ipe_inode &&
> > > + ctx->ipe_inode->fs_verity_signed;
> > > +}
> >
> > Isn't better to just define one function and prepend a ! in
> > evaluate_property()?
> Yes that's a better way to do it, I will take this idea.
>
> > Not sure about the usefulness of the fsverity_signature= property as it
> > is. I would at minimum allow to specify which keyring signatures are
> > verified against, and ensure that the keyring has a restriction.
> >
> > And maybe I would call fsverity_verify_signature() directly, after
> > extending it to pass the desired keyring.
> >
> Thanks for the suggestion.
> For the initial version we only have the fsverity_signature property
> to enable the policy can make decision based on the existence of the
> signature. In the future we plan to add more properties to leverage
> the remaining signature information so we can have the restrictions
> you mentioned.
Uhm, these boolean properties feel like something is missing. In my
opinion, one cannot accept just any signature, but should be able to
specify the approved signers.
Roberto
> -Fan
>
> > I would also split this patch in two, one for fsverity_digest= and one
> > for fsverity_signature=.
> >
> > Roberto
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2023-02-02 9:52 UTC|newest]
Thread overview: 225+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-30 22:57 [RFC PATCH v9 00/16] Integrity Policy Enforcement LSM (IPE) Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-01-30 22:57 ` [RFC PATCH v9 01/16] security: add ipe lsm Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-03-02 19:00 ` Paul Moore
2023-03-02 19:00 ` Paul Moore
2023-03-02 19:00 ` [dm-devel] " Paul Moore
2023-04-06 19:20 ` Fan Wu
2023-04-06 19:20 ` Fan Wu
2023-04-06 19:20 ` [dm-devel] " Fan Wu
2023-01-30 22:57 ` [RFC PATCH v9 02/16] ipe: add policy parser Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-01-31 10:53 ` Roberto Sassu
2023-01-31 10:53 ` [dm-devel] " Roberto Sassu
2023-01-31 10:53 ` Roberto Sassu
2023-02-01 22:38 ` Fan Wu
2023-02-01 22:38 ` Fan Wu
2023-02-01 22:38 ` [dm-devel] " Fan Wu
2023-03-02 19:02 ` Paul Moore
2023-03-02 19:02 ` Paul Moore
2023-03-02 19:02 ` [dm-devel] " Paul Moore
2023-04-06 20:00 ` Fan Wu
2023-04-06 20:00 ` Fan Wu
2023-04-06 20:00 ` [dm-devel] " Fan Wu
2023-04-11 19:13 ` Paul Moore
2023-04-11 19:13 ` Paul Moore
2023-04-11 19:13 ` [dm-devel] " Paul Moore
2023-01-30 22:57 ` [RFC PATCH v9 03/16] ipe: add evaluation loop and introduce 'boot_verified' as a trust provider Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-01-31 10:29 ` Roberto Sassu
2023-01-31 10:29 ` [dm-devel] " Roberto Sassu
2023-01-31 10:29 ` Roberto Sassu
2023-01-31 15:49 ` Roberto Sassu
2023-01-31 15:49 ` [dm-devel] " Roberto Sassu
2023-01-31 15:49 ` Roberto Sassu
2023-02-10 23:21 ` Fan Wu
2023-02-10 23:21 ` Fan Wu
2023-02-10 23:21 ` [dm-devel] " Fan Wu
2023-03-02 2:33 ` Paul Moore
2023-03-02 2:33 ` Paul Moore
2023-03-02 2:33 ` [dm-devel] " Paul Moore
2023-03-02 19:03 ` Paul Moore
2023-03-02 19:03 ` Paul Moore
2023-03-02 19:03 ` Paul Moore
2023-04-10 18:53 ` Fan Wu
2023-04-10 18:53 ` Fan Wu
2023-04-10 18:53 ` [dm-devel] " Fan Wu
2023-04-11 20:32 ` Paul Moore
2023-04-11 20:32 ` Paul Moore
2023-04-11 20:32 ` [dm-devel] " Paul Moore
2023-01-30 22:57 ` [RFC PATCH v9 04/16] security: add new securityfs delete function Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-01-30 22:57 ` [RFC PATCH v9 05/16] ipe: add userspace interface Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-01-31 10:49 ` Roberto Sassu
2023-01-31 10:49 ` [dm-devel] " Roberto Sassu
2023-01-31 10:49 ` Roberto Sassu
2023-02-01 19:46 ` Fan Wu
2023-02-01 19:46 ` [dm-devel] " Fan Wu
2023-02-01 19:46 ` Fan Wu
2023-02-05 8:42 ` kernel test robot
2023-03-02 19:04 ` Paul Moore
2023-03-02 19:04 ` Paul Moore
2023-03-02 19:04 ` [dm-devel] " Paul Moore
2023-04-10 19:10 ` Fan Wu
2023-04-10 19:10 ` Fan Wu
2023-04-10 19:10 ` [dm-devel] " Fan Wu
2023-04-11 21:45 ` Paul Moore
2023-04-11 21:45 ` Paul Moore
2023-04-11 21:45 ` [dm-devel] " Paul Moore
2023-04-12 23:36 ` Fan Wu
2023-04-12 23:36 ` Fan Wu
2023-04-12 23:36 ` [dm-devel] " Fan Wu
2023-04-13 18:45 ` Paul Moore
2023-04-13 18:45 ` Paul Moore
2023-04-13 18:45 ` [dm-devel] " Paul Moore
2023-04-17 18:06 ` Fan Wu
2023-04-17 18:06 ` Fan Wu
2023-04-17 18:06 ` [dm-devel] " Fan Wu
2023-04-17 20:16 ` Paul Moore
2023-04-17 20:16 ` Paul Moore
2023-04-17 20:16 ` [dm-devel] " Paul Moore
2023-04-17 21:18 ` Fan Wu
2023-04-17 21:18 ` Fan Wu
2023-04-17 21:18 ` [dm-devel] " Fan Wu
2023-04-17 21:31 ` Paul Moore
2023-04-17 21:31 ` Paul Moore
2023-04-17 21:31 ` [dm-devel] " Paul Moore
2023-01-30 22:57 ` [RFC PATCH v9 06/16] ipe: add LSM hooks on execution and kernel read Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-01-31 12:51 ` Roberto Sassu
2023-01-31 12:51 ` [dm-devel] " Roberto Sassu
2023-01-31 12:51 ` Roberto Sassu
2023-02-09 22:42 ` Fan Wu
2023-02-09 22:42 ` Fan Wu
2023-02-09 22:42 ` [dm-devel] " Fan Wu
2023-03-02 19:05 ` Paul Moore
2023-03-02 19:05 ` Paul Moore
2023-03-02 19:05 ` [dm-devel] " Paul Moore
2023-04-10 21:22 ` Fan Wu
2023-04-10 21:22 ` Fan Wu
2023-04-10 21:22 ` [dm-devel] " Fan Wu
2023-01-30 22:57 ` [RFC PATCH v9 07/16] uapi|audit|ipe: add ipe auditing support Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-01-31 12:57 ` Roberto Sassu
2023-01-31 12:57 ` [dm-devel] " Roberto Sassu
2023-01-31 12:57 ` Roberto Sassu
2023-01-31 17:10 ` Steve Grubb
2023-01-31 17:10 ` [dm-devel] " Steve Grubb
2023-01-31 17:10 ` Steve Grubb
2023-03-02 19:05 ` [dm-devel] " Paul Moore
2023-03-02 19:05 ` Paul Moore
2023-03-02 19:05 ` Paul Moore
2023-03-16 22:53 ` Fan Wu
2023-03-16 22:53 ` Fan Wu
2023-03-16 22:53 ` [dm-devel] " Fan Wu
2023-04-11 23:07 ` Paul Moore
2023-04-11 23:07 ` Paul Moore
2023-04-11 23:07 ` [dm-devel] " Paul Moore
2023-04-11 23:21 ` Paul Moore
2023-04-11 23:21 ` Paul Moore
2023-04-11 23:21 ` [dm-devel] " Paul Moore
2023-01-30 22:57 ` [RFC PATCH v9 08/16] ipe: add permissive toggle Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-03-02 19:06 ` Paul Moore
2023-03-02 19:06 ` Paul Moore
2023-03-02 19:06 ` [dm-devel] " Paul Moore
2023-01-30 22:57 ` [RFC PATCH v9 09/16] block|security: add LSM blob to block_device Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-01-31 8:53 ` Christoph Hellwig
2023-01-31 8:53 ` Christoph Hellwig
2023-01-31 8:53 ` [dm-devel] " Christoph Hellwig
2023-01-31 23:01 ` Fan Wu
2023-01-31 23:01 ` Fan Wu
2023-01-31 23:01 ` [dm-devel] " Fan Wu
2023-03-02 19:07 ` Paul Moore
2023-03-02 19:07 ` Paul Moore
2023-03-02 19:07 ` [dm-devel] " Paul Moore
2023-01-30 22:57 ` [RFC PATCH v9 10/16] dm-verity: consume root hash digest and signature data via LSM hook Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-01-31 13:22 ` Roberto Sassu
2023-01-31 13:22 ` [dm-devel] " Roberto Sassu
2023-01-31 13:22 ` Roberto Sassu
2023-02-01 23:26 ` Fan Wu
2023-02-01 23:26 ` Fan Wu
2023-02-01 23:26 ` [dm-devel] " Fan Wu
2023-02-02 8:21 ` Roberto Sassu
2023-02-02 8:21 ` [dm-devel] " Roberto Sassu
2023-02-02 8:21 ` Roberto Sassu
2023-02-07 23:52 ` Fan Wu
2023-02-07 23:52 ` Fan Wu
2023-02-07 23:52 ` [dm-devel] " Fan Wu
2023-02-01 4:10 ` kernel test robot
2023-01-30 22:57 ` [RFC PATCH v9 11/16] ipe: add support for dm-verity as a trust provider Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-01-31 1:42 ` kernel test robot
2023-03-02 19:08 ` Paul Moore
2023-03-02 19:08 ` Paul Moore
2023-03-02 19:08 ` [dm-devel] " Paul Moore
2023-03-16 22:10 ` Fan Wu
2023-03-16 22:10 ` Fan Wu
2023-03-16 22:10 ` [dm-devel] " Fan Wu
2023-01-30 22:57 ` [RFC PATCH v9 12/16] fsverity: consume builtin signature via LSM hook Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-02-09 3:30 ` Eric Biggers
2023-02-09 3:30 ` Eric Biggers
2023-02-09 3:30 ` [dm-devel] " Eric Biggers
2023-02-09 22:21 ` Fan Wu
2023-02-09 22:21 ` Fan Wu
2023-02-09 22:21 ` [dm-devel] " Fan Wu
2023-01-30 22:57 ` [RFC PATCH v9 13/16] ipe: enable support for fs-verity as a trust provider Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-01-31 14:00 ` Roberto Sassu
2023-01-31 14:00 ` [dm-devel] " Roberto Sassu
2023-01-31 14:00 ` Roberto Sassu
2023-02-01 23:50 ` Fan Wu
2023-02-01 23:50 ` Fan Wu
2023-02-01 23:50 ` [dm-devel] " Fan Wu
2023-02-02 9:51 ` Roberto Sassu [this message]
2023-02-02 9:51 ` Roberto Sassu
2023-02-02 9:51 ` Roberto Sassu
2023-02-08 0:16 ` Fan Wu
2023-02-08 0:16 ` Fan Wu
2023-02-08 0:16 ` [dm-devel] " Fan Wu
2023-01-30 22:57 ` [RFC PATCH v9 14/16] scripts: add boot policy generation program Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-01-30 22:57 ` [RFC PATCH v9 15/16] ipe: kunit test for parser Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-01-30 22:57 ` [RFC PATCH v9 16/16] documentation: add ipe documentation Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] " Fan Wu
2023-01-31 3:59 ` Bagas Sanjaya
2023-01-31 3:59 ` Bagas Sanjaya
2023-01-31 3:59 ` [dm-devel] " Bagas Sanjaya
2023-02-02 0:19 ` Fan Wu
2023-02-02 0:19 ` Fan Wu
2023-02-02 0:19 ` [dm-devel] " Fan Wu
2023-01-31 14:22 ` [RFC PATCH v9 00/16] Integrity Policy Enforcement LSM (IPE) Roberto Sassu
2023-01-31 14:22 ` [dm-devel] " Roberto Sassu
2023-01-31 14:22 ` Roberto Sassu
2023-02-01 0:48 ` Fan Wu
2023-02-01 0:48 ` Fan Wu
2023-02-01 0:48 ` [dm-devel] " Fan Wu
2023-02-02 10:48 ` Roberto Sassu
2023-02-02 10:48 ` [dm-devel] " Roberto Sassu
2023-02-02 10:48 ` Roberto Sassu
2023-02-08 0:31 ` Fan Wu
2023-02-08 0:31 ` Fan Wu
2023-02-08 0:31 ` [dm-devel] " Fan Wu
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=6ddfa7344d01b21a93d3909af9dac0ae5e2a79ee.camel@huaweicloud.com \
--to=roberto.sassu@huaweicloud.com \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=corbet@lwn.net \
--cc=deven.desai@linux.microsoft.com \
--cc=dm-devel@redhat.com \
--cc=ebiggers@kernel.org \
--cc=eparis@redhat.com \
--cc=jmorris@namei.org \
--cc=linux-audit@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=snitzer@kernel.org \
--cc=tytso@mit.edu \
--cc=wufan@linux.microsoft.com \
--cc=zohar@linux.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.