From: Samir Bellabes <sam@synack.fr>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: ebiederm@xmission.com (Eric W. Biederman),
"Serge E. Hallyn" <serue@us.ibm.com>,
"Andrew G. Morgan" <morgan@kernel.org>,
"Bryan Donlan" <bdonlan@gmail.com>,
"Benny Amorsen" <benny+usenet@amorsen.dk>,
"Michael Stone" <michael@laptop.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-security-module@vger.kernel.org,
"Andi Kleen" <andi@firstfloor.org>, "David Lang" <david@lang.hm>,
"Oliver Hartkopp" <socketcan@hartkopp.net>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>,
"Evgeniy Polyakov" <zbr@ioremap.net>,
"C. Scott Ananian" <cscott@cscott.net>,
"James Morris" <jmorris@namei.org>,
"Bernie Innocenti" <bernie@codewiz.org>,
"Mark Seaborn" <mrs@mythic-beasts.com>,
"Randy Dunlap" <randy.dunlap@oracle.com>,
"Américo Wang" <xiyou.wangcong@gmail.com>,
"Tetsuo Handa" <penguin-kernel@i-love.sakura.ne.jp>,
"Casey Schaufler" <casey@schaufler-ca.com>,
"Pavel Machek" <pavel@ucw.cz>,
"Al Viro" <viro@zeniv.linux.org.uk>
Subject: Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges
Date: Thu, 31 Dec 2009 14:00:13 +0100 [thread overview]
Message-ID: <m2bphfti1u.fsf@ssh.synack.fr> (raw)
In-Reply-To: <20091230230042.5d2e78ac@lxorguk.ukuu.org.uk> (Alan Cox's message of "Wed, 30 Dec 2009 23:00:42 +0000")
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> Well to be fair its random regurgitated security idea of every year or
> two.
true, last year the same kind of discussion occurs with the 'personal
firewall' aka a network MAC.
http://marc.info/?t=123247387500003&r=3&w=2
http://marc.info/?t=123187029200001&r=2&w=2
> More to the point - we have security_* hooks so this kind of continuous
> security proposal turdstream can stay out of the main part of the kernel.
indeed, LSM framework was design to be the abstraction tool. the 3
design rules were :
0. truly generic, where using a different security model is merely a
matter of loading a different kernel module;
1. conceptually simple, minimally invasive, and efficient; and
2. able to support the existing POSIX.1e capabilities logic as an
optional security module.
so, 'minimally invasive' is keyword. what's why I don't understand the
purpose of this kind of patch, even if I see the goal to achieve:
int security_socket_connect(struct socket *sock, struct sockaddr *address, int addrlen)
{
- return security_ops->socket_connect(sock, address, addrlen);
+ int ret = 0;
+
+ ret = security_ops->socket_connect(sock, address, addrlen);
+ if (ret)
+ goto out;
+
+#ifdef CONFIG_SECURITY_DISABLENETWORK
+ ret = disablenetwork_security_socket_connect(sock, address, addrlen);
+ if (ret)
+ goto out;
+#endif
+
+out:
+ return ret;
}
This really seems to be a kind of stacking, but it's not. So are we
going to move LSM framework to support stacking, or are we respecting
the rules of LSM framework (respecting the abstract hooks) ?
This change makes LSM framework no more generic at all.
WARNING: multiple messages have this Message-ID (diff)
From: Samir Bellabes <sam@synack.fr>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: ebiederm@xmission.com (Eric W. Biederman),
"Serge E. Hallyn" <serue@us.ibm.com>,
"Andrew G. Morgan" <morgan@kernel.org>,
"Bryan Donlan" <bdonlan@gmail.com>,
"Benny Amorsen" <benny+usenet@amorsen.dk>,
"Michael Stone" <michael@laptop.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-security-module@vger.kernel.org,
"Andi Kleen" <andi@firstfloor.org>, "David Lang" <david@lang.hm>,
"Oliver Hartkopp" <socketcan@hartkopp.net>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>,
"Evgeniy Polyakov" <zbr@ioremap.net>,
"C. Scott Ananian" <cscott@cscott.net>,
"James Morris" <jmorris@namei.org>,
"Bernie Innocenti" <bernie@codewiz.org>,
"Mark Seaborn" <mrs@mythic-beasts.com>,
"Randy Dunlap" <randy.dunlap@oracle.com>,
"Américo Wang" <xiyou.wangcong@gmail.com>,
"Tetsuo Handa" <penguin-kernel@i-love.sakura.ne.jp>
Subject: Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges
Date: Thu, 31 Dec 2009 14:00:13 +0100 [thread overview]
Message-ID: <m2bphfti1u.fsf@ssh.synack.fr> (raw)
In-Reply-To: <20091230230042.5d2e78ac@lxorguk.ukuu.org.uk> (Alan Cox's message of "Wed, 30 Dec 2009 23:00:42 +0000")
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> Well to be fair its random regurgitated security idea of every year or
> two.
true, last year the same kind of discussion occurs with the 'personal
firewall' aka a network MAC.
http://marc.info/?t=123247387500003&r=3&w=2
http://marc.info/?t=123187029200001&r=2&w=2
> More to the point - we have security_* hooks so this kind of continuous
> security proposal turdstream can stay out of the main part of the kernel.
indeed, LSM framework was design to be the abstraction tool. the 3
design rules were :
0. truly generic, where using a different security model is merely a
matter of loading a different kernel module;
1. conceptually simple, minimally invasive, and efficient; and
2. able to support the existing POSIX.1e capabilities logic as an
optional security module.
so, 'minimally invasive' is keyword. what's why I don't understand the
purpose of this kind of patch, even if I see the goal to achieve:
int security_socket_connect(struct socket *sock, struct sockaddr *address, int addrlen)
{
- return security_ops->socket_connect(sock, address, addrlen);
+ int ret = 0;
+
+ ret = security_ops->socket_connect(sock, address, addrlen);
+ if (ret)
+ goto out;
+
+#ifdef CONFIG_SECURITY_DISABLENETWORK
+ ret = disablenetwork_security_socket_connect(sock, address, addrlen);
+ if (ret)
+ goto out;
+#endif
+
+out:
+ return ret;
}
This really seems to be a kind of stacking, but it's not. So are we
going to move LSM framework to support stacking, or are we respecting
the rules of LSM framework (respecting the abstract hooks) ?
This change makes LSM framework no more generic at all.
next prev parent reply other threads:[~2009-12-31 13:00 UTC|newest]
Thread overview: 278+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-27 1:04 RFC: disablenetwork facility. (v4) Michael Stone
2009-12-27 1:04 ` Michael Stone
2009-12-27 1:06 ` [PATCH 1/3] Security: Add disablenetwork interface. (v4) Michael Stone
2009-12-27 1:06 ` Michael Stone
2009-12-27 3:26 ` Serge E. Hallyn
2009-12-28 18:13 ` Serge E. Hallyn
2009-12-29 1:21 ` Michael Stone
2009-12-29 5:26 ` Serge E. Hallyn
2009-12-27 7:53 ` Pavel Machek
2009-12-29 1:25 ` Michael Stone
2009-12-29 1:25 ` Michael Stone
2009-12-30 10:09 ` Pavel Machek
2009-12-30 18:47 ` Serge E. Hallyn
2009-12-27 1:06 ` [PATCH 2/3] Security: Implement disablenetwork semantics. (v4) Michael Stone
2009-12-27 1:06 ` Michael Stone
2009-12-27 1:20 ` Tetsuo Handa
2009-12-30 18:50 ` Serge E. Hallyn
2010-01-01 14:31 ` Pavel Machek
2010-01-10 21:11 ` James Morris
2010-01-10 21:16 ` Pavel Machek
2010-01-10 21:44 ` James Morris
2010-01-10 21:54 ` Michael Stone
2010-01-10 21:54 ` Michael Stone
2010-01-10 21:58 ` Pavel Machek
2010-01-10 21:58 ` Pavel Machek
2010-01-10 22:40 ` Michael Stone
2010-01-10 22:40 ` Michael Stone
2010-01-11 1:07 ` Tetsuo Handa
2010-01-11 1:45 ` Michael Stone
2010-01-11 1:45 ` Michael Stone
2010-01-11 17:49 ` Serge E. Hallyn
2010-01-11 17:49 ` Serge E. Hallyn
2010-01-12 6:10 ` Michael Stone
2010-01-12 6:10 ` Michael Stone
2010-01-12 15:52 ` Serge E. Hallyn
2010-01-12 15:52 ` Serge E. Hallyn
2010-01-14 9:23 ` Pavel Machek
2010-01-14 9:23 ` Pavel Machek
2010-01-14 15:00 ` Serge E. Hallyn
2010-01-14 15:00 ` Serge E. Hallyn
2010-01-14 16:36 ` Michael Stone
2010-01-14 16:36 ` Michael Stone
2010-01-14 16:47 ` Serge E. Hallyn
2010-01-14 16:47 ` Serge E. Hallyn
[not found] ` <20100114171309.GA6372@heat>
2010-01-14 17:36 ` Serge E. Hallyn
2010-01-14 17:36 ` Serge E. Hallyn
2010-01-15 8:10 ` disablenetwork (v5) patches Michael Stone
2010-01-15 8:10 ` Michael Stone
2010-01-15 8:12 ` disablenetwork (v5): Remove a TOCTTOU race by passing flags by value Michael Stone
2010-01-15 8:12 ` Michael Stone
2010-01-15 8:12 ` disablenetwork (v5): Simplify the disablenetwork sendmsg hook Michael Stone
2010-01-15 8:12 ` Michael Stone
2010-01-15 8:13 ` disablenetwork (v5): Require CAP_SETPCAP to enable disablenetwork Michael Stone
2010-01-15 8:13 ` Michael Stone
2010-01-17 2:58 ` Andrew G. Morgan
2010-01-17 2:58 ` Andrew G. Morgan
[not found] ` <20100117044825.GA2712@heat>
2010-01-17 4:58 ` disablenetwork (v5): Require CAP_SETPCAP to enable Andrew G. Morgan
2010-01-17 4:58 ` Andrew G. Morgan
2010-01-18 19:30 ` Serge E. Hallyn
2010-01-18 19:30 ` Serge E. Hallyn
2010-01-15 8:13 ` disablenetwork (v5): Update documentation for PR_NETWORK_ENABLE_DN Michael Stone
2010-01-15 8:13 ` Michael Stone
2010-01-17 6:01 ` disablenetwork (v5) patches Kyle Moffett
2010-01-17 6:01 ` Kyle Moffett
2010-01-17 6:01 ` Kyle Moffett
[not found] ` <20100117180728.GA2848@heat>
2010-01-17 21:17 ` Kyle Moffett
2010-01-17 21:17 ` Kyle Moffett
2010-01-12 18:30 ` [PATCH 2/3] Security: Implement disablenetwork semantics. (v4) David Wagner
2010-01-13 20:23 ` Pavel Machek
2010-01-11 1:46 ` Casey Schaufler
2010-01-12 3:19 ` Valdis.Kletnieks
2010-01-12 4:01 ` Casey Schaufler
2010-01-11 12:01 ` Pavel Machek
2010-01-11 1:29 ` David Wagner
2010-01-11 13:39 ` Simon Horman
2010-01-12 2:54 ` Valdis.Kletnieks
2010-01-12 7:59 ` Pavel Machek
2010-01-12 14:28 ` Valdis.Kletnieks
2010-01-14 9:22 ` Pavel Machek
2010-01-14 14:30 ` David Wagner
2010-01-18 12:54 ` Valdis.Kletnieks
2010-01-18 15:56 ` Andrew G. Morgan
2010-01-18 15:56 ` Andrew G. Morgan
2010-01-10 22:18 ` Kyle Moffett
2010-01-10 22:18 ` Kyle Moffett
2010-01-10 23:08 ` Michael Stone
2010-01-10 23:08 ` Michael Stone
2010-01-10 23:41 ` Bryan Donlan
2010-01-10 23:41 ` Bryan Donlan
2010-01-11 1:50 ` Casey Schaufler
2010-01-11 1:50 ` Casey Schaufler
2010-01-11 2:15 ` Bryan Donlan
2010-01-11 2:15 ` Bryan Donlan
2010-01-11 11:53 ` Pavel Machek
2010-01-11 11:53 ` Pavel Machek
2010-01-11 1:41 ` David Wagner
2010-01-10 22:58 ` James Morris
2010-01-11 1:21 ` David Wagner
2009-12-27 1:07 ` [PATCH 3/3] Security: Document disablenetwork. (v4) Michael Stone
2009-12-27 1:07 ` Michael Stone
2009-12-27 1:39 ` Tetsuo Handa
2009-12-27 16:25 ` Michael Stone
2009-12-27 8:36 ` RFC: disablenetwork facility. (v4) Tetsuo Handa
2009-12-27 8:38 ` Pavel Machek
2009-12-27 11:49 ` Tetsuo Handa
2009-12-27 12:18 ` Al Viro
2009-12-27 15:03 ` Serge E. Hallyn
2009-12-27 15:47 ` Michael Stone
2009-12-27 16:12 ` Serge E. Hallyn
2009-12-27 16:36 ` Michael Stone
2009-12-27 18:06 ` Pavel Machek
2009-12-27 19:08 ` Pavel Machek
2009-12-28 6:07 ` Michael Stone
2009-12-28 6:07 ` Michael Stone
2009-12-28 10:10 ` Pavel Machek
2009-12-28 14:37 ` Valdis.Kletnieks
2009-12-28 20:55 ` Pavel Machek
2009-12-28 21:28 ` Valdis.Kletnieks
2009-12-28 21:33 ` Bryan Donlan
2009-12-28 21:33 ` Bryan Donlan
2009-12-29 6:08 ` Serge E. Hallyn
2010-01-01 15:06 ` Pavel Machek
2009-12-28 16:31 ` Michael Stone
2009-12-28 16:31 ` Michael Stone
2009-12-28 21:08 ` Pavel Machek
2009-12-28 21:24 ` Valdis.Kletnieks
2009-12-28 22:10 ` David Wagner
2009-12-28 23:54 ` Valdis.Kletnieks
2009-12-29 0:42 ` David Wagner
2009-12-29 1:39 ` Valdis.Kletnieks
2010-01-01 15:55 ` Pavel Machek
2009-12-28 18:13 ` Serge E. Hallyn
2009-12-29 5:01 ` Michael Stone
2009-12-29 5:01 ` Michael Stone
2009-12-29 5:56 ` Serge E. Hallyn
2009-12-29 16:31 ` Michael Stone
2009-12-29 16:31 ` Michael Stone
2009-12-29 11:06 ` Eric W. Biederman
2009-12-29 15:11 ` Serge E. Hallyn
2009-12-29 16:05 ` Bryan Donlan
2009-12-29 16:39 ` Serge E. Hallyn
2009-12-29 16:39 ` Serge E. Hallyn
2009-12-29 17:01 ` Bryan Donlan
2009-12-29 17:01 ` Bryan Donlan
2009-12-29 18:36 ` Eric W. Biederman
2009-12-29 18:36 ` Eric W. Biederman
2009-12-29 19:08 ` Bryan Donlan
2009-12-29 20:56 ` Eric W. Biederman
2009-12-29 21:27 ` Serge E. Hallyn
2009-12-29 21:27 ` Serge E. Hallyn
2009-12-29 21:46 ` Valdis.Kletnieks
2009-12-29 22:16 ` Serge E. Hallyn
2009-12-29 20:10 ` Benny Amorsen
2009-12-29 20:10 ` Benny Amorsen
2009-12-29 20:40 ` Eric W. Biederman
2009-12-29 20:40 ` Eric W. Biederman
2009-12-29 20:43 ` Bryan Donlan
2009-12-29 20:43 ` Bryan Donlan
2009-12-29 21:11 ` Alan Cox
2009-12-29 21:11 ` Alan Cox
2009-12-29 21:14 ` Bryan Donlan
2009-12-29 21:14 ` Bryan Donlan
2009-12-29 21:35 ` Alan Cox
2009-12-29 21:35 ` Alan Cox
2009-12-29 21:29 ` Eric W. Biederman
2009-12-29 21:29 ` Eric W. Biederman
2009-12-29 22:36 ` Serge E. Hallyn
2009-12-29 22:36 ` Serge E. Hallyn
2009-12-30 3:26 ` Eric W. Biederman
2009-12-30 3:26 ` Eric W. Biederman
2009-12-30 3:50 ` Serge E. Hallyn
2009-12-30 3:50 ` Serge E. Hallyn
2009-12-30 4:29 ` Eric W. Biederman
2009-12-30 4:29 ` Eric W. Biederman
2009-12-30 18:00 ` Serge E. Hallyn
2009-12-30 18:00 ` Serge E. Hallyn
2009-12-30 21:12 ` Eric W. Biederman
2009-12-30 21:12 ` Eric W. Biederman
2009-12-30 3:35 ` [RFC][PATCH] Unprivileged: Disable acquisition of privileges Eric W. Biederman
2009-12-30 3:35 ` Eric W. Biederman
2009-12-30 3:54 ` Bryan Donlan
2009-12-30 3:54 ` Bryan Donlan
2009-12-30 4:33 ` Eric W. Biederman
2009-12-30 4:33 ` Eric W. Biederman
2009-12-30 4:57 ` Bryan Donlan
2009-12-30 4:57 ` Bryan Donlan
2009-12-30 12:47 ` Eric W. Biederman
2009-12-30 12:47 ` Eric W. Biederman
2009-12-30 12:49 ` [RFC][PATCH v2] Unprivileged: Disable raising " Eric W. Biederman
2009-12-30 12:49 ` Eric W. Biederman
2009-12-30 14:52 ` Andrew G. Morgan
2009-12-30 14:52 ` Andrew G. Morgan
2009-12-30 18:35 ` Serge E. Hallyn
2009-12-30 18:35 ` Serge E. Hallyn
2009-12-30 20:07 ` Eric W. Biederman
2009-12-30 20:07 ` Eric W. Biederman
2009-12-30 20:17 ` Serge E. Hallyn
2009-12-30 20:17 ` Serge E. Hallyn
2009-12-30 21:15 ` [RFC][PATCH v3] " Eric W. Biederman
2009-12-30 21:15 ` Eric W. Biederman
2009-12-30 21:29 ` Alan Cox
2009-12-30 21:29 ` Alan Cox
2009-12-30 21:36 ` Eric W. Biederman
2009-12-30 21:36 ` Eric W. Biederman
2009-12-30 23:00 ` Alan Cox
2009-12-30 23:00 ` Alan Cox
2009-12-31 2:44 ` Bryan Donlan
2009-12-31 2:44 ` Bryan Donlan
2009-12-31 17:33 ` Alan Cox
2009-12-31 17:33 ` Alan Cox
2009-12-31 17:52 ` David Wagner
2009-12-31 17:52 ` Serge E. Hallyn
2009-12-31 17:52 ` Serge E. Hallyn
2009-12-31 18:20 ` Andrew G. Morgan
2009-12-31 18:20 ` Andrew G. Morgan
2009-12-31 18:32 ` Eric W. Biederman
2009-12-31 18:32 ` Eric W. Biederman
2010-01-01 14:43 ` Alan Cox
2010-01-01 14:43 ` Alan Cox
2010-01-01 14:53 ` Pavel Machek
2010-01-01 14:53 ` Pavel Machek
2010-01-01 16:26 ` Eric W. Biederman
2010-01-01 16:26 ` Eric W. Biederman
2010-01-01 21:35 ` Casey Schaufler
2010-01-01 21:35 ` Casey Schaufler
2010-01-01 22:39 ` Alan Cox
2010-01-01 22:39 ` Alan Cox
2010-01-01 23:18 ` Casey Schaufler
2010-01-01 23:18 ` Casey Schaufler
2010-01-02 0:42 ` Peter Dolding
2010-01-02 0:42 ` Peter Dolding
[not found] ` <4B3FB0FC.3030809@schaufler-ca.com>
2010-01-03 1:43 ` Peter Dolding
2010-01-03 1:43 ` Peter Dolding
2009-12-31 18:41 ` Eric W. Biederman
2009-12-31 18:41 ` Eric W. Biederman
2009-12-31 21:46 ` Serge E. Hallyn
2009-12-31 21:46 ` Serge E. Hallyn
2010-01-01 21:17 ` Andrew G. Morgan
2010-01-01 21:17 ` Andrew G. Morgan
2010-01-01 14:57 ` Alan Cox
2010-01-01 14:57 ` Alan Cox
2009-12-31 8:57 ` Eric W. Biederman
2009-12-31 8:57 ` Eric W. Biederman
2009-12-31 13:00 ` Samir Bellabes [this message]
2009-12-31 13:00 ` Samir Bellabes
2009-12-31 14:08 ` Peter Dolding
2009-12-31 14:08 ` Peter Dolding
2009-12-31 17:06 ` Alan Cox
2009-12-31 17:06 ` Alan Cox
2009-12-31 17:55 ` David Wagner
2010-01-01 14:46 ` Alan Cox
2010-01-02 6:23 ` David Wagner
2010-01-02 13:55 ` Alan Cox
2010-01-04 0:55 ` David Wagner
2010-01-01 0:12 ` Peter Dolding
2010-01-01 0:12 ` Peter Dolding
2010-01-01 10:28 ` Pavel Machek
2010-01-01 10:28 ` Pavel Machek
2009-12-31 15:25 ` Serge E. Hallyn
2009-12-31 15:25 ` Serge E. Hallyn
2009-12-31 16:48 ` Eric W. Biederman
2009-12-31 16:48 ` Eric W. Biederman
2009-12-30 18:29 ` [RFC][PATCH v2] " Serge E. Hallyn
2009-12-30 18:29 ` Serge E. Hallyn
2009-12-30 20:45 ` Eric W. Biederman
2009-12-30 20:45 ` Eric W. Biederman
2009-12-29 18:03 ` RFC: disablenetwork facility. (v4) Eric W. Biederman
2009-12-29 16:06 ` Michael Stone
2009-12-29 16:06 ` Michael Stone
2009-12-30 7:24 ` David Wagner
2009-12-30 16:26 ` Valdis.Kletnieks
2010-01-01 11:41 ` Eric W. Biederman
2010-01-02 6:28 ` David Wagner
2010-01-01 15:11 ` Pavel Machek
2009-12-27 8:51 ` Al Viro
2009-12-27 11:23 ` Valdis.Kletnieks
2009-12-27 12:45 ` Andi Kleen
2009-12-27 15:55 ` Michael Stone
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=m2bphfti1u.fsf@ssh.synack.fr \
--to=sam@synack.fr \
--cc=Valdis.Kletnieks@vt.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andi@firstfloor.org \
--cc=bdonlan@gmail.com \
--cc=benny+usenet@amorsen.dk \
--cc=bernie@codewiz.org \
--cc=casey@schaufler-ca.com \
--cc=cscott@cscott.net \
--cc=david@lang.hm \
--cc=ebiederm@xmission.com \
--cc=herbert@gondor.apana.org.au \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=michael@laptop.org \
--cc=morgan@kernel.org \
--cc=mrs@mythic-beasts.com \
--cc=netdev@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=randy.dunlap@oracle.com \
--cc=serue@us.ibm.com \
--cc=socketcan@hartkopp.net \
--cc=viro@zeniv.linux.org.uk \
--cc=xiyou.wangcong@gmail.com \
--cc=zbr@ioremap.net \
/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.