From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Khalid Aziz <khalid.aziz@oracle.com> Cc: juergh@gmail.com, tycho@tycho.ws, jsteckli@amazon.de, ak@linux.intel.com, torvalds@linux-foundation.org, liran.alon@oracle.com, keescook@google.com, Juerg Haefliger <juerg.haefliger@canonical.com>, deepa.srinivasan@oracle.com, chris.hyser@oracle.com, tyhicks@canonical.com, dwmw@amazon.co.uk, andrew.cooper3@citrix.com, jcm@redhat.com, boris.ostrovsky@oracle.com, kanth.ghatraju@oracle.com, joao.m.martins@oracle.com, jmattson@google.com, pradeep.vincent@oracle.com, john.haxby@oracle.com, tglx@linutronix.de, kirill.shutemov@linux.intel.com, hch@lst.de, steven.sistare@oracle.com, kernel-hardening@lists.openwall.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Tycho Andersen <tycho@docker.com> Subject: Re: [RFC PATCH v7 07/16] arm64/mm, xpfo: temporarily map dcache regions Date: Wed, 23 Jan 2019 09:56:03 -0500 [thread overview] Message-ID: <20190123145551.GD19289@Konrads-MacBook-Pro.local> (raw) In-Reply-To: <eba179acbfdea5a646c5548cb82138c1c3b74aa2.1547153058.git.khalid.aziz@oracle.com> On Thu, Jan 10, 2019 at 02:09:39PM -0700, Khalid Aziz wrote: > From: Juerg Haefliger <juerg.haefliger@canonical.com> > > If the page is unmapped by XPFO, a data cache flush results in a fatal > page fault, so let's temporarily map the region, flush the cache, and then > unmap it. > > v6: actually flush in the face of xpfo, and temporarily map the underlying > memory so it can be flushed correctly > > CC: linux-arm-kernel@lists.infradead.org > Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com> > Signed-off-by: Tycho Andersen <tycho@docker.com> > Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com> > --- > arch/arm64/mm/flush.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c > index 30695a868107..f12f26b60319 100644 > --- a/arch/arm64/mm/flush.c > +++ b/arch/arm64/mm/flush.c > @@ -20,6 +20,7 @@ > #include <linux/export.h> > #include <linux/mm.h> > #include <linux/pagemap.h> > +#include <linux/xpfo.h> > > #include <asm/cacheflush.h> > #include <asm/cache.h> > @@ -28,9 +29,15 @@ > void sync_icache_aliases(void *kaddr, unsigned long len) > { > unsigned long addr = (unsigned long)kaddr; > + unsigned long num_pages = XPFO_NUM_PAGES(addr, len); Is it possible that the 'len' is more than 32 pages? Or say 1000's of pages? Which would blow away your stack. > + void *mapping[num_pages]; > > if (icache_is_aliasing()) { > + xpfo_temp_map(kaddr, len, mapping, > + sizeof(mapping[0]) * num_pages); > __clean_dcache_area_pou(kaddr, len); > + xpfo_temp_unmap(kaddr, len, mapping, > + sizeof(mapping[0]) * num_pages); > __flush_icache_all(); > } else { > flush_icache_range(addr, addr + len); > -- > 2.17.1 >
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Khalid Aziz <khalid.aziz@oracle.com> Cc: Tycho Andersen <tycho@docker.com>, kernel-hardening@lists.openwall.com, linux-mm@kvack.org, deepa.srinivasan@oracle.com, steven.sistare@oracle.com, joao.m.martins@oracle.com, boris.ostrovsky@oracle.com, tycho@tycho.ws, ak@linux.intel.com, hch@lst.de, kanth.ghatraju@oracle.com, jsteckli@amazon.de, pradeep.vincent@oracle.com, jcm@redhat.com, liran.alon@oracle.com, tglx@linutronix.de, chris.hyser@oracle.com, linux-arm-kernel@lists.infradead.org, jmattson@google.com, juergh@gmail.com, andrew.cooper3@citrix.com, linux-kernel@vger.kernel.org, tyhicks@canonical.com, john.haxby@oracle.com, Juerg Haefliger <juerg.haefliger@canonical.com>, dwmw@amazon.co.uk, keescook@google.com, torvalds@linux-foundation.org, kirill.shutemov@linux.intel.com Subject: Re: [RFC PATCH v7 07/16] arm64/mm, xpfo: temporarily map dcache regions Date: Wed, 23 Jan 2019 09:56:03 -0500 [thread overview] Message-ID: <20190123145551.GD19289@Konrads-MacBook-Pro.local> (raw) In-Reply-To: <eba179acbfdea5a646c5548cb82138c1c3b74aa2.1547153058.git.khalid.aziz@oracle.com> On Thu, Jan 10, 2019 at 02:09:39PM -0700, Khalid Aziz wrote: > From: Juerg Haefliger <juerg.haefliger@canonical.com> > > If the page is unmapped by XPFO, a data cache flush results in a fatal > page fault, so let's temporarily map the region, flush the cache, and then > unmap it. > > v6: actually flush in the face of xpfo, and temporarily map the underlying > memory so it can be flushed correctly > > CC: linux-arm-kernel@lists.infradead.org > Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com> > Signed-off-by: Tycho Andersen <tycho@docker.com> > Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com> > --- > arch/arm64/mm/flush.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c > index 30695a868107..f12f26b60319 100644 > --- a/arch/arm64/mm/flush.c > +++ b/arch/arm64/mm/flush.c > @@ -20,6 +20,7 @@ > #include <linux/export.h> > #include <linux/mm.h> > #include <linux/pagemap.h> > +#include <linux/xpfo.h> > > #include <asm/cacheflush.h> > #include <asm/cache.h> > @@ -28,9 +29,15 @@ > void sync_icache_aliases(void *kaddr, unsigned long len) > { > unsigned long addr = (unsigned long)kaddr; > + unsigned long num_pages = XPFO_NUM_PAGES(addr, len); Is it possible that the 'len' is more than 32 pages? Or say 1000's of pages? Which would blow away your stack. > + void *mapping[num_pages]; > > if (icache_is_aliasing()) { > + xpfo_temp_map(kaddr, len, mapping, > + sizeof(mapping[0]) * num_pages); > __clean_dcache_area_pou(kaddr, len); > + xpfo_temp_unmap(kaddr, len, mapping, > + sizeof(mapping[0]) * num_pages); > __flush_icache_all(); > } else { > flush_icache_range(addr, addr + len); > -- > 2.17.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-01-23 14:57 UTC|newest] Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-10 21:09 [RFC PATCH v7 00/16] Add support for eXclusive Page Frame Ownership Khalid Aziz 2019-01-10 21:09 ` [RFC PATCH v7 01/16] mm: add MAP_HUGETLB support to vm_mmap Khalid Aziz 2019-01-10 21:09 ` [RFC PATCH v7 02/16] x86: always set IF before oopsing from page fault Khalid Aziz 2019-01-10 21:09 ` [RFC PATCH v7 03/16] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO) Khalid Aziz 2019-01-10 21:09 ` [RFC PATCH v7 04/16] swiotlb: Map the buffer if it was unmapped by XPFO Khalid Aziz 2019-01-23 14:16 ` Konrad Rzeszutek Wilk 2019-01-10 21:09 ` [RFC PATCH v7 05/16] arm64/mm: Add support for XPFO Khalid Aziz 2019-01-10 21:09 ` Khalid Aziz 2019-01-23 14:20 ` Konrad Rzeszutek Wilk 2019-01-23 14:20 ` Konrad Rzeszutek Wilk 2019-02-12 15:45 ` Khalid Aziz 2019-02-12 15:45 ` Khalid Aziz 2019-01-23 14:24 ` Konrad Rzeszutek Wilk 2019-01-23 14:24 ` Konrad Rzeszutek Wilk 2019-02-12 15:52 ` Khalid Aziz 2019-02-12 15:52 ` Khalid Aziz 2019-02-12 20:01 ` Laura Abbott 2019-02-12 20:01 ` Laura Abbott 2019-02-12 20:34 ` Khalid Aziz 2019-02-12 20:34 ` Khalid Aziz 2019-01-10 21:09 ` [RFC PATCH v7 06/16] xpfo: add primitives for mapping underlying memory Khalid Aziz 2019-01-10 21:09 ` [RFC PATCH v7 07/16] arm64/mm, xpfo: temporarily map dcache regions Khalid Aziz 2019-01-10 21:09 ` Khalid Aziz 2019-01-11 14:54 ` Tycho Andersen 2019-01-11 14:54 ` Tycho Andersen 2019-01-11 18:28 ` Khalid Aziz 2019-01-11 18:28 ` Khalid Aziz 2019-01-11 19:50 ` Tycho Andersen 2019-01-11 19:50 ` Tycho Andersen 2019-01-23 14:56 ` Konrad Rzeszutek Wilk [this message] 2019-01-23 14:56 ` Konrad Rzeszutek Wilk 2019-01-10 21:09 ` [RFC PATCH v7 08/16] arm64/mm: disable section/contiguous mappings if XPFO is enabled Khalid Aziz 2019-01-10 21:09 ` Khalid Aziz 2019-01-10 21:09 ` [RFC PATCH v7 09/16] mm: add a user_virt_to_phys symbol Khalid Aziz 2019-01-10 21:09 ` Khalid Aziz 2019-01-23 15:03 ` Konrad Rzeszutek Wilk 2019-01-23 15:03 ` Konrad Rzeszutek Wilk 2019-01-10 21:09 ` [RFC PATCH v7 10/16] lkdtm: Add test for XPFO Khalid Aziz 2019-01-10 21:09 ` [RFC PATCH v7 11/16] mm, x86: omit TLB flushing by default for XPFO page table modifications Khalid Aziz 2019-01-10 21:09 ` [RFC PATCH v7 12/16] xpfo, mm: remove dependency on CONFIG_PAGE_EXTENSION Khalid Aziz 2019-01-16 15:01 ` Julian Stecklina 2019-01-10 21:09 ` [RFC PATCH v7 13/16] xpfo, mm: optimize spinlock usage in xpfo_kunmap Khalid Aziz 2019-01-10 21:09 ` [RFC PATCH v7 14/16] EXPERIMENTAL: xpfo, mm: optimize spin lock usage in xpfo_kmap Khalid Aziz 2019-01-17 0:18 ` Laura Abbott 2019-01-17 15:14 ` Khalid Aziz 2019-01-10 21:09 ` [RFC PATCH v7 15/16] xpfo, mm: Fix hang when booting with "xpfotlbflush" Khalid Aziz 2019-01-10 21:09 ` [RFC PATCH v7 16/16] xpfo, mm: Defer TLB flushes for non-current CPUs (x86 only) Khalid Aziz 2019-01-10 23:07 ` [RFC PATCH v7 00/16] Add support for eXclusive Page Frame Ownership Kees Cook 2019-01-10 23:07 ` Kees Cook 2019-01-11 0:20 ` Khalid Aziz 2019-01-11 0:44 ` Andy Lutomirski 2019-01-11 0:44 ` Andy Lutomirski 2019-01-11 21:45 ` Khalid Aziz 2019-01-10 23:40 ` Dave Hansen 2019-01-11 9:59 ` Peter Zijlstra 2019-01-11 18:21 ` Khalid Aziz 2019-01-11 20:42 ` Dave Hansen 2019-01-11 21:06 ` Andy Lutomirski 2019-01-11 21:06 ` Andy Lutomirski 2019-01-11 23:25 ` Khalid Aziz 2019-01-11 23:23 ` Khalid Aziz 2019-01-16 1:28 ` Laura Abbott 2019-01-16 14:56 ` Julian Stecklina 2019-01-16 15:16 ` Khalid Aziz 2019-01-17 23:38 ` Laura Abbott
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=20190123145551.GD19289@Konrads-MacBook-Pro.local \ --to=konrad.wilk@oracle.com \ --cc=ak@linux.intel.com \ --cc=andrew.cooper3@citrix.com \ --cc=boris.ostrovsky@oracle.com \ --cc=chris.hyser@oracle.com \ --cc=deepa.srinivasan@oracle.com \ --cc=dwmw@amazon.co.uk \ --cc=hch@lst.de \ --cc=jcm@redhat.com \ --cc=jmattson@google.com \ --cc=joao.m.martins@oracle.com \ --cc=john.haxby@oracle.com \ --cc=jsteckli@amazon.de \ --cc=juerg.haefliger@canonical.com \ --cc=juergh@gmail.com \ --cc=kanth.ghatraju@oracle.com \ --cc=keescook@google.com \ --cc=kernel-hardening@lists.openwall.com \ --cc=khalid.aziz@oracle.com \ --cc=kirill.shutemov@linux.intel.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=liran.alon@oracle.com \ --cc=pradeep.vincent@oracle.com \ --cc=steven.sistare@oracle.com \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ --cc=tycho@docker.com \ --cc=tycho@tycho.ws \ --cc=tyhicks@canonical.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: linkBe 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.