All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Fan Wu <wufan@linux.microsoft.com>
Cc: axboe@kernel.dk, 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,
	linux-block@vger.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 12/16] fsverity: consume builtin signature via LSM hook
Date: Wed, 8 Feb 2023 19:30:33 -0800	[thread overview]
Message-ID: <Y+Ro2Uor21d/Gfqc@sol.localdomain> (raw)
In-Reply-To: <1675119451-23180-13-git-send-email-wufan@linux.microsoft.com>

So disregarding the fact that using the fsverity builtin signatures still seems
like a bad idea to me, here's a few comments on the diff itself:

On Mon, Jan 30, 2023 at 02:57:27PM -0800, Fan Wu wrote:
> diff --git a/fs/verity/open.c b/fs/verity/open.c
> index 81ff94442f7b..7e6fa52c0e9c 100644
> --- a/fs/verity/open.c
> +++ b/fs/verity/open.c
> @@ -7,7 +7,9 @@
>  
>  #include "fsverity_private.h"
>  
> +#include <linux/security.h>
>  #include <linux/slab.h>
> +#include <crypto/public_key.h>

There's no need to include <crypto/public_key.h>.

>  
>  static struct kmem_cache *fsverity_info_cachep;
>  
> @@ -146,7 +148,7 @@ static int compute_file_digest(struct fsverity_hash_alg *hash_alg,
>   * appended signature), and check the signature if present.  The
>   * fsverity_descriptor must have already undergone basic validation.
>   */
> -struct fsverity_info *fsverity_create_info(const struct inode *inode,
> +struct fsverity_info *fsverity_create_info(struct inode *inode,
>  					   struct fsverity_descriptor *desc)
>  {
>  	struct fsverity_info *vi;
> @@ -182,6 +184,15 @@ struct fsverity_info *fsverity_create_info(const struct inode *inode,
>  
>  	err = fsverity_verify_signature(vi, desc->signature,
>  					le32_to_cpu(desc->sig_size));
> +	if (err) {
> +		fsverity_err(inode, "Error %d verifying signature", err);
> +		goto out;
> +	}

The above error message is unnecessary because fsverity_verify_signature()
already prints an error message on failure.

> +
> +	err = security_inode_setsecurity(inode, FS_VERITY_INODE_SEC_NAME, desc->signature,
> +					 le32_to_cpu(desc->sig_size), 0);

This runs even if CONFIG_FS_VERITY_BUILTIN_SIGNATURES is disabled.  Is that
really the right behavior?

Also a nit: please stick to the preferred line length of 80 characters.
See Documentation/process/coding-style.rst

> diff --git a/fs/verity/signature.c b/fs/verity/signature.c
> index 143a530a8008..5d7b9496f9c4 100644
> --- a/fs/verity/signature.c
> +++ b/fs/verity/signature.c
> @@ -9,6 +9,7 @@
>  
>  #include <linux/cred.h>
>  #include <linux/key.h>
> +#include <linux/security.h>
>  #include <linux/slab.h>
>  #include <linux/verification.h>

This change is unnecessary.

> diff --git a/include/linux/fsverity.h b/include/linux/fsverity.h
> index 40f14e5fed9d..29e9888287ba 100644
> --- a/include/linux/fsverity.h
> +++ b/include/linux/fsverity.h
> @@ -254,4 +254,6 @@ static inline bool fsverity_active(const struct inode *inode)
>  	return fsverity_get_info(inode) != NULL;
>  }
>  
> +#define FS_VERITY_INODE_SEC_NAME "fsverity.inode-info"

"inode-info" is very vague.  Shouldn't it be named "builtin-sig" or something?

- Eric

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Fan Wu <wufan@linux.microsoft.com>
Cc: axboe@kernel.dk, 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,
	linux-block@vger.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 12/16] fsverity: consume builtin signature via LSM hook
Date: Wed, 8 Feb 2023 19:30:33 -0800	[thread overview]
Message-ID: <Y+Ro2Uor21d/Gfqc@sol.localdomain> (raw)
In-Reply-To: <1675119451-23180-13-git-send-email-wufan@linux.microsoft.com>

So disregarding the fact that using the fsverity builtin signatures still seems
like a bad idea to me, here's a few comments on the diff itself:

On Mon, Jan 30, 2023 at 02:57:27PM -0800, Fan Wu wrote:
> diff --git a/fs/verity/open.c b/fs/verity/open.c
> index 81ff94442f7b..7e6fa52c0e9c 100644
> --- a/fs/verity/open.c
> +++ b/fs/verity/open.c
> @@ -7,7 +7,9 @@
>  
>  #include "fsverity_private.h"
>  
> +#include <linux/security.h>
>  #include <linux/slab.h>
> +#include <crypto/public_key.h>

There's no need to include <crypto/public_key.h>.

>  
>  static struct kmem_cache *fsverity_info_cachep;
>  
> @@ -146,7 +148,7 @@ static int compute_file_digest(struct fsverity_hash_alg *hash_alg,
>   * appended signature), and check the signature if present.  The
>   * fsverity_descriptor must have already undergone basic validation.
>   */
> -struct fsverity_info *fsverity_create_info(const struct inode *inode,
> +struct fsverity_info *fsverity_create_info(struct inode *inode,
>  					   struct fsverity_descriptor *desc)
>  {
>  	struct fsverity_info *vi;
> @@ -182,6 +184,15 @@ struct fsverity_info *fsverity_create_info(const struct inode *inode,
>  
>  	err = fsverity_verify_signature(vi, desc->signature,
>  					le32_to_cpu(desc->sig_size));
> +	if (err) {
> +		fsverity_err(inode, "Error %d verifying signature", err);
> +		goto out;
> +	}

The above error message is unnecessary because fsverity_verify_signature()
already prints an error message on failure.

> +
> +	err = security_inode_setsecurity(inode, FS_VERITY_INODE_SEC_NAME, desc->signature,
> +					 le32_to_cpu(desc->sig_size), 0);

This runs even if CONFIG_FS_VERITY_BUILTIN_SIGNATURES is disabled.  Is that
really the right behavior?

Also a nit: please stick to the preferred line length of 80 characters.
See Documentation/process/coding-style.rst

> diff --git a/fs/verity/signature.c b/fs/verity/signature.c
> index 143a530a8008..5d7b9496f9c4 100644
> --- a/fs/verity/signature.c
> +++ b/fs/verity/signature.c
> @@ -9,6 +9,7 @@
>  
>  #include <linux/cred.h>
>  #include <linux/key.h>
> +#include <linux/security.h>
>  #include <linux/slab.h>
>  #include <linux/verification.h>

This change is unnecessary.

> diff --git a/include/linux/fsverity.h b/include/linux/fsverity.h
> index 40f14e5fed9d..29e9888287ba 100644
> --- a/include/linux/fsverity.h
> +++ b/include/linux/fsverity.h
> @@ -254,4 +254,6 @@ static inline bool fsverity_active(const struct inode *inode)
>  	return fsverity_get_info(inode) != NULL;
>  }
>  
> +#define FS_VERITY_INODE_SEC_NAME "fsverity.inode-info"

"inode-info" is very vague.  Shouldn't it be named "builtin-sig" or something?

- Eric

--
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: Eric Biggers <ebiggers@kernel.org>
To: Fan Wu <wufan@linux.microsoft.com>
Cc: corbet@lwn.net, zohar@linux.ibm.com, jmorris@namei.org,
	serge@hallyn.com, tytso@mit.edu, 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 12/16] fsverity: consume builtin signature via LSM hook
Date: Wed, 8 Feb 2023 19:30:33 -0800	[thread overview]
Message-ID: <Y+Ro2Uor21d/Gfqc@sol.localdomain> (raw)
In-Reply-To: <1675119451-23180-13-git-send-email-wufan@linux.microsoft.com>

So disregarding the fact that using the fsverity builtin signatures still seems
like a bad idea to me, here's a few comments on the diff itself:

On Mon, Jan 30, 2023 at 02:57:27PM -0800, Fan Wu wrote:
> diff --git a/fs/verity/open.c b/fs/verity/open.c
> index 81ff94442f7b..7e6fa52c0e9c 100644
> --- a/fs/verity/open.c
> +++ b/fs/verity/open.c
> @@ -7,7 +7,9 @@
>  
>  #include "fsverity_private.h"
>  
> +#include <linux/security.h>
>  #include <linux/slab.h>
> +#include <crypto/public_key.h>

There's no need to include <crypto/public_key.h>.

>  
>  static struct kmem_cache *fsverity_info_cachep;
>  
> @@ -146,7 +148,7 @@ static int compute_file_digest(struct fsverity_hash_alg *hash_alg,
>   * appended signature), and check the signature if present.  The
>   * fsverity_descriptor must have already undergone basic validation.
>   */
> -struct fsverity_info *fsverity_create_info(const struct inode *inode,
> +struct fsverity_info *fsverity_create_info(struct inode *inode,
>  					   struct fsverity_descriptor *desc)
>  {
>  	struct fsverity_info *vi;
> @@ -182,6 +184,15 @@ struct fsverity_info *fsverity_create_info(const struct inode *inode,
>  
>  	err = fsverity_verify_signature(vi, desc->signature,
>  					le32_to_cpu(desc->sig_size));
> +	if (err) {
> +		fsverity_err(inode, "Error %d verifying signature", err);
> +		goto out;
> +	}

The above error message is unnecessary because fsverity_verify_signature()
already prints an error message on failure.

> +
> +	err = security_inode_setsecurity(inode, FS_VERITY_INODE_SEC_NAME, desc->signature,
> +					 le32_to_cpu(desc->sig_size), 0);

This runs even if CONFIG_FS_VERITY_BUILTIN_SIGNATURES is disabled.  Is that
really the right behavior?

Also a nit: please stick to the preferred line length of 80 characters.
See Documentation/process/coding-style.rst

> diff --git a/fs/verity/signature.c b/fs/verity/signature.c
> index 143a530a8008..5d7b9496f9c4 100644
> --- a/fs/verity/signature.c
> +++ b/fs/verity/signature.c
> @@ -9,6 +9,7 @@
>  
>  #include <linux/cred.h>
>  #include <linux/key.h>
> +#include <linux/security.h>
>  #include <linux/slab.h>
>  #include <linux/verification.h>

This change is unnecessary.

> diff --git a/include/linux/fsverity.h b/include/linux/fsverity.h
> index 40f14e5fed9d..29e9888287ba 100644
> --- a/include/linux/fsverity.h
> +++ b/include/linux/fsverity.h
> @@ -254,4 +254,6 @@ static inline bool fsverity_active(const struct inode *inode)
>  	return fsverity_get_info(inode) != NULL;
>  }
>  
> +#define FS_VERITY_INODE_SEC_NAME "fsverity.inode-info"

"inode-info" is very vague.  Shouldn't it be named "builtin-sig" or something?

- Eric

  reply	other threads:[~2023-02-09  3:38 UTC|newest]

Thread overview: 225+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-30 22:57 [dm-devel] [RFC PATCH v9 00/16] Integrity Policy Enforcement LSM (IPE) Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` Fan Wu
2023-01-30 22:57 ` [dm-devel] [RFC PATCH v9 01/16] security: add ipe lsm Fan Wu
2023-01-30 22:57   ` Fan Wu
2023-01-30 22:57   ` Fan Wu
2023-03-02 19:00   ` [dm-devel] " Paul Moore
2023-03-02 19:00     ` Paul Moore
2023-03-02 19:00     ` Paul Moore
2023-04-06 19:20     ` [dm-devel] " Fan Wu
2023-04-06 19:20       ` Fan Wu
2023-04-06 19:20       ` Fan Wu
2023-01-30 22:57 ` [dm-devel] [RFC PATCH v9 02/16] ipe: add policy parser Fan Wu
2023-01-30 22:57   ` Fan Wu
2023-01-30 22:57   ` Fan Wu
2023-01-31 10:53   ` [dm-devel] " Roberto Sassu
2023-01-31 10:53     ` Roberto Sassu
2023-01-31 10:53     ` Roberto Sassu
2023-02-01 22:38     ` [dm-devel] " Fan Wu
2023-02-01 22:38       ` Fan Wu
2023-02-01 22:38       ` Fan Wu
2023-03-02 19:02   ` [dm-devel] " Paul Moore
2023-03-02 19:02     ` Paul Moore
2023-03-02 19:02     ` Paul Moore
2023-04-06 20:00     ` [dm-devel] " Fan Wu
2023-04-06 20:00       ` Fan Wu
2023-04-06 20:00       ` Fan Wu
2023-04-11 19:13       ` [dm-devel] " Paul Moore
2023-04-11 19:13         ` Paul Moore
2023-04-11 19:13         ` Paul Moore
2023-01-30 22:57 ` [dm-devel] [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   ` Fan Wu
2023-01-31 10:29   ` [dm-devel] " Roberto Sassu
2023-01-31 10:29     ` Roberto Sassu
2023-01-31 10:29     ` Roberto Sassu
2023-01-31 15:49   ` [dm-devel] " Roberto Sassu
2023-01-31 15:49     ` Roberto Sassu
2023-01-31 15:49     ` Roberto Sassu
2023-02-10 23:21     ` [dm-devel] " Fan Wu
2023-02-10 23:21       ` Fan Wu
2023-02-10 23:21       ` Fan Wu
2023-03-02  2:33       ` [dm-devel] " Paul Moore
2023-03-02  2:33         ` Paul Moore
2023-03-02  2:33         ` Paul Moore
2023-03-02 19:03   ` [dm-devel] " Paul Moore
2023-03-02 19:03     ` Paul Moore
2023-03-02 19:03     ` Paul Moore
2023-04-10 18:53     ` [dm-devel] " Fan Wu
2023-04-10 18:53       ` Fan Wu
2023-04-10 18:53       ` Fan Wu
2023-04-11 20:32       ` [dm-devel] " Paul Moore
2023-04-11 20:32         ` Paul Moore
2023-04-11 20:32         ` Paul Moore
2023-01-30 22:57 ` [dm-devel] [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   ` Fan Wu
2023-01-30 22:57 ` [dm-devel] [RFC PATCH v9 05/16] ipe: add userspace interface Fan Wu
2023-01-30 22:57   ` Fan Wu
2023-01-30 22:57   ` Fan Wu
2023-01-31 10:49   ` [dm-devel] " Roberto Sassu
2023-01-31 10:49     ` Roberto Sassu
2023-01-31 10:49     ` Roberto Sassu
2023-02-01 19:46     ` [dm-devel] " Fan Wu
2023-02-01 19:46       ` Fan Wu
2023-02-01 19:46       ` Fan Wu
2023-02-05  8:42   ` kernel test robot
2023-03-02 19:04   ` [dm-devel] " Paul Moore
2023-03-02 19:04     ` Paul Moore
2023-03-02 19:04     ` Paul Moore
2023-04-10 19:10     ` [dm-devel] " Fan Wu
2023-04-10 19:10       ` Fan Wu
2023-04-10 19:10       ` Fan Wu
2023-04-11 21:45       ` [dm-devel] " Paul Moore
2023-04-11 21:45         ` Paul Moore
2023-04-11 21:45         ` Paul Moore
2023-04-12 23:36         ` [dm-devel] " Fan Wu
2023-04-12 23:36           ` Fan Wu
2023-04-12 23:36           ` Fan Wu
2023-04-13 18:45           ` [dm-devel] " Paul Moore
2023-04-13 18:45             ` Paul Moore
2023-04-13 18:45             ` Paul Moore
2023-04-17 18:06             ` [dm-devel] " Fan Wu
2023-04-17 18:06               ` Fan Wu
2023-04-17 18:06               ` Fan Wu
2023-04-17 20:16               ` [dm-devel] " Paul Moore
2023-04-17 20:16                 ` Paul Moore
2023-04-17 20:16                 ` Paul Moore
2023-04-17 21:18                 ` [dm-devel] " Fan Wu
2023-04-17 21:18                   ` Fan Wu
2023-04-17 21:18                   ` Fan Wu
2023-04-17 21:31                   ` [dm-devel] " Paul Moore
2023-04-17 21:31                     ` Paul Moore
2023-04-17 21:31                     ` Paul Moore
2023-01-30 22:57 ` [dm-devel] [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   ` Fan Wu
2023-01-31 12:51   ` [dm-devel] " Roberto Sassu
2023-01-31 12:51     ` Roberto Sassu
2023-01-31 12:51     ` Roberto Sassu
2023-02-09 22:42     ` [dm-devel] " Fan Wu
2023-02-09 22:42       ` Fan Wu
2023-02-09 22:42       ` Fan Wu
2023-03-02 19:05   ` [dm-devel] " Paul Moore
2023-03-02 19:05     ` Paul Moore
2023-03-02 19:05     ` Paul Moore
2023-04-10 21:22     ` [dm-devel] " Fan Wu
2023-04-10 21:22       ` Fan Wu
2023-04-10 21:22       ` Fan Wu
2023-01-30 22:57 ` [dm-devel] [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   ` Fan Wu
2023-01-31 12:57   ` [dm-devel] " Roberto Sassu
2023-01-31 12:57     ` Roberto Sassu
2023-01-31 12:57     ` Roberto Sassu
2023-01-31 17:10   ` [dm-devel] " Steve Grubb
2023-01-31 17:10     ` 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       ` [dm-devel] " Fan Wu
2023-03-16 22:53         ` Fan Wu
2023-03-16 22:53         ` Fan Wu
2023-04-11 23:07         ` [dm-devel] " Paul Moore
2023-04-11 23:07           ` Paul Moore
2023-04-11 23:07           ` Paul Moore
2023-04-11 23:21       ` [dm-devel] " Paul Moore
2023-04-11 23:21         ` Paul Moore
2023-04-11 23:21         ` Paul Moore
2023-01-30 22:57 ` [dm-devel] [RFC PATCH v9 08/16] ipe: add permissive toggle Fan Wu
2023-01-30 22:57   ` Fan Wu
2023-01-30 22:57   ` Fan Wu
2023-03-02 19:06   ` [dm-devel] " Paul Moore
2023-03-02 19:06     ` Paul Moore
2023-03-02 19:06     ` Paul Moore
2023-01-30 22:57 ` [dm-devel] [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   ` Fan Wu
2023-01-31  8:53   ` [dm-devel] " Christoph Hellwig
2023-01-31  8:53     ` Christoph Hellwig
2023-01-31  8:53     ` Christoph Hellwig
2023-01-31 23:01     ` [dm-devel] " Fan Wu
2023-01-31 23:01       ` Fan Wu
2023-01-31 23:01       ` Fan Wu
2023-03-02 19:07   ` [dm-devel] " Paul Moore
2023-03-02 19:07     ` Paul Moore
2023-03-02 19:07     ` Paul Moore
2023-01-30 22:57 ` [dm-devel] [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   ` Fan Wu
2023-01-31 13:22   ` [dm-devel] " Roberto Sassu
2023-01-31 13:22     ` Roberto Sassu
2023-01-31 13:22     ` Roberto Sassu
2023-02-01 23:26     ` [dm-devel] " Fan Wu
2023-02-01 23:26       ` Fan Wu
2023-02-01 23:26       ` Fan Wu
2023-02-02  8:21       ` [dm-devel] " Roberto Sassu
2023-02-02  8:21         ` Roberto Sassu
2023-02-02  8:21         ` Roberto Sassu
2023-02-07 23:52         ` [dm-devel] " Fan Wu
2023-02-07 23:52           ` Fan Wu
2023-02-07 23:52           ` Fan Wu
2023-02-01  4:10   ` kernel test robot
2023-01-30 22:57 ` [dm-devel] [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   ` Fan Wu
2023-01-31  1:42   ` kernel test robot
2023-03-02 19:08   ` [dm-devel] " Paul Moore
2023-03-02 19:08     ` Paul Moore
2023-03-02 19:08     ` Paul Moore
2023-03-16 22:10     ` [dm-devel] " Fan Wu
2023-03-16 22:10       ` Fan Wu
2023-03-16 22:10       ` Fan Wu
2023-01-30 22:57 ` [dm-devel] [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   ` Fan Wu
2023-02-09  3:30   ` Eric Biggers [this message]
2023-02-09  3:30     ` Eric Biggers
2023-02-09  3:30     ` Eric Biggers
2023-02-09 22:21     ` [dm-devel] " Fan Wu
2023-02-09 22:21       ` Fan Wu
2023-02-09 22:21       ` Fan Wu
2023-01-30 22:57 ` [dm-devel] [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   ` Fan Wu
2023-01-31 14:00   ` [dm-devel] " Roberto Sassu
2023-01-31 14:00     ` Roberto Sassu
2023-01-31 14:00     ` Roberto Sassu
2023-02-01 23:50     ` [dm-devel] " Fan Wu
2023-02-01 23:50       ` Fan Wu
2023-02-01 23:50       ` Fan Wu
2023-02-02  9:51       ` [dm-devel] " Roberto Sassu
2023-02-02  9:51         ` Roberto Sassu
2023-02-02  9:51         ` Roberto Sassu
2023-02-08  0:16         ` [dm-devel] " Fan Wu
2023-02-08  0:16           ` Fan Wu
2023-02-08  0:16           ` Fan Wu
2023-01-30 22:57 ` [dm-devel] [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   ` Fan Wu
2023-01-30 22:57 ` [dm-devel] [RFC PATCH v9 15/16] ipe: kunit test for parser Fan Wu
2023-01-30 22:57   ` Fan Wu
2023-01-30 22:57   ` Fan Wu
2023-01-30 22:57 ` [dm-devel] [RFC PATCH v9 16/16] documentation: add ipe documentation Fan Wu
2023-01-30 22:57   ` Fan Wu
2023-01-30 22:57   ` Fan Wu
2023-01-31  3:59   ` [dm-devel] " Bagas Sanjaya
2023-01-31  3:59     ` Bagas Sanjaya
2023-01-31  3:59     ` Bagas Sanjaya
2023-02-02  0:19     ` [dm-devel] " Fan Wu
2023-02-02  0:19       ` Fan Wu
2023-02-02  0:19       ` Fan Wu
2023-01-31 14:22 ` [dm-devel] [RFC PATCH v9 00/16] Integrity Policy Enforcement LSM (IPE) Roberto Sassu
2023-01-31 14:22   ` Roberto Sassu
2023-01-31 14:22   ` Roberto Sassu
2023-02-01  0:48   ` [dm-devel] " Fan Wu
2023-02-01  0:48     ` Fan Wu
2023-02-01  0:48     ` Fan Wu
2023-02-02 10:48     ` [dm-devel] " Roberto Sassu
2023-02-02 10:48       ` Roberto Sassu
2023-02-02 10:48       ` Roberto Sassu
2023-02-08  0:31       ` [dm-devel] " Fan Wu
2023-02-08  0:31         ` Fan Wu
2023-02-08  0:31         ` 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=Y+Ro2Uor21d/Gfqc@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=agk@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=corbet@lwn.net \
    --cc=deven.desai@linux.microsoft.com \
    --cc=dm-devel@redhat.com \
    --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.