From: Peter Zijlstra <email@example.com> To: Igor Stoppa <firstname.lastname@example.org> Cc: Kees Cook <email@example.com>, Mimi Zohar <firstname.lastname@example.org>, Matthew Wilcox <email@example.com>, Dave Chinner <firstname.lastname@example.org>, James Morris <email@example.com>, Michal Hocko <firstname.lastname@example.org>, Kernel Hardening <email@example.com>, linux-integrity <firstname.lastname@example.org>, linux-security-module <email@example.com>, Igor Stoppa <firstname.lastname@example.org>, Dave Hansen <email@example.com>, Jonathan Corbet <firstname.lastname@example.org>, Laura Abbott <email@example.com>, Randy Dunlap <firstname.lastname@example.org>, Mike Rapoport <email@example.com>, "open list:DOCUMENTATION" <firstname.lastname@example.org>, LKML <email@example.com>, Andy Lutomirski <firstname.lastname@example.org>, Thomas Gleixner <email@example.com> Subject: Re: [PATCH 10/17] prmem: documentation Date: Tue, 30 Oct 2018 16:26:41 +0100 Message-ID: <20181030152641.GE8177@hirez.programming.kicks-ass.net> (raw) In-Reply-To: <firstname.lastname@example.org> On Mon, Oct 29, 2018 at 11:04:01PM +0200, Igor Stoppa wrote: > On 28/10/2018 18:31, Peter Zijlstra wrote: > > On Fri, Oct 26, 2018 at 11:46:28AM +0100, Kees Cook wrote: > > > On Fri, Oct 26, 2018 at 10:26 AM, Peter Zijlstra <email@example.com> wrote: > > > > I still don't really understand the whole write-rare thing; how does it > > > > really help? If we can write in kernel memory, we can write to > > > > page-tables too. > > > > > One aspect of hardening the kernel against attack is reducing the > > > internal attack surface. Not all flaws are created equal, so there is > > > variation in what limitations an attacker may have when exploiting > > > flaws (not many flaws end up being a fully controlled "write anything, > > > anywhere, at any time"). By making the more sensitive data structures > > > of the kernel read-only, we reduce the risk of an attacker finding a > > > path to manipulating the kernel's behavior in a significant way. > > > > > > Examples of typical sensitive targets are function pointers, security > > > policy, and page tables. Having these "read only at rest" makes them > > > much harder to control by an attacker using memory integrity flaws. > > > > Because 'write-anywhere' exploits are easier than (and the typical first > > step to) arbitrary code execution thingies? > > > > > The "write rarely" name itself may not sufficiently describe what is > > > wanted either (I'll take the blame for the inaccurate name), so I'm > > > open to new ideas there. The implementation requirements for the > > > "sensitive data read-only at rest" feature are rather tricky: > > > > > > - allow writes only from specific places in the kernel > > > - keep those locations inline to avoid making them trivial ROP targets > > > - keep the writeability window open only to a single uninterruptable CPU > > > > The current patch set does not achieve that because it uses a global > > address space for the alias mapping (vmap) which is equally accessible > > from all CPUs. > > I never claimed to achieve 100% resilience to attacks. You never even begun explaining what you were defending against. Let alone how well it achieved its stated goals. > While it's true that the address space is accessible to all the CPUs, it is > also true that the access has a limited duration in time, and the location > where the access can be performed is not fixed. > > Iow, assuming that the CPUs not involved in the write-rare operations are > compromised and that they are trying to perform a concurrent access to the > data in the writable page, they have a limited window of opportunity. That sounds like security through obscurity. Sure it makes it harder, but it doesn't stop anything. > Said this, this I have posted is just a tentative implementation. > My primary intent was to at least give an idea of what I'd like to do: alter > some data in a way that is not easily exploitable. Since you need to modify page-tables in order to achieve this, the page-tables are also there for the attacker to write to. > > > - fast enough to deal with page table updates > > > > The proposed implementation needs page-tables for the alias; I don't see > > how you could ever do R/O page-tables when you need page-tables to > > modify your page-tables. > > It's not all-or-nothing. I really am still strugging with what it is this thing is supposed to do. As it stands, I see very little value. Yes it makes a few things a little harder, but it doesn't really do away with things. > I hope we agree at least on the reasoning that having only a limited amount > of address space directly attackable, instead of the whole set of pages > containing exploitable data, is reducing the attack surface. I do not in fact agree. Most pages are not interesting for an attack at all. So simply reducing the set of pages you can write to isn't sufficient. IOW. removing all noninteresting pages from the writable set will satisfy your criteria, but it avoids exactly 0 exploits. What you need to argue is that we remove common exploit targets, and you've utterly failed to do so. Kees mentioned: function pointers, page-tables and a few other things. You mentioned nothing. > Furthermore, if we think about possible limitations that the attack might > have (maximum reach), the level of protection might be even higher. I have > to use "might" because I cannot foresee the vulnerability. That's just a bunch of words together that don't really say anything afaict. > Furthermore, taking a different angle: your average attacker is not > necessarily very social and inclined to share the vulnerability found. > It is safe to assume that in most cases each attacker has to identify the > attack strategy autonomously. > Reducing the amount of individual who can perform an attack, by increasing > the expertise required is also a way of doing damage control. If you make RO all noninteresting pages, you in fact increase the density of interesting targets and make things easier. > > And this is entirely irrespective of performance. > > I have not completely given up on performance, but, being write-rare, I see > improved performance as just a way of widening the range of possible > recipients for the hardening. What?! Are you saying you don't care about performance? > > Right... /me goes find the patches we did for text_poke. Hmm, those > > never seem to have made it: > > > > https://firstname.lastname@example.org > > > > like that. That approach will in fact work and not be a completely > > broken mess like this thing. > > That approach is x86 specific. It is not. Every architecture does switch_mm() with IRQs disabled, as that is exactly what the scheduler does. And keeping a second init_mm around also isn't very architecture specific I feel. > > > We need to find a good way to do the write-windowing that works well > > > for static and dynamic structures _and_ for the page tables... this > > > continues to be tricky. > > > > > > Making it resilient against ROP-style targets makes it difficult to > > > deal with certain data structures (like list manipulation). In my > > > earlier RFC, I tried to provide enough examples of where this could > > > get used to let people see some of the complexity. Igor's series > > > expands this to even more examples using dynamic allocation. > > > > Doing 2 CR3 writes for 'every' WR write doesn't seem like it would be > > fast enough for much of anything. > > Part of the reason for the duplication is that, even if the wr_API I came up > with, can be collapsed with the regular API, the implementation needs to be > different, to be faster. > > Ex: > * force the list_head structure to be aligned so that it will always be > fully contained by a single page > * create alternate mapping for all the pages involved (max 1 page for each > list_head) > * do the lsit operation on the remapped list_heads > * destroy all the mappings Those constraints are due to single page aliases. > I can try to introduce some wrapper similar to kmap_atomic(), as suggested > by Dave Hansen, which can improve the coding, but it will not change the > actual set of operations performed. See below, I don't think kmap_atomic() is either correct or workable. One thing that might be interesting is teaching objtool about the write-enable write-disable markers and making it guarantee we reach a disable after every enable. IOW, ensure we never leak this state. I think that was part of why we hated on that initial thing Kees did -- well that an disabling all WP is of course completely insane ;-). > > And I don't suppose we can take the WP fault and then fix up from there, > > because if we're doing R/O page-tables, that'll incrase the fault depth > > and we'll double fault all the time, and tripple fault where we > > currently double fault. And we all know how _awesome_ tripple faults > > are. > > > > But duplicating (and wrapping in gunk) whole APIs is just not going to > > work. > > Would something like kmap_atomic() be acceptable? Don't think so. kmap_atomic() on x86_32 (64bit doesn't have it at all) only does the TLB invalidate on the one CPU, which we've established is incorrect. Also, kmap_atomic is still page-table based, which means not all page-tables can be read-only. > Do you have some better proposal, now that (I hope) it should be more clear > what I'm trying to do and why? You've still not talked about any actual attack vectors and how they're mitigated by these patches. I suppose the 'normal' attack goes like: 1) find buffer-overrun / bound check failure 2) use that to write to 'interesting' location 3) that write results arbitrary code execution 4) win Of course, if the store of 2 is to the current cred structure, and simply sets the effective uid to 0, we can skip 3. Which seems to suggest all cred structures should be made r/o like this. But I'm not sure I remember these patches doing that. Also, there is an inverse situation with all this. If you make everything R/O, then you need this allow-write for everything you do, which then is about to include a case with an overflow / bound check fail, and we're back to square 1. What are you doing to avoid that?
next prev parent reply index 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 [this message] 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 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 publically 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=20181030152641.GE8177@hirez.programming.kicks-ass.net \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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
Linux-Security-Module Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-security-module/0 linux-security-module/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-security-module linux-security-module/ https://lore.kernel.org/linux-security-module \ firstname.lastname@example.org email@example.com public-inbox-index linux-security-module Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-security-module AGPL code for this site: git clone https://public-inbox.org/ public-inbox