From: Roberto Sassu <roberto.sassu@huawei.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "deven.desai@linux.microsoft.com"
<deven.desai@linux.microsoft.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"agk@redhat.com" <agk@redhat.com>,
"snitzer@redhat.com" <snitzer@redhat.com>,
"ebiggers@kernel.org" <ebiggers@kernel.org>,
"tytso@mit.edu" <tytso@mit.edu>,
"paul@paul-moore.com" <paul@paul-moore.com>,
"eparis@redhat.com" <eparis@redhat.com>,
"jmorris@namei.org" <jmorris@namei.org>,
"serge@hallyn.com" <serge@hallyn.com>,
"jannh@google.com" <jannh@google.com>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-fscrypt@vger.kernel.org" <linux-fscrypt@vger.kernel.org>,
"linux-audit@redhat.com" <linux-audit@redhat.com>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
"tusharsu@linux.microsoft.com" <tusharsu@linux.microsoft.com>
Subject: RE: [RFC][PATCH] device mapper: Add builtin function dm_get_status()
Date: Fri, 3 Dec 2021 10:20:27 +0000 [thread overview]
Message-ID: <28208b7f142f4295ac5c857af5cffe07@huawei.com> (raw)
In-Reply-To: <Yam+m9eiLxIamGXm@infradead.org>
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Friday, December 3, 2021 7:52 AM
> On Thu, Dec 02, 2021 at 09:29:52AM +0000, Roberto Sassu wrote:
> > The problem being solved is how to grant access to files
> > which satisfy a property defined in the policy.
>
> If you have want to enforce access to files in the block layer using
> a specific stacking block driver you don't just have one layering
> violation but a bunch of them. Please go back to the drawing board.
Ok. I write my thoughts here, so that it is easier to align.
dm-verity provides block-level integrity, which means that
the block layer itself is responsible to not pass data to the
upper layer, the filesystem, if a block is found corrupted.
The dm-verity root digest represents the immutable state
of the block device. dm-verity is still responsible to enforce
accesses to the block device according to the root digest
passed at device setup time. Nothing changes, the block
layer still detects data corruption against the passed
reference value.
The task of the security layer is to decide whether or not
the root digest passed at device setup time is acceptable,
e.g. it represents a device containing genuine files coming
from a software vendor.
The mandatory policy can be enforced at different layers,
depending on whether the security controls are placed.
A possibility would be to deny mounting block devices that
don't satisfy the mandatory policy.
However, if the mandatory policy wants only to restrict
execution of approved files and allowing the rest, making
the decision at the block layer is too coarse and restrictive.
It would force the user to mount only approved block
devices. The security layer must operate on files to enforce
this policy.
Now probably there is the part where there is no agreement.
The integrity property of a block device applies also to the
files on the filesystem mounted from that device. User space
programs cannot access files in that filesystem coming from a
device with a different dm-verity root digest, or files stored
in a corrupted block device.
If what I wrote is correct, that the integrity property is preserved
across the layers, this would give enough flexibility to enforce
policies at a higher layer, although that property is guaranteed
by a lower layer.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua
WARNING: multiple messages have this Message-ID (diff)
From: Roberto Sassu <roberto.sassu@huawei.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"tytso@mit.edu" <tytso@mit.edu>,
"paul@paul-moore.com" <paul@paul-moore.com>,
"snitzer@redhat.com" <snitzer@redhat.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"deven.desai@linux.microsoft.com"
<deven.desai@linux.microsoft.com>,
"jannh@google.com" <jannh@google.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"jmorris@namei.org" <jmorris@namei.org>,
"eparis@redhat.com" <eparis@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"ebiggers@kernel.org" <ebiggers@kernel.org>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
"linux-audit@redhat.com" <linux-audit@redhat.com>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"tusharsu@linux.microsoft.com" <tusharsu@linux.microsoft.com>,
"linux-fscrypt@vger.kernel.org" <linux-fscrypt@vger.kernel.org>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
"agk@redhat.com" <agk@redhat.com>,
"serge@hallyn.com" <serge@hallyn.com>
Subject: Re: [dm-devel] [RFC][PATCH] device mapper: Add builtin function dm_get_status()
Date: Fri, 3 Dec 2021 10:20:27 +0000 [thread overview]
Message-ID: <28208b7f142f4295ac5c857af5cffe07@huawei.com> (raw)
In-Reply-To: <Yam+m9eiLxIamGXm@infradead.org>
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Friday, December 3, 2021 7:52 AM
> On Thu, Dec 02, 2021 at 09:29:52AM +0000, Roberto Sassu wrote:
> > The problem being solved is how to grant access to files
> > which satisfy a property defined in the policy.
>
> If you have want to enforce access to files in the block layer using
> a specific stacking block driver you don't just have one layering
> violation but a bunch of them. Please go back to the drawing board.
Ok. I write my thoughts here, so that it is easier to align.
dm-verity provides block-level integrity, which means that
the block layer itself is responsible to not pass data to the
upper layer, the filesystem, if a block is found corrupted.
The dm-verity root digest represents the immutable state
of the block device. dm-verity is still responsible to enforce
accesses to the block device according to the root digest
passed at device setup time. Nothing changes, the block
layer still detects data corruption against the passed
reference value.
The task of the security layer is to decide whether or not
the root digest passed at device setup time is acceptable,
e.g. it represents a device containing genuine files coming
from a software vendor.
The mandatory policy can be enforced at different layers,
depending on whether the security controls are placed.
A possibility would be to deny mounting block devices that
don't satisfy the mandatory policy.
However, if the mandatory policy wants only to restrict
execution of approved files and allowing the rest, making
the decision at the block layer is too coarse and restrictive.
It would force the user to mount only approved block
devices. The security layer must operate on files to enforce
this policy.
Now probably there is the part where there is no agreement.
The integrity property of a block device applies also to the
files on the filesystem mounted from that device. User space
programs cannot access files in that filesystem coming from a
device with a different dm-verity root digest, or files stored
in a corrupted block device.
If what I wrote is correct, that the integrity property is preserved
across the layers, this would give enough flexibility to enforce
policies at a higher layer, although that property is guaranteed
by a lower layer.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua
--
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: Roberto Sassu <roberto.sassu@huawei.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"tytso@mit.edu" <tytso@mit.edu>,
"snitzer@redhat.com" <snitzer@redhat.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"deven.desai@linux.microsoft.com"
<deven.desai@linux.microsoft.com>,
"jannh@google.com" <jannh@google.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"jmorris@namei.org" <jmorris@namei.org>,
"eparis@redhat.com" <eparis@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"ebiggers@kernel.org" <ebiggers@kernel.org>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
"linux-audit@redhat.com" <linux-audit@redhat.com>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"tusharsu@linux.microsoft.com" <tusharsu@linux.microsoft.com>,
"linux-fscrypt@vger.kernel.org" <linux-fscrypt@vger.kernel.org>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
"agk@redhat.com" <agk@redhat.com>,
"serge@hallyn.com" <serge@hallyn.com>
Subject: RE: [RFC][PATCH] device mapper: Add builtin function dm_get_status()
Date: Fri, 3 Dec 2021 10:20:27 +0000 [thread overview]
Message-ID: <28208b7f142f4295ac5c857af5cffe07@huawei.com> (raw)
In-Reply-To: <Yam+m9eiLxIamGXm@infradead.org>
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Friday, December 3, 2021 7:52 AM
> On Thu, Dec 02, 2021 at 09:29:52AM +0000, Roberto Sassu wrote:
> > The problem being solved is how to grant access to files
> > which satisfy a property defined in the policy.
>
> If you have want to enforce access to files in the block layer using
> a specific stacking block driver you don't just have one layering
> violation but a bunch of them. Please go back to the drawing board.
Ok. I write my thoughts here, so that it is easier to align.
dm-verity provides block-level integrity, which means that
the block layer itself is responsible to not pass data to the
upper layer, the filesystem, if a block is found corrupted.
The dm-verity root digest represents the immutable state
of the block device. dm-verity is still responsible to enforce
accesses to the block device according to the root digest
passed at device setup time. Nothing changes, the block
layer still detects data corruption against the passed
reference value.
The task of the security layer is to decide whether or not
the root digest passed at device setup time is acceptable,
e.g. it represents a device containing genuine files coming
from a software vendor.
The mandatory policy can be enforced at different layers,
depending on whether the security controls are placed.
A possibility would be to deny mounting block devices that
don't satisfy the mandatory policy.
However, if the mandatory policy wants only to restrict
execution of approved files and allowing the rest, making
the decision at the block layer is too coarse and restrictive.
It would force the user to mount only approved block
devices. The security layer must operate on files to enforce
this policy.
Now probably there is the part where there is no agreement.
The integrity property of a block device applies also to the
files on the filesystem mounted from that device. User space
programs cannot access files in that filesystem coming from a
device with a different dm-verity root digest, or files stored
in a corrupted block device.
If what I wrote is correct, that the integrity property is preserved
across the layers, this would give enough flexibility to enforce
policies at a higher layer, although that property is guaranteed
by a lower layer.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2021-12-03 10:21 UTC|newest]
Thread overview: 193+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 19:06 [RFC PATCH v7 00/16] Integrity Policy Enforcement (IPE) deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 01/16] security: add ipe lsm & initial context creation deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-10-27 4:10 ` kernel test robot
2021-10-13 19:06 ` [RFC PATCH v7 02/16] ipe: add policy parser deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-10-27 5:58 ` kernel test robot
2021-10-13 19:06 ` [RFC PATCH v7 03/16] ipe: add evaluation loop deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-10-27 8:17 ` kernel test robot
2021-10-13 19:06 ` [RFC PATCH v7 04/16] ipe: add userspace interface deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-11-03 9:42 ` Roberto Sassu
2021-11-03 9:42 ` Roberto Sassu
2021-11-03 9:42 ` [dm-devel] " Roberto Sassu
2021-11-04 16:50 ` Deven Bowers
2021-11-04 16:50 ` Deven Bowers
2021-11-04 16:50 ` [dm-devel] " Deven Bowers
2021-10-13 19:06 ` [RFC PATCH v7 05/16] ipe: add LSM hooks on execution and kernel read deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-10-13 20:04 ` Casey Schaufler
2021-10-13 20:04 ` [dm-devel] " Casey Schaufler
2021-10-13 20:04 ` Casey Schaufler
2021-10-15 19:25 ` Deven Bowers
2021-10-15 19:25 ` Deven Bowers
2021-10-15 19:25 ` [dm-devel] " Deven Bowers
2021-10-25 12:22 ` Roberto Sassu
2021-10-25 12:22 ` Roberto Sassu
2021-10-25 12:22 ` [dm-devel] " Roberto Sassu
2021-10-26 19:03 ` Deven Bowers
2021-10-26 19:03 ` Deven Bowers
2021-10-26 19:03 ` [dm-devel] " Deven Bowers
2021-10-27 8:56 ` Roberto Sassu
2021-10-27 8:56 ` Roberto Sassu
2021-10-27 8:56 ` [dm-devel] " Roberto Sassu
2021-10-13 19:06 ` [RFC PATCH v7 06/16] uapi|audit: add trust audit message definitions deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 07/16] ipe: add auditing support deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-10-13 20:02 ` Steve Grubb
2021-10-13 20:02 ` [dm-devel] " Steve Grubb
2021-10-13 20:02 ` Steve Grubb
2021-10-15 19:25 ` Deven Bowers
2021-10-15 19:25 ` Deven Bowers
2021-10-15 19:25 ` [dm-devel] " Deven Bowers
2021-11-02 19:44 ` Steve Grubb
2021-11-02 19:44 ` [dm-devel] " Steve Grubb
2021-11-02 19:44 ` Steve Grubb
2021-11-04 16:59 ` Deven Bowers
2021-11-04 16:59 ` Deven Bowers
2021-11-04 16:59 ` [dm-devel] " Deven Bowers
2021-10-13 22:54 ` Randy Dunlap
2021-10-13 22:54 ` Randy Dunlap
2021-10-13 22:54 ` [dm-devel] " Randy Dunlap
2021-10-15 19:25 ` Deven Bowers
2021-10-15 19:25 ` Deven Bowers
2021-10-15 19:25 ` [dm-devel] " Deven Bowers
2021-10-15 19:50 ` Randy Dunlap
2021-10-15 19:50 ` Randy Dunlap
2021-10-15 19:50 ` [dm-devel] " Randy Dunlap
2021-10-26 19:03 ` Deven Bowers
2021-10-26 19:03 ` Deven Bowers
2021-10-26 19:03 ` [dm-devel] " Deven Bowers
2021-10-13 19:06 ` [RFC PATCH v7 08/16] ipe: add permissive toggle deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 09/16] ipe: introduce 'boot_verified' as a trust provider deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 10/16] fs|dm-verity: add block_dev LSM blob and submit dm-verity data deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 11/16] ipe: add support for dm-verity as a trust provider deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-11-25 9:37 ` Roberto Sassu
2021-11-25 9:37 ` Roberto Sassu
2021-11-25 9:37 ` [dm-devel] " Roberto Sassu
2021-11-30 18:55 ` Deven Bowers
2021-11-30 18:55 ` Deven Bowers
2021-11-30 18:55 ` [dm-devel] " Deven Bowers
2021-12-01 16:37 ` [RFC][PATCH] device mapper: Add builtin function dm_get_status() Roberto Sassu
2021-12-01 16:37 ` Roberto Sassu
2021-12-01 16:37 ` [dm-devel] " Roberto Sassu
2021-12-01 16:43 ` Roberto Sassu
2021-12-01 16:43 ` Roberto Sassu
2021-12-01 16:43 ` [dm-devel] " Roberto Sassu
2021-12-02 7:20 ` Christoph Hellwig
2021-12-02 7:20 ` Christoph Hellwig
2021-12-02 7:20 ` [dm-devel] " Christoph Hellwig
2021-12-02 7:59 ` Roberto Sassu
2021-12-02 7:59 ` Roberto Sassu
2021-12-02 7:59 ` [dm-devel] " Roberto Sassu
2021-12-02 8:44 ` Christoph Hellwig
2021-12-02 8:44 ` Christoph Hellwig
2021-12-02 8:44 ` [dm-devel] " Christoph Hellwig
2021-12-02 9:29 ` Roberto Sassu
2021-12-02 9:29 ` Roberto Sassu
2021-12-02 9:29 ` [dm-devel] " Roberto Sassu
2021-12-03 6:52 ` Christoph Hellwig
2021-12-03 6:52 ` Christoph Hellwig
2021-12-03 6:52 ` [dm-devel] " Christoph Hellwig
2021-12-03 10:20 ` Roberto Sassu [this message]
2021-12-03 10:20 ` Roberto Sassu
2021-12-03 10:20 ` [dm-devel] " Roberto Sassu
2021-12-06 10:57 ` Roberto Sassu
2021-12-06 10:57 ` Roberto Sassu
2021-12-06 10:57 ` [dm-devel] " Roberto Sassu
2021-10-13 19:06 ` [RFC PATCH v7 12/16] fsverity|security: add security hooks to fsverity digest and signature deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-10-13 19:24 ` Eric Biggers
2021-10-13 19:24 ` Eric Biggers
2021-10-13 19:24 ` [dm-devel] " Eric Biggers
2021-10-15 19:25 ` Deven Bowers
2021-10-15 19:25 ` Deven Bowers
2021-10-15 19:25 ` [dm-devel] " Deven Bowers
2021-10-15 20:11 ` Eric Biggers
2021-10-15 20:11 ` Eric Biggers
2021-10-15 20:11 ` [dm-devel] " Eric Biggers
2021-10-20 15:08 ` Roberto Sassu
2021-10-20 15:08 ` [dm-devel] " Roberto Sassu
2021-10-20 15:08 ` Roberto Sassu
2021-10-22 16:31 ` Roberto Sassu
2021-10-22 16:31 ` Roberto Sassu
2021-10-22 16:31 ` [dm-devel] " Roberto Sassu
2021-10-26 19:03 ` Deven Bowers
2021-10-26 19:03 ` Deven Bowers
2021-10-26 19:03 ` [dm-devel] " Deven Bowers
2021-10-27 8:41 ` Roberto Sassu
2021-10-27 8:41 ` Roberto Sassu
2021-10-27 8:41 ` [dm-devel] " Roberto Sassu
2021-10-26 19:03 ` Deven Bowers
2021-10-26 19:03 ` Deven Bowers
2021-10-26 19:03 ` [dm-devel] " Deven Bowers
2021-10-27 9:34 ` Roberto Sassu
2021-10-27 9:34 ` Roberto Sassu
2021-10-27 9:34 ` [dm-devel] " Roberto Sassu
2021-10-28 3:48 ` Eric Biggers
2021-10-28 3:48 ` Eric Biggers
2021-10-28 3:48 ` [dm-devel] " Eric Biggers
2021-10-28 18:11 ` Deven Bowers
2021-10-28 18:11 ` Deven Bowers
2021-10-28 18:11 ` [dm-devel] " Deven Bowers
2021-11-03 12:28 ` Roberto Sassu
2021-11-03 12:28 ` Roberto Sassu
2021-11-03 12:28 ` [dm-devel] " Roberto Sassu
2021-11-04 17:12 ` Deven Bowers
2021-11-04 17:12 ` [dm-devel] " Deven Bowers
2021-11-04 17:12 ` Deven Bowers
2021-10-13 19:06 ` [RFC PATCH v7 13/16] ipe: enable support for fs-verity as a trust provider deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-10-27 11:55 ` kernel test robot
2021-10-13 19:06 ` [RFC PATCH v7 14/16] scripts: add boot policy generation program deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-11-03 16:43 ` Roberto Sassu
2021-11-03 16:43 ` Roberto Sassu
2021-11-03 16:43 ` [dm-devel] " Roberto Sassu
2021-11-03 16:53 ` Roberto Sassu
2021-11-03 16:53 ` Roberto Sassu
2021-11-03 16:53 ` [dm-devel] " Roberto Sassu
2021-11-04 16:52 ` Deven Bowers
2021-11-04 16:52 ` Deven Bowers
2021-11-04 16:52 ` [dm-devel] " Deven Bowers
2021-10-13 19:06 ` [RFC PATCH v7 15/16] ipe: kunit tests deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 16/16] documentation: add ipe documentation deven.desai
2021-10-13 19:06 ` deven.desai
2021-10-13 19:06 ` [dm-devel] " deven.desai
2021-10-25 11:30 ` [RFC PATCH v7 00/16] Integrity Policy Enforcement (IPE) Roberto Sassu
2021-10-25 11:30 ` Roberto Sassu
2021-10-25 11:30 ` [dm-devel] " Roberto Sassu
2021-10-26 19:03 ` Deven Bowers
2021-10-26 19:03 ` Deven Bowers
2021-10-26 19:03 ` [dm-devel] " Deven Bowers
2021-10-27 8:26 ` Roberto Sassu
2021-10-27 8:26 ` Roberto Sassu
2021-10-27 8:26 ` [dm-devel] " Roberto Sassu
2021-10-28 20:36 ` Deven Bowers
2021-10-28 20:36 ` Deven Bowers
2021-10-28 20:36 ` [dm-devel] " Deven Bowers
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=28208b7f142f4295ac5c857af5cffe07@huawei.com \
--to=roberto.sassu@huawei.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=hch@infradead.org \
--cc=jannh@google.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=serge@hallyn.com \
--cc=snitzer@redhat.com \
--cc=tusharsu@linux.microsoft.com \
--cc=tytso@mit.edu \
/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.