From: Igor Stoppa <igor.stoppa@gmail.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>,
Kees Cook <keescook@chromium.org>,
Matthew Wilcox <willy@infradead.org>,
Dave Chinner <david@fromorbit.com>,
James Morris <jmorris@namei.org>,
Michal Hocko <mhocko@kernel.org>,
kernel-hardening@lists.openwall.com,
linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
igor stoppa <igor.stoppa@huawei.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Jonathan Corbet <corbet@lwn.net>,
Laura Abbott <labbott@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Kate Stewart <kstewart@linuxfoundation.org>,
"David S. Miller" <davem@davemloft.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Philippe Ombredanne <pombredanne@nexb.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Josh Triplett <josh@joshtriplett.org>,
rostedt <rostedt@goodmis.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 14/17] prmem: llist, hlist, both plain and rcu
Date: Wed, 24 Oct 2018 17:03:01 +0300 [thread overview]
Message-ID: <243a8ff2-889c-089f-a1ff-c882933ca5c3@gmail.com> (raw)
In-Reply-To: <1634210774.446.1540381072927.JavaMail.zimbra@efficios.com>
On 24/10/18 14:37, Mathieu Desnoyers wrote:
> I could not find a description of the overall context of this patch
> (e.g. a patch 00/17 ?) that would explain the attack vectors this aims
> to protect against.
Apologies, I have to admit I was a bit baffled about what to do: the
patchset spans across several subsystems and I was reluctant at spamming
all the mailing lists.
I was hoping that by CC-ing kernel.org, the explicit recipients would
get both the mail directly intended for them (as subsystem
maintainers/supporters) and the rest.
The next time I'll err in the opposite direction.
In the meanwhile, please find the whole set here:
https://www.openwall.com/lists/kernel-hardening/2018/10/23/3
> This might help figuring out whether this added complexity in the core
> kernel is worth it.
I hope it will.
> Also, is it the right approach to duplicate existing APIs, or should we
> rather hook into page fault handlers and let the kernel do those "shadow"
> mappings under the hood ?
This question is probably a good candidate for the small Q&A section I
have in the 00/17.
> Adding a new GFP flags for dynamic allocation, and a macro mapping to
> a section attribute might suffice for allocation or definition of such
> mostly-read-only/seldom-updated data.
I think what you are proposing makes sense from a pure hardening
standpoint. From a more defensive one, I'd rather minimise the chances
of giving a free pass to an attacker.
Maybe there is a better implementation of this, than what I have in
mind. But, based on my current understanding of what you are describing,
there would be few issues:
1) where would the pool go? The pool is a way to manage multiple vmas
and express common property they share. Even before a vma is associated
to the pool.
2) there would be more code that can seamlessly deal with both protected
and regular data. Based on what? Some parameter, I suppose.
That parameter would be the new target.
If the code is "duplicated", as you say, the actual differences are
baked in at compile time. The "duplication" would also allow to have
always inlined functions for write-rare and leave more freedom to the
compiler for their non-protected version.
Besides, I think the separate wr version also makes it very clear, to
the user of the API, that there will be a price to pay, in terms of
performance. The more seamlessly alternative might make this price less
obvious.
--
igor
next prev parent reply other threads:[~2018-10-24 14:03 UTC|newest]
Thread overview: 140+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-23 21:34 [RFC v1 PATCH 00/17] prmem: protected memory Igor Stoppa
2018-10-23 21:34 ` [PATCH 01/17] prmem: linker section for static write rare Igor Stoppa
2018-10-23 21:34 ` [PATCH 02/17] prmem: write rare for static allocation Igor Stoppa
2018-10-25 0:24 ` Dave Hansen
2018-10-29 18:03 ` Igor Stoppa
2018-10-26 9:41 ` Peter Zijlstra
2018-10-29 20:01 ` Igor Stoppa
2018-10-23 21:34 ` [PATCH 03/17] prmem: vmalloc support for dynamic allocation Igor Stoppa
2018-10-25 0:26 ` Dave Hansen
2018-10-29 18:07 ` Igor Stoppa
2018-10-23 21:34 ` [PATCH 04/17] prmem: " Igor Stoppa
2018-10-23 21:34 ` [PATCH 05/17] prmem: shorthands for write rare on common types Igor Stoppa
2018-10-25 0:28 ` Dave Hansen
2018-10-29 18:12 ` Igor Stoppa
2018-10-23 21:34 ` [PATCH 06/17] prmem: test cases for memory protection Igor Stoppa
2018-10-24 3:27 ` Randy Dunlap
2018-10-24 14:24 ` Igor Stoppa
2018-10-25 16:43 ` Dave Hansen
2018-10-29 18:16 ` Igor Stoppa
2018-10-23 21:34 ` [PATCH 07/17] prmem: lkdtm tests " Igor Stoppa
2018-10-23 21:34 ` [PATCH 08/17] prmem: struct page: track vmap_area Igor Stoppa
2018-10-24 3:12 ` Matthew Wilcox
2018-10-24 23:01 ` Igor Stoppa
2018-10-25 2:13 ` Matthew Wilcox
2018-10-29 18:21 ` Igor Stoppa
2018-10-23 21:34 ` [PATCH 09/17] prmem: hardened usercopy Igor Stoppa
2018-10-29 11:45 ` Chris von Recklinghausen
2018-10-29 18:24 ` Igor Stoppa
2018-10-23 21:34 ` [PATCH 10/17] prmem: documentation Igor Stoppa
2018-10-24 3:48 ` Randy Dunlap
2018-10-24 14:30 ` Igor Stoppa
2018-10-24 23:04 ` Mike Rapoport
2018-10-29 19:05 ` Igor Stoppa
2018-10-26 9:26 ` Peter Zijlstra
2018-10-26 10:20 ` Matthew Wilcox
2018-10-29 19:28 ` Igor Stoppa
2018-10-26 10:46 ` Kees Cook
2018-10-28 18:31 ` Peter Zijlstra
2018-10-29 21:04 ` Igor Stoppa
2018-10-30 15:26 ` Peter Zijlstra
2018-10-30 16:37 ` Kees Cook
2018-10-30 17:06 ` Andy Lutomirski
2018-10-30 17:58 ` Matthew Wilcox
2018-10-30 18:03 ` Dave Hansen
2018-10-31 9:18 ` Peter Zijlstra
2018-10-30 18:28 ` Tycho Andersen
2018-10-30 19:20 ` Matthew Wilcox
2018-10-30 20:43 ` Igor Stoppa
2018-10-30 21:02 ` Andy Lutomirski
2018-10-30 21:07 ` Kees Cook
2018-10-30 21:25 ` Igor Stoppa
2018-10-30 22:15 ` Igor Stoppa
2018-10-31 10:11 ` Peter Zijlstra
2018-10-31 20:38 ` Andy Lutomirski
2018-10-31 20:53 ` Andy Lutomirski
2018-10-31 9:45 ` Peter Zijlstra
2018-10-30 21:35 ` Matthew Wilcox
2018-10-30 21:49 ` Igor Stoppa
2018-10-31 4:41 ` Andy Lutomirski
2018-10-31 9:08 ` Igor Stoppa
2018-10-31 19:38 ` Igor Stoppa
2018-10-31 10:02 ` Peter Zijlstra
2018-10-31 20:36 ` Andy Lutomirski
2018-10-31 21:00 ` Peter Zijlstra
2018-10-31 22:57 ` Andy Lutomirski
2018-10-31 23:10 ` Igor Stoppa
2018-10-31 23:19 ` Andy Lutomirski
2018-10-31 23:26 ` Igor Stoppa
2018-11-01 8:21 ` Thomas Gleixner
2018-11-01 15:58 ` Igor Stoppa
2018-11-01 17:08 ` Peter Zijlstra
2018-10-30 18:51 ` Andy Lutomirski
2018-10-30 19:14 ` Kees Cook
2018-10-30 21:25 ` Matthew Wilcox
2018-10-30 21:55 ` Igor Stoppa
2018-10-30 22:08 ` Matthew Wilcox
2018-10-31 9:29 ` Peter Zijlstra
2018-10-30 23:18 ` Nadav Amit
2018-10-31 9:08 ` Peter Zijlstra
2018-11-01 16:31 ` Nadav Amit
2018-11-02 21:11 ` Nadav Amit
2018-10-31 9:36 ` Peter Zijlstra
2018-10-31 11:33 ` Matthew Wilcox
2018-11-13 14:25 ` Igor Stoppa
2018-11-13 17:16 ` Andy Lutomirski
2018-11-13 17:43 ` Nadav Amit
2018-11-13 17:47 ` Andy Lutomirski
2018-11-13 18:06 ` Nadav Amit
2018-11-13 18:31 ` Igor Stoppa
2018-11-13 18:33 ` Igor Stoppa
2018-11-13 18:36 ` Andy Lutomirski
2018-11-13 19:03 ` Igor Stoppa
2018-11-21 16:34 ` Igor Stoppa
2018-11-21 17:36 ` Nadav Amit
2018-11-21 18:01 ` Igor Stoppa
2018-11-21 18:15 ` Andy Lutomirski
2018-11-22 19:27 ` Igor Stoppa
2018-11-22 20:04 ` Matthew Wilcox
2018-11-22 20:53 ` Andy Lutomirski
2018-12-04 12:34 ` Igor Stoppa
2018-11-13 18:48 ` Andy Lutomirski
2018-11-13 19:35 ` Igor Stoppa
2018-11-13 18:26 ` Igor Stoppa
2018-11-13 18:35 ` Andy Lutomirski
2018-11-13 19:01 ` Igor Stoppa
2018-10-31 9:27 ` Igor Stoppa
2018-10-26 11:09 ` Markus Heiser
2018-10-29 19:35 ` Igor Stoppa
2018-10-26 15:05 ` Jonathan Corbet
2018-10-29 19:38 ` Igor Stoppa
2018-10-29 20:35 ` Igor Stoppa
2018-10-23 21:34 ` [PATCH 11/17] prmem: llist: use designated initializer Igor Stoppa
2018-10-23 21:34 ` [PATCH 12/17] prmem: linked list: set alignment Igor Stoppa
2018-10-26 9:31 ` Peter Zijlstra
2018-10-23 21:35 ` [PATCH 13/17] prmem: linked list: disable layout randomization Igor Stoppa
2018-10-24 13:43 ` Alexey Dobriyan
2018-10-29 19:40 ` Igor Stoppa
2018-10-26 9:32 ` Peter Zijlstra
2018-10-26 10:17 ` Matthew Wilcox
2018-10-30 15:39 ` Peter Zijlstra
2018-10-23 21:35 ` [PATCH 14/17] prmem: llist, hlist, both plain and rcu Igor Stoppa
2018-10-24 11:37 ` Mathieu Desnoyers
2018-10-24 14:03 ` Igor Stoppa [this message]
2018-10-24 14:56 ` Tycho Andersen
2018-10-24 22:52 ` Igor Stoppa
2018-10-25 8:11 ` Tycho Andersen
2018-10-28 9:52 ` Steven Rostedt
2018-10-29 19:43 ` Igor Stoppa
2018-10-26 9:38 ` Peter Zijlstra
2018-10-23 21:35 ` [PATCH 15/17] prmem: test cases for prlist and prhlist Igor Stoppa
2018-10-23 21:35 ` [PATCH 16/17] prmem: pratomic-long Igor Stoppa
2018-10-25 0:13 ` Peter Zijlstra
2018-10-29 21:17 ` Igor Stoppa
2018-10-30 15:58 ` Peter Zijlstra
2018-10-30 16:28 ` Will Deacon
2018-10-31 9:10 ` Peter Zijlstra
2018-11-01 3:28 ` Kees Cook
2018-10-23 21:35 ` [PATCH 17/17] prmem: ima: turn the measurements list write rare Igor Stoppa
2018-10-24 23:03 ` [RFC v1 PATCH 00/17] prmem: protected memory Dave Chinner
2018-10-29 19:47 ` Igor Stoppa
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=243a8ff2-889c-089f-a1ff-c882933ca5c3@gmail.com \
--to=igor.stoppa@gmail.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=david@fromorbit.com \
--cc=gregkh@linuxfoundation.org \
--cc=igor.stoppa@huawei.com \
--cc=jiangshanlai@gmail.com \
--cc=jmorris@namei.org \
--cc=josh@joshtriplett.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=kstewart@linuxfoundation.org \
--cc=labbott@redhat.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhocko@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pombredanne@nexb.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=willy@infradead.org \
--cc=zohar@linux.vnet.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).