From: Igor Stoppa <igor.stoppa@gmail.com> To: Andy Lutomirski <luto@amacapital.net> Cc: Andy Lutomirski <luto@kernel.org>, Igor Stoppa <igor.stoppa@huawei.com>, Nadav Amit <nadav.amit@gmail.com>, Kees Cook <keescook@chromium.org>, Peter Zijlstra <peterz@infradead.org>, Mimi Zohar <zohar@linux.vnet.ibm.com>, Matthew Wilcox <willy@infradead.org>, Dave Chinner <david@fromorbit.com>, James Morris <jmorris@namei.org>, Michal Hocko <mhocko@kernel.org>, Kernel Hardening <kernel-hardening@lists.openwall.com>, linux-integrity <linux-integrity@vger.kernel.org>, LSM List <linux-security-module@vger.kernel.org>, Dave Hansen <dave.hansen@linux.intel.com>, Jonathan Corbet <corbet@lwn.net>, Laura Abbott <labbott@redhat.com>, Randy Dunlap <rdunlap@infradead.org>, Mike Rapoport <rppt@linux.vnet.ibm.com>, "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de> Subject: Re: [PATCH 10/17] prmem: documentation Date: Thu, 22 Nov 2018 21:27:02 +0200 Message-ID: <5e10c8e4-aa71-1eea-b1ce-50d7d0a60e8c@gmail.com> (raw) In-Reply-To: <3BB9DE07-E0AE-43E2-99F1-E4AA774CD462@amacapital.net> On 21/11/2018 20:15, Andy Lutomirski wrote: >> On Nov 21, 2018, at 9:34 AM, Igor Stoppa <igor.stoppa@gmail.com> wrote: [...] >> There might be other reasons for replicating the mm_struct. >> >> If I understand correctly how the text patching works, it happens sequentially, because of the text_mutex used by arch_jump_label_transform >> >> Which might be fine for this specific case, but I think I shouldn't introduce a global mutex, when it comes to data. >> Most likely, if two or more cores want to perform a write rare operation, there is no correlation between them, they could proceed in parallel. And if there really is, then the user of the API should introduce own locking, for that specific case. > > Text patching uses the same VA for different physical addresses, so it need a mutex to avoid conflicts. I think that, for rare writes, you should just map each rare-writable address at a *different* VA. You’ll still need a mutex (mmap_sem) to synchronize allocation and freeing of rare-writable ranges, but that shouldn’t have much contention. I have studied the code involved with Nadav's patchset. I am perplexed about these sentences you wrote. More to the point (to the best of my understanding): poking_init() ------------- 1. it gets one random poking address and ensures to have at least 2 consecutive PTEs from the same PMD 2. it then proceeds to map/unmap an address from the first of the 2 consecutive PTEs, so that, later on, there will be no need to allocate pages, which might fail, if poking from atomic context. 3. at this point, the page tables are populated, for the address that was obtained at point 1, and this is ok, because the address is fixed write_rare ---------- 4. it can happen on any available core / thread at any time, therefore each of them needs a different address 5. CPUs support hotplug, but from what I have read, I might get away with having up to nr_cpus different addresses (determined at init) and I would follow the same technique used by Nadav, of forcing the mapping of 1 or 2 (1 could be enough, I have to loop anyway, at some point) pages at each address, to ensure the population of the page tables so far, so good, but ... 6. the addresses used by each CPU are fixed 7. I do not understand the reference you make to "allocation and freeing of rare-writable ranges", because if I treat the range as such, then there is a risk that I need to populate more entries in the page table, which would have problems with the atomic context, unless write_rare from atomic is ruled out. If write_rare from atomic can be avoided, then I can also have one-use randomized addresses at each write-rare operation, instead of fixed ones, like in point 6. and, apologies for being dense: the following is still not clear to me: 8. you wrote: > You’ll still need a mutex (mmap_sem) to synchronize allocation > and freeing of rare-writable ranges, but that shouldn’t have much > contention. What causes the contention? It's the fact that the various cores are using the same mm, if I understood correctly. However, if there was one mm for each core, wouldn't that make it unnecessary to have any mutex? I feel there must be some obvious reason why multiple mms are not a good idea, yet I cannot grasp it :-( switch_mm_irqs_off() seems to have lots of references to "this_cpu_something"; if there is any optimization from having the same next across multiple cores, I'm missing it [...] > I would either refactor it or create a new function to handle the write. The main thing that Nadav is adding that I think you’ll want to use is the infrastructure for temporarily switching mms from a non-kernel-thread context. yes [...] > You’ll still want Nadav’s code for setting up the mm in the first place, though. yes -- thanks, igor
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 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 [this message] 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 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=5e10c8e4-aa71-1eea-b1ce-50d7d0a60e8c@gmail.com \ --to=igor.stoppa@gmail.com \ --cc=corbet@lwn.net \ --cc=dave.hansen@linux.intel.com \ --cc=david@fromorbit.com \ --cc=igor.stoppa@huawei.com \ --cc=jmorris@namei.org \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=labbott@redhat.com \ --cc=linux-doc@vger.kernel.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=luto@kernel.org \ --cc=mhocko@kernel.org \ --cc=nadav.amit@gmail.com \ --cc=peterz@infradead.org \ --cc=rdunlap@infradead.org \ --cc=rppt@linux.vnet.ibm.com \ --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
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 \ linux-security-module@vger.kernel.org public-inbox-index linux-security-module Example config snippet for mirrors 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.git