From: Michael Ellerman <mpe@ellerman.id.au> To: Christophe Leroy <christophe.leroy@csgroup.eu>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org> Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v4 14/45] powerpc/32s: Don't warn when mapping RO data ROX. Date: Mon, 25 May 2020 15:40:06 +1000 [thread overview] Message-ID: <87eer8fu89.fsf@mpe.ellerman.id.au> (raw) In-Reply-To: <6499f8eeb2a36330e5c9fc1cee9a79374875bd54.1589866984.git.christophe.leroy@csgroup.eu> Christophe Leroy <christophe.leroy@csgroup.eu> writes: > Mapping RO data as ROX is not an issue since that data > cannot be modified to introduce an exploit. Being pedantic: it is still an issue, in that it means there's more targets for a code-reuse attack. But given the entire kernel text is also available for code-reuse attacks, the RO data is unlikely to contain any useful sequences that aren't also in the kernel text. > PPC64 accepts to have RO data mapped ROX, as a trade off > between kernel size and strictness of protection. > > On PPC32, kernel size is even more critical as amount of > memory is usually small. Yep, I think it's a reasonable trade off to make. cheers > Depending on the number of available IBATs, the last IBATs > might overflow the end of text. Only warn if it crosses > the end of RO data. > > Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> > --- > arch/powerpc/mm/book3s32/mmu.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c > index 39ba53ca5bb5..a9b2cbc74797 100644 > --- a/arch/powerpc/mm/book3s32/mmu.c > +++ b/arch/powerpc/mm/book3s32/mmu.c > @@ -187,6 +187,7 @@ void mmu_mark_initmem_nx(void) > int i; > unsigned long base = (unsigned long)_stext - PAGE_OFFSET; > unsigned long top = (unsigned long)_etext - PAGE_OFFSET; > + unsigned long border = (unsigned long)__init_begin - PAGE_OFFSET; > unsigned long size; > > if (IS_ENABLED(CONFIG_PPC_BOOK3S_601)) > @@ -201,9 +202,10 @@ void mmu_mark_initmem_nx(void) > size = block_size(base, top); > size = max(size, 128UL << 10); > if ((top - base) > size) { > - if (strict_kernel_rwx_enabled()) > - pr_warn("Kernel _etext not properly aligned\n"); > size <<= 1; > + if (strict_kernel_rwx_enabled() && base + size > border) > + pr_warn("Some RW data is getting mapped X. " > + "Adjust CONFIG_DATA_SHIFT to avoid that.\n"); > } > setibat(i++, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT); > base += size; > -- > 2.25.0
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au> To: Christophe Leroy <christophe.leroy@csgroup.eu>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org> Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 14/45] powerpc/32s: Don't warn when mapping RO data ROX. Date: Mon, 25 May 2020 15:40:06 +1000 [thread overview] Message-ID: <87eer8fu89.fsf@mpe.ellerman.id.au> (raw) In-Reply-To: <6499f8eeb2a36330e5c9fc1cee9a79374875bd54.1589866984.git.christophe.leroy@csgroup.eu> Christophe Leroy <christophe.leroy@csgroup.eu> writes: > Mapping RO data as ROX is not an issue since that data > cannot be modified to introduce an exploit. Being pedantic: it is still an issue, in that it means there's more targets for a code-reuse attack. But given the entire kernel text is also available for code-reuse attacks, the RO data is unlikely to contain any useful sequences that aren't also in the kernel text. > PPC64 accepts to have RO data mapped ROX, as a trade off > between kernel size and strictness of protection. > > On PPC32, kernel size is even more critical as amount of > memory is usually small. Yep, I think it's a reasonable trade off to make. cheers > Depending on the number of available IBATs, the last IBATs > might overflow the end of text. Only warn if it crosses > the end of RO data. > > Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> > --- > arch/powerpc/mm/book3s32/mmu.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c > index 39ba53ca5bb5..a9b2cbc74797 100644 > --- a/arch/powerpc/mm/book3s32/mmu.c > +++ b/arch/powerpc/mm/book3s32/mmu.c > @@ -187,6 +187,7 @@ void mmu_mark_initmem_nx(void) > int i; > unsigned long base = (unsigned long)_stext - PAGE_OFFSET; > unsigned long top = (unsigned long)_etext - PAGE_OFFSET; > + unsigned long border = (unsigned long)__init_begin - PAGE_OFFSET; > unsigned long size; > > if (IS_ENABLED(CONFIG_PPC_BOOK3S_601)) > @@ -201,9 +202,10 @@ void mmu_mark_initmem_nx(void) > size = block_size(base, top); > size = max(size, 128UL << 10); > if ((top - base) > size) { > - if (strict_kernel_rwx_enabled()) > - pr_warn("Kernel _etext not properly aligned\n"); > size <<= 1; > + if (strict_kernel_rwx_enabled() && base + size > border) > + pr_warn("Some RW data is getting mapped X. " > + "Adjust CONFIG_DATA_SHIFT to avoid that.\n"); > } > setibat(i++, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT); > base += size; > -- > 2.25.0
next prev parent reply other threads:[~2020-05-25 5:39 UTC|newest] Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-19 5:48 [PATCH v4 00/45] Use hugepages to map kernel mem on 8xx Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-19 5:48 ` [PATCH v4 01/45] powerpc/kasan: Fix error detection on memory allocation Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-19 5:48 ` [PATCH v4 02/45] powerpc/kasan: Fix issues by lowering KASAN_SHADOW_END Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-19 5:48 ` [PATCH v4 03/45] powerpc/kasan: Fix shadow pages allocation failure Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-19 5:48 ` [PATCH v4 04/45] powerpc/kasan: Remove unnecessary page table locking Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-19 5:48 ` [PATCH v4 05/45] powerpc/kasan: Refactor update of early shadow mappings Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-19 5:48 ` [PATCH v4 06/45] powerpc/kasan: Declare kasan_init_region() weak Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-19 5:48 ` [PATCH v4 07/45] powerpc/ptdump: Limit size of flags text to 1/2 chars on PPC32 Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-25 5:15 ` Michael Ellerman 2020-05-25 5:15 ` Michael Ellerman 2020-05-25 11:06 ` Christophe Leroy 2020-05-25 11:06 ` Christophe Leroy 2020-05-26 12:53 ` Michael Ellerman 2020-05-26 12:53 ` Michael Ellerman 2020-05-19 5:48 ` [PATCH v4 08/45] powerpc/ptdump: Reorder flags Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-19 5:48 ` [PATCH v4 09/45] powerpc/ptdump: Add _PAGE_COHERENT flag Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-19 5:48 ` [PATCH v4 10/45] powerpc/ptdump: Display size of BATs Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-19 5:48 ` [PATCH v4 11/45] powerpc/ptdump: Standardise display of BAT flags Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-19 5:48 ` [PATCH v4 12/45] powerpc/ptdump: Properly handle non standard page size Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-19 5:48 ` [PATCH v4 13/45] powerpc/ptdump: Handle hugepd at PGD level Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-19 5:48 ` [PATCH v4 14/45] powerpc/32s: Don't warn when mapping RO data ROX Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-25 5:40 ` Michael Ellerman [this message] 2020-05-25 5:40 ` Michael Ellerman 2020-05-19 5:48 ` [PATCH v4 15/45] powerpc/mm: Allocate static page tables for fixmap Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-19 5:48 ` [PATCH v4 16/45] powerpc/mm: Fix conditions to perform MMU specific management by blocks on PPC32 Christophe Leroy 2020-05-19 5:48 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 17/45] powerpc/mm: PTE_ATOMIC_UPDATES is only for 40x Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 18/45] powerpc/mm: Refactor pte_update() on nohash/32 Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 19/45] powerpc/mm: Refactor pte_update() on book3s/32 Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 20/45] powerpc/mm: Standardise __ptep_test_and_clear_young() params between PPC32 and PPC64 Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 21/45] powerpc/mm: Standardise pte_update() prototype " Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 22/45] powerpc/mm: Create a dedicated pte_update() for 8xx Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 23/45] powerpc/mm: Reduce hugepd size for 8M hugepages on 8xx Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 24/45] powerpc/8xx: Drop CONFIG_8xx_COPYBACK option Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 25/45] powerpc/8xx: Prepare handlers for _PAGE_HUGE for 512k pages Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 26/45] powerpc/8xx: Manage 512k huge pages as standard pages Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 27/45] powerpc/8xx: Only 8M pages are hugepte pages now Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 28/45] powerpc/8xx: MM_SLICE is not needed anymore Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 29/45] powerpc/8xx: Move PPC_PIN_TLB options into 8xx Kconfig Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 30/45] powerpc/8xx: Add function to set pinned TLBs Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 31/45] powerpc/8xx: Don't set IMMR map anymore at boot Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 32/45] powerpc/8xx: Always pin TLBs at startup Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 33/45] powerpc/8xx: Drop special handling of Linear and IMMR mappings in I/D TLB handlers Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 34/45] powerpc/8xx: Remove now unused TLB miss functions Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 35/45] powerpc/8xx: Move DTLB perf handling closer Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 36/45] powerpc/mm: Don't be too strict with _etext alignment on PPC32 Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 37/45] powerpc/8xx: Refactor kernel address boundary comparison Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 38/45] powerpc/8xx: Add a function to early map kernel via huge pages Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 39/45] powerpc/8xx: Map IMMR with a huge page Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 40/45] powerpc/8xx: Map linear memory with huge pages Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 41/45] powerpc/8xx: Allow STRICT_KERNEL_RwX with pinned TLB Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 42/45] powerpc/8xx: Allow large TLBs with DEBUG_PAGEALLOC Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 43/45] powerpc/8xx: Implement dedicated kasan_init_region() Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 44/45] powerpc/32s: Allow mapping with BATs with DEBUG_PAGEALLOC Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-05-19 5:49 ` [PATCH v4 45/45] powerpc/32s: Implement dedicated kasan_init_region() Christophe Leroy 2020-05-19 5:49 ` Christophe Leroy 2020-06-09 5:28 ` [PATCH v4 00/45] Use hugepages to map kernel mem on 8xx Michael Ellerman
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=87eer8fu89.fsf@mpe.ellerman.id.au \ --to=mpe@ellerman.id.au \ --cc=benh@kernel.crashing.org \ --cc=christophe.leroy@csgroup.eu \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=paulus@samba.org \ /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.