From: Mark Rutland <mark.rutland@arm.com> To: Tycho Andersen <tycho@docker.com> Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-hardening@lists.openwall.com, Marco Benatto <marco.antonio.780@gmail.com>, Juerg Haefliger <juerg.haefliger@canonical.com>, Juerg Haefliger <juerg.haefliger@hpe.com> Subject: Re: [kernel-hardening] [PATCH v5 07/10] arm64/mm: Don't flush the data cache if the page is unmapped by XPFO Date: Tue, 15 Aug 2017 10:39:01 +0100 [thread overview] Message-ID: <20170815093900.GA6090@leverpostej> (raw) In-Reply-To: <20170814202727.5jm5ndd3nzlwftfb@smitten> On Mon, Aug 14, 2017 at 02:27:27PM -0600, Tycho Andersen wrote: > Hi Mark, > > First, thanks for taking a look! > > On Sat, Aug 12, 2017 at 12:57:37PM +0100, Mark Rutland wrote: > > On Wed, Aug 09, 2017 at 02:07:52PM -0600, Tycho Andersen wrote: > > > From: Juerg Haefliger <juerg.haefliger@hpe.com> > > > > > > If the page is unmapped by XPFO, a data cache flush results in a fatal > > > page fault. So don't flush in that case. > > > > Do you have an example callchain where that happens? We might need to shuffle > > things around to cater for that case. > > Here's one from the other branch (i.e. xpfo_page_is_unmapped() is true): > > [ 15.487293] CPU: 2 PID: 1633 Comm: plymouth Not tainted 4.13.0-rc4-c2+ #242 > [ 15.487295] Hardware name: Hardkernel ODROID-C2 (DT) > [ 15.487297] Call trace: > [ 15.487313] [<ffff0000080884f0>] dump_backtrace+0x0/0x248 > [ 15.487317] [<ffff00000808878c>] show_stack+0x14/0x20 > [ 15.487324] [<ffff000008b3e1b8>] dump_stack+0x98/0xb8 > [ 15.487329] [<ffff000008098bb4>] sync_icache_aliases+0x84/0x98 > [ 15.487332] [<ffff000008098c74>] __sync_icache_dcache+0x64/0x88 > [ 15.487337] [<ffff0000081d4814>] alloc_set_pte+0x4ec/0x6b8 > [ 15.487342] [<ffff00000819d920>] filemap_map_pages+0x350/0x360 > [ 15.487344] [<ffff0000081d4ccc>] do_fault+0x28c/0x568 > [ 15.487347] [<ffff0000081d67a0>] __handle_mm_fault+0x410/0xd08 > [ 15.487350] [<ffff0000081d7164>] handle_mm_fault+0xcc/0x1a8 > [ 15.487352] [<ffff000008098580>] do_page_fault+0x270/0x380 > [ 15.487355] [<ffff00000808128c>] do_mem_abort+0x3c/0x98 > [ 15.487358] Exception stack(0xffff800061dabe20 to 0xffff800061dabf50) > [ 15.487362] be20: 0000000000000000 0000800062e19000 ffffffffffffffff 0000ffff8f64ddc8 > [ 15.487365] be40: ffff800061dabe80 ffff000008238810 ffff800061d80330 0000000000000018 > [ 15.487368] be60: ffffffffffffffff 0000ffff8f5ba958 ffff800061d803d0 ffff800067132e18 > [ 15.487370] be80: 0000000000000000 ffff800061d80d08 0000000000000000 0000000000000019 > [ 15.487373] bea0: 000000002bd3d0f0 0000000000000000 0000000000000019 ffff800067132e00 > [ 15.487376] bec0: 0000000000000000 0000ffff8f657220 0000000000000000 0000000000000000 > [ 15.487379] bee0: 8080808000000000 0000000000000000 0000000080808080 fefefeff6f6b6467 > [ 15.487381] bf00: 7f7f7f7f7f7f7f7f 000000002bd3fb40 0101010101010101 0000000000000020 > [ 15.487384] bf20: 00000000004072b0 00000000004072e0 0000000000000000 0000ffff8f6b2000 > [ 15.487386] bf40: 0000ffff8f66b190 0000ffff8f576380 > [ 15.487389] [<ffff000008082b74>] el0_da+0x20/0x24 > > > > @@ -30,7 +31,9 @@ void sync_icache_aliases(void *kaddr, unsigned long len) > > > unsigned long addr = (unsigned long)kaddr; > > > > > > if (icache_is_aliasing()) { > > > - __clean_dcache_area_pou(kaddr, len); > > > + /* Don't flush if the page is unmapped by XPFO */ > > > + if (!xpfo_page_is_unmapped(virt_to_page(kaddr))) > > > + __clean_dcache_area_pou(kaddr, len); > > > __flush_icache_all(); > > > } else { > > > flush_icache_range(addr, addr + len); > > > > I don't think this patch is correct. If data cache maintenance is required in > > the absence of XPFO, I don't see why it wouldn't be required in the presence of > > XPFO. > > Ok. I suppose we could do re-map like we do for dma; or is there some > re-arrangement of things you can see that would help? Creating a temporary mapping (which I guess you do for DMA) should work. We might be able to perform the maintenance before we unmap the linear map alias, but I guess this might not be possible if the that logic is too far removed from the PTE manipulation. > > On a more general note, in future it would be good to Cc the arm64 maintainers > > and the linux-arm-kernel mailing list for patches affecting arm64. > > Yes, I thought about doing that for the series, but since it has x86 patches > too, I didn't want to spam everyone :). I'll just add x86/arm lists to CC in > the patches in the future. If there's some better way, let me know. That sounds fine; thanks. Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com> To: Tycho Andersen <tycho@docker.com> Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-hardening@lists.openwall.com, Marco Benatto <marco.antonio.780@gmail.com>, Juerg Haefliger <juerg.haefliger@canonical.com>, Juerg Haefliger <juerg.haefliger@hpe.com> Subject: Re: [kernel-hardening] [PATCH v5 07/10] arm64/mm: Don't flush the data cache if the page is unmapped by XPFO Date: Tue, 15 Aug 2017 10:39:01 +0100 [thread overview] Message-ID: <20170815093900.GA6090@leverpostej> (raw) In-Reply-To: <20170814202727.5jm5ndd3nzlwftfb@smitten> On Mon, Aug 14, 2017 at 02:27:27PM -0600, Tycho Andersen wrote: > Hi Mark, > > First, thanks for taking a look! > > On Sat, Aug 12, 2017 at 12:57:37PM +0100, Mark Rutland wrote: > > On Wed, Aug 09, 2017 at 02:07:52PM -0600, Tycho Andersen wrote: > > > From: Juerg Haefliger <juerg.haefliger@hpe.com> > > > > > > If the page is unmapped by XPFO, a data cache flush results in a fatal > > > page fault. So don't flush in that case. > > > > Do you have an example callchain where that happens? We might need to shuffle > > things around to cater for that case. > > Here's one from the other branch (i.e. xpfo_page_is_unmapped() is true): > > [ 15.487293] CPU: 2 PID: 1633 Comm: plymouth Not tainted 4.13.0-rc4-c2+ #242 > [ 15.487295] Hardware name: Hardkernel ODROID-C2 (DT) > [ 15.487297] Call trace: > [ 15.487313] [<ffff0000080884f0>] dump_backtrace+0x0/0x248 > [ 15.487317] [<ffff00000808878c>] show_stack+0x14/0x20 > [ 15.487324] [<ffff000008b3e1b8>] dump_stack+0x98/0xb8 > [ 15.487329] [<ffff000008098bb4>] sync_icache_aliases+0x84/0x98 > [ 15.487332] [<ffff000008098c74>] __sync_icache_dcache+0x64/0x88 > [ 15.487337] [<ffff0000081d4814>] alloc_set_pte+0x4ec/0x6b8 > [ 15.487342] [<ffff00000819d920>] filemap_map_pages+0x350/0x360 > [ 15.487344] [<ffff0000081d4ccc>] do_fault+0x28c/0x568 > [ 15.487347] [<ffff0000081d67a0>] __handle_mm_fault+0x410/0xd08 > [ 15.487350] [<ffff0000081d7164>] handle_mm_fault+0xcc/0x1a8 > [ 15.487352] [<ffff000008098580>] do_page_fault+0x270/0x380 > [ 15.487355] [<ffff00000808128c>] do_mem_abort+0x3c/0x98 > [ 15.487358] Exception stack(0xffff800061dabe20 to 0xffff800061dabf50) > [ 15.487362] be20: 0000000000000000 0000800062e19000 ffffffffffffffff 0000ffff8f64ddc8 > [ 15.487365] be40: ffff800061dabe80 ffff000008238810 ffff800061d80330 0000000000000018 > [ 15.487368] be60: ffffffffffffffff 0000ffff8f5ba958 ffff800061d803d0 ffff800067132e18 > [ 15.487370] be80: 0000000000000000 ffff800061d80d08 0000000000000000 0000000000000019 > [ 15.487373] bea0: 000000002bd3d0f0 0000000000000000 0000000000000019 ffff800067132e00 > [ 15.487376] bec0: 0000000000000000 0000ffff8f657220 0000000000000000 0000000000000000 > [ 15.487379] bee0: 8080808000000000 0000000000000000 0000000080808080 fefefeff6f6b6467 > [ 15.487381] bf00: 7f7f7f7f7f7f7f7f 000000002bd3fb40 0101010101010101 0000000000000020 > [ 15.487384] bf20: 00000000004072b0 00000000004072e0 0000000000000000 0000ffff8f6b2000 > [ 15.487386] bf40: 0000ffff8f66b190 0000ffff8f576380 > [ 15.487389] [<ffff000008082b74>] el0_da+0x20/0x24 > > > > @@ -30,7 +31,9 @@ void sync_icache_aliases(void *kaddr, unsigned long len) > > > unsigned long addr = (unsigned long)kaddr; > > > > > > if (icache_is_aliasing()) { > > > - __clean_dcache_area_pou(kaddr, len); > > > + /* Don't flush if the page is unmapped by XPFO */ > > > + if (!xpfo_page_is_unmapped(virt_to_page(kaddr))) > > > + __clean_dcache_area_pou(kaddr, len); > > > __flush_icache_all(); > > > } else { > > > flush_icache_range(addr, addr + len); > > > > I don't think this patch is correct. If data cache maintenance is required in > > the absence of XPFO, I don't see why it wouldn't be required in the presence of > > XPFO. > > Ok. I suppose we could do re-map like we do for dma; or is there some > re-arrangement of things you can see that would help? Creating a temporary mapping (which I guess you do for DMA) should work. We might be able to perform the maintenance before we unmap the linear map alias, but I guess this might not be possible if the that logic is too far removed from the PTE manipulation. > > On a more general note, in future it would be good to Cc the arm64 maintainers > > and the linux-arm-kernel mailing list for patches affecting arm64. > > Yes, I thought about doing that for the series, but since it has x86 patches > too, I didn't want to spam everyone :). I'll just add x86/arm lists to CC in > the patches in the future. If there's some better way, let me know. That sounds fine; thanks. Mark. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-08-15 9:40 UTC|newest] Thread overview: 135+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-08-09 20:07 [PATCH v5 00/10] Add support for eXclusive Page Frame Ownership Tycho Andersen 2017-08-09 20:07 ` [kernel-hardening] " Tycho Andersen 2017-08-09 20:07 ` Tycho Andersen 2017-08-09 20:07 ` [PATCH v5 01/10] mm: add MAP_HUGETLB support to vm_mmap Tycho Andersen 2017-08-09 20:07 ` [kernel-hardening] " Tycho Andersen 2017-08-09 20:07 ` Tycho Andersen 2017-08-09 20:07 ` [PATCH v5 02/10] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO) Tycho Andersen 2017-08-09 20:07 ` [kernel-hardening] " Tycho Andersen 2017-08-09 20:07 ` Tycho Andersen 2017-08-14 18:51 ` Laura Abbott 2017-08-14 18:51 ` [kernel-hardening] " Laura Abbott 2017-08-14 18:51 ` Laura Abbott 2017-08-14 22:30 ` Laura Abbott 2017-08-14 22:30 ` [kernel-hardening] " Laura Abbott 2017-08-14 22:30 ` Laura Abbott 2017-08-15 3:47 ` Tycho Andersen 2017-08-15 3:47 ` [kernel-hardening] " Tycho Andersen 2017-08-15 3:47 ` Tycho Andersen 2017-08-15 3:51 ` Tycho Andersen 2017-08-15 3:51 ` [kernel-hardening] " Tycho Andersen 2017-08-15 3:51 ` Tycho Andersen 2017-08-09 20:07 ` [PATCH v5 03/10] swiotlb: Map the buffer if it was unmapped by XPFO Tycho Andersen 2017-08-09 20:07 ` [kernel-hardening] " Tycho Andersen 2017-08-09 20:07 ` Tycho Andersen 2017-08-10 13:01 ` Konrad Rzeszutek Wilk 2017-08-10 13:01 ` [kernel-hardening] " Konrad Rzeszutek Wilk 2017-08-10 13:01 ` Konrad Rzeszutek Wilk 2017-08-10 16:22 ` Tycho Andersen 2017-08-10 16:22 ` [kernel-hardening] " Tycho Andersen 2017-08-10 16:22 ` Tycho Andersen 2017-09-20 16:19 ` Dave Hansen 2017-09-20 16:19 ` [kernel-hardening] " Dave Hansen 2017-09-20 16:19 ` Dave Hansen 2017-09-20 22:47 ` Tycho Andersen 2017-09-20 22:47 ` [kernel-hardening] " Tycho Andersen 2017-09-20 22:47 ` Tycho Andersen 2017-09-20 23:25 ` Dave Hansen 2017-09-20 23:25 ` [kernel-hardening] " Dave Hansen 2017-09-20 23:25 ` Dave Hansen 2017-08-09 20:07 ` [PATCH v5 04/10] arm64: Add __flush_tlb_one() Tycho Andersen 2017-08-09 20:07 ` [kernel-hardening] " Tycho Andersen 2017-08-09 20:07 ` Tycho Andersen 2017-08-12 11:26 ` [kernel-hardening] " Mark Rutland 2017-08-12 11:26 ` Mark Rutland 2017-08-14 16:35 ` Tycho Andersen 2017-08-14 16:35 ` Tycho Andersen 2017-08-14 16:50 ` Mark Rutland 2017-08-14 16:50 ` Mark Rutland 2017-08-14 17:01 ` Tycho Andersen 2017-08-14 17:01 ` Tycho Andersen 2017-08-23 16:58 ` Tycho Andersen 2017-08-23 16:58 ` Tycho Andersen 2017-08-23 17:04 ` Mark Rutland 2017-08-23 17:04 ` Mark Rutland 2017-08-23 17:13 ` Tycho Andersen 2017-08-23 17:13 ` Tycho Andersen 2017-08-24 15:45 ` Mark Rutland 2017-08-24 15:45 ` Mark Rutland 2017-08-29 17:24 ` Tycho Andersen 2017-08-29 17:24 ` Tycho Andersen 2017-08-30 5:31 ` Juerg Haefliger 2017-08-30 16:47 ` Tycho Andersen 2017-08-30 16:47 ` Tycho Andersen 2017-08-31 9:43 ` Juerg Haefliger 2017-08-31 9:47 ` Mark Rutland 2017-08-31 9:47 ` Mark Rutland 2017-08-31 21:21 ` Tycho Andersen 2017-08-31 21:21 ` Tycho Andersen 2017-08-09 20:07 ` [PATCH v5 05/10] arm64/mm: Add support for XPFO Tycho Andersen 2017-08-09 20:07 ` [kernel-hardening] " Tycho Andersen 2017-08-09 20:07 ` Tycho Andersen 2017-08-11 18:01 ` [kernel-hardening] " Laura Abbott 2017-08-11 18:01 ` Laura Abbott 2017-08-11 20:19 ` Tycho Andersen 2017-08-11 20:19 ` Tycho Andersen 2017-08-09 20:07 ` [PATCH v5 06/10] arm64/mm: Disable section mappings if XPFO is enabled Tycho Andersen 2017-08-09 20:07 ` [kernel-hardening] " Tycho Andersen 2017-08-09 20:07 ` Tycho Andersen 2017-08-11 17:25 ` [kernel-hardening] " Laura Abbott 2017-08-11 17:25 ` Laura Abbott 2017-08-11 21:13 ` Tycho Andersen 2017-08-11 21:13 ` Tycho Andersen 2017-08-11 21:52 ` Tycho Andersen 2017-08-11 21:52 ` Tycho Andersen 2017-08-12 11:17 ` Mark Rutland 2017-08-12 11:17 ` Mark Rutland 2017-08-14 16:22 ` Tycho Andersen 2017-08-14 16:22 ` Tycho Andersen 2017-08-14 18:42 ` Laura Abbott 2017-08-14 18:42 ` Laura Abbott 2017-08-14 20:28 ` Tycho Andersen 2017-08-14 20:28 ` Tycho Andersen 2017-08-09 20:07 ` [PATCH v5 07/10] arm64/mm: Don't flush the data cache if the page is unmapped by XPFO Tycho Andersen 2017-08-09 20:07 ` [kernel-hardening] " Tycho Andersen 2017-08-09 20:07 ` Tycho Andersen 2017-08-12 11:57 ` [kernel-hardening] " Mark Rutland 2017-08-12 11:57 ` Mark Rutland 2017-08-14 16:54 ` Mark Rutland 2017-08-14 16:54 ` Mark Rutland 2017-08-14 20:27 ` Tycho Andersen 2017-08-14 20:27 ` Tycho Andersen 2017-08-15 9:39 ` Mark Rutland [this message] 2017-08-15 9:39 ` Mark Rutland 2017-08-09 20:07 ` [PATCH v5 08/10] arm64/mm: Add support for XPFO to swiotlb Tycho Andersen 2017-08-09 20:07 ` [kernel-hardening] " Tycho Andersen 2017-08-09 20:07 ` Tycho Andersen 2017-08-10 13:11 ` Konrad Rzeszutek Wilk 2017-08-10 13:11 ` [kernel-hardening] " Konrad Rzeszutek Wilk 2017-08-10 13:11 ` Konrad Rzeszutek Wilk 2017-08-10 16:35 ` Tycho Andersen 2017-08-10 16:35 ` [kernel-hardening] " Tycho Andersen 2017-08-10 16:35 ` Tycho Andersen 2017-08-09 20:07 ` [PATCH v5 09/10] mm: add a user_virt_to_phys symbol Tycho Andersen 2017-08-09 20:07 ` [kernel-hardening] " Tycho Andersen 2017-08-09 20:07 ` Tycho Andersen 2017-08-09 20:07 ` [PATCH v5 10/10] lkdtm: Add test for XPFO Tycho Andersen 2017-08-09 20:07 ` [kernel-hardening] " Tycho Andersen 2017-08-09 20:07 ` Tycho Andersen 2017-08-12 20:24 ` kbuild test robot 2017-08-12 20:24 ` [kernel-hardening] " kbuild test robot 2017-08-12 20:24 ` kbuild test robot 2017-08-14 16:21 ` Tycho Andersen 2017-08-14 16:21 ` [kernel-hardening] " Tycho Andersen 2017-08-14 16:21 ` Tycho Andersen 2017-08-12 21:05 ` kbuild test robot 2017-08-12 21:05 ` [kernel-hardening] " kbuild test robot 2017-08-12 21:05 ` kbuild test robot 2017-08-14 19:10 ` Kees Cook 2017-08-14 19:10 ` [kernel-hardening] " Kees Cook 2017-08-14 19:10 ` Kees Cook 2017-08-14 20:29 ` Tycho Andersen 2017-08-14 20:29 ` [kernel-hardening] " Tycho Andersen 2017-08-14 20:29 ` Tycho Andersen 2017-08-11 23:35 ` [kernel-hardening] [PATCH v5 00/10] Add support for eXclusive Page Frame Ownership Laura Abbott 2017-08-11 23:35 ` 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=20170815093900.GA6090@leverpostej \ --to=mark.rutland@arm.com \ --cc=juerg.haefliger@canonical.com \ --cc=juerg.haefliger@hpe.com \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=marco.antonio.780@gmail.com \ --cc=tycho@docker.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.