From: Russell Currey <hidden> Date: 2019-10-30 07:45:05
v4 cover letter: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198268.html
v3 cover letter: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198023.html
Changes since v4:
[1/5]: Addressed review comments from Michael Ellerman (thanks!)
[4/5]: make ARCH_HAS_STRICT_MODULE_RWX depend on
ARCH_HAS_STRICT_KERNEL_RWX to simplify things and avoid
STRICT_MODULE_RWX being *on by default* in cases where
STRICT_KERNEL_RWX is *unavailable*
[5/5]: split skiroot_defconfig changes out into its own patch
The whole Kconfig situation is really weird and confusing, I believe the
correct resolution is to change arch/Kconfig but the consequences are so
minor that I don't think it's worth it, especially given that I expect
powerpc to have mandatory strict RWX Soon(tm).
Russell Currey (5):
powerpc/mm: Implement set_memory() routines
powerpc/kprobes: Mark newly allocated probes as RO
powerpc/mm/ptdump: debugfs handler for W+X checks at runtime
powerpc: Set ARCH_HAS_STRICT_MODULE_RWX
powerpc/configs: Enable STRICT_MODULE_RWX in skiroot_defconfig
arch/powerpc/Kconfig | 2 +
arch/powerpc/Kconfig.debug | 6 +-
arch/powerpc/configs/skiroot_defconfig | 1 +
arch/powerpc/include/asm/set_memory.h | 32 +++++++++++
arch/powerpc/kernel/kprobes.c | 3 +
arch/powerpc/mm/Makefile | 1 +
arch/powerpc/mm/pageattr.c | 77 ++++++++++++++++++++++++++
arch/powerpc/mm/ptdump/ptdump.c | 21 ++++++-
8 files changed, 140 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/include/asm/set_memory.h
create mode 100644 arch/powerpc/mm/pageattr.c
--
2.23.0
From: Russell Currey <hidden> Date: 2019-10-30 07:33:56
With CONFIG_STRICT_KERNEL_RWX=y and CONFIG_KPROBES=y, there will be one
W+X page at boot by default. This can be tested with
CONFIG_PPC_PTDUMP=y and CONFIG_PPC_DEBUG_WX=y set, and checking the
kernel log during boot.
powerpc doesn't implement its own alloc() for kprobes like other
architectures do, but we couldn't immediately mark RO anyway since we do
a memcpy to the page we allocate later. After that, nothing should be
allowed to modify the page, and write permissions are removed well
before the kprobe is armed.
Thus mark newly allocated probes as read-only once it's safe to do so.
Signed-off-by: Russell Currey <redacted>
---
arch/powerpc/kernel/kprobes.c | 3 +++
1 file changed, 3 insertions(+)
From: Daniel Axtens <hidden> Date: 2019-11-01 14:57:54
Russell Currey [off-list ref] writes:
With CONFIG_STRICT_KERNEL_RWX=y and CONFIG_KPROBES=y, there will be one
W+X page at boot by default. This can be tested with
CONFIG_PPC_PTDUMP=y and CONFIG_PPC_DEBUG_WX=y set, and checking the
kernel log during boot.
powerpc doesn't implement its own alloc() for kprobes like other
architectures do, but we couldn't immediately mark RO anyway since we do
a memcpy to the page we allocate later. After that, nothing should be
allowed to modify the page, and write permissions are removed well
before the kprobe is armed.
Thus mark newly allocated probes as read-only once it's safe to do so.
So if I've got the flow right here:
register[_aggr]_kprobe
-> prepare_kprobe
-> arch_prepare_kprobe
perform memcpy
mark as readonly, after which no-one touches writes to the memory
which all seems right to me.
I have been trying to check if optprobes need special handling: it looks
like the buffer for them lives in kernel text, not dynamically allocated
memory, so it should be protected by the usual Strict RWX protections
without special treatment here.
So lgtm.
Reviewed-by: Daniel Axtens <redacted>
Regards,
Daniel
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2019-11-02 10:47:32
Russell Currey [off-list ref] writes:
quoted hunk
With CONFIG_STRICT_KERNEL_RWX=y and CONFIG_KPROBES=y, there will be one
W+X page at boot by default. This can be tested with
CONFIG_PPC_PTDUMP=y and CONFIG_PPC_DEBUG_WX=y set, and checking the
kernel log during boot.
powerpc doesn't implement its own alloc() for kprobes like other
architectures do, but we couldn't immediately mark RO anyway since we do
a memcpy to the page we allocate later. After that, nothing should be
allowed to modify the page, and write permissions are removed well
before the kprobe is armed.
Thus mark newly allocated probes as read-only once it's safe to do so.
Signed-off-by: Russell Currey <redacted>
---
arch/powerpc/kernel/kprobes.c | 3 +++
1 file changed, 3 insertions(+)
@@ -131,6 +132,8 @@ int arch_prepare_kprobe(struct kprobe *p)(unsignedlong)p->ainsn.insn+sizeof(kprobe_opcode_t));}+set_memory_ro((unsignedlong)p->ainsn.insn,1);+
That comes from:
p->ainsn.insn = get_insn_slot();
Which ends up in __get_insn_slot() I think. And that looks very much
like it's going to hand out multiple slots per page, which isn't going
to work because you've just marked the whole page RO.
So I would expect this to crash on the 2nd kprobe that's installed. Have
you tested it somehow?
I think this code should just use patch_instruction() rather than
memcpy().
cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2019-12-05 23:49:17
Michael Ellerman [off-list ref] writes:
Russell Currey [off-list ref] writes:
quoted
With CONFIG_STRICT_KERNEL_RWX=y and CONFIG_KPROBES=y, there will be one
W+X page at boot by default. This can be tested with
CONFIG_PPC_PTDUMP=y and CONFIG_PPC_DEBUG_WX=y set, and checking the
kernel log during boot.
powerpc doesn't implement its own alloc() for kprobes like other
architectures do, but we couldn't immediately mark RO anyway since we do
a memcpy to the page we allocate later. After that, nothing should be
allowed to modify the page, and write permissions are removed well
before the kprobe is armed.
Thus mark newly allocated probes as read-only once it's safe to do so.
Signed-off-by: Russell Currey <redacted>
---
arch/powerpc/kernel/kprobes.c | 3 +++
1 file changed, 3 insertions(+)
@@ -131,6 +132,8 @@ int arch_prepare_kprobe(struct kprobe *p)(unsignedlong)p->ainsn.insn+sizeof(kprobe_opcode_t));}+set_memory_ro((unsignedlong)p->ainsn.insn,1);+
That comes from:
p->ainsn.insn = get_insn_slot();
Which ends up in __get_insn_slot() I think. And that looks very much
like it's going to hand out multiple slots per page, which isn't going
to work because you've just marked the whole page RO.
So I would expect this to crash on the 2nd kprobe that's installed. Have
you tested it somehow?
I'm not sure if this is the issue I was talking about, but it doesn't
survive ftracetest:
[ 1139.576047] ------------[ cut here ]------------
[ 1139.576322] kernel BUG at mm/memory.c:2036!
cpu 0x1f: Vector: 700 (Program Check) at [c000001fd6c675d0]
pc: c00000000035d018: apply_to_page_range+0x318/0x610
lr: c0000000000900bc: change_memory_attr+0x4c/0x70
sp: c000001fd6c67860
msr: 9000000000029033
current = 0xc000001fa4a47880
paca = 0xc000001ffffe5c80 irqmask: 0x03 irq_happened: 0x01
pid = 7168, comm = ftracetest
kernel BUG at mm/memory.c:2036!
Linux version 5.4.0-gcc-8.2.0-11694-gf1f9aa266811 (michael@Raptor-2.ozlabs.ibm.com) (gcc version 8.2.0 (crosstool-NG 1.24.0-rc1.16-9627a04)) #1384 SMP Thu Dec 5 22:11:09 AEDT 2019
enter ? for help
[c000001fd6c67940] c0000000000900bc change_memory_attr+0x4c/0x70
[c000001fd6c67970] c000000000053c48 arch_prepare_kprobe+0xb8/0x120
[c000001fd6c679e0] c00000000022f718 register_kprobe+0x608/0x790
[c000001fd6c67a40] c00000000022fc50 register_kretprobe+0x230/0x350
[c000001fd6c67a80] c0000000002849b4 __register_trace_kprobe+0xf4/0x1a0
[c000001fd6c67af0] c000000000285b18 trace_kprobe_create+0x738/0xf70
[c000001fd6c67c30] c000000000286378 create_or_delete_trace_kprobe+0x28/0x70
[c000001fd6c67c50] c00000000025f024 trace_run_command+0xc4/0xe0
[c000001fd6c67ca0] c00000000025f128 trace_parse_run_command+0xe8/0x230
[c000001fd6c67d40] c0000000002845d0 probes_write+0x20/0x40
[c000001fd6c67d60] c0000000003eef4c __vfs_write+0x3c/0x70
[c000001fd6c67d80] c0000000003f26a0 vfs_write+0xd0/0x200
[c000001fd6c67dd0] c0000000003f2a3c ksys_write+0x7c/0x140
[c000001fd6c67e20] c00000000000b9e0 system_call+0x5c/0x68
--- Exception: c01 (System Call) at 00007fff8f06e420
SP (7ffff93d6830) is in userspace
1f:mon> client_loop: send disconnect: Broken pipe
Sorry I didn't get any more info on the crash, I lost the console and
then some CI bot stole the machine 8)
You should be able to reproduce just by running ftracetest.
cheers
From: Russell Currey <hidden> Date: 2019-12-12 06:45:42
On Fri, 2019-12-06 at 10:47 +1100, Michael Ellerman wrote:
Michael Ellerman [off-list ref] writes:
quoted
Russell Currey [off-list ref] writes:
quoted
With CONFIG_STRICT_KERNEL_RWX=y and CONFIG_KPROBES=y, there will
be one
W+X page at boot by default. This can be tested with
CONFIG_PPC_PTDUMP=y and CONFIG_PPC_DEBUG_WX=y set, and checking
the
kernel log during boot.
powerpc doesn't implement its own alloc() for kprobes like other
architectures do, but we couldn't immediately mark RO anyway
since we do
a memcpy to the page we allocate later. After that, nothing
should be
allowed to modify the page, and write permissions are removed
well
before the kprobe is armed.
Thus mark newly allocated probes as read-only once it's safe to
do so.
Signed-off-by: Russell Currey <redacted>
---
arch/powerpc/kernel/kprobes.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/kprobes.c
b/arch/powerpc/kernel/kprobes.c
index 2d27ec4feee4..2610496de7c7 100644
That comes from:
p->ainsn.insn = get_insn_slot();
Which ends up in __get_insn_slot() I think. And that looks very
much
like it's going to hand out multiple slots per page, which isn't
going
to work because you've just marked the whole page RO.
So I would expect this to crash on the 2nd kprobe that's installed.
Have
you tested it somehow?
I'm not sure if this is the issue I was talking about, but it doesn't
survive ftracetest:
[ 1139.576047] ------------[ cut here ]------------
[ 1139.576322] kernel BUG at mm/memory.c:2036!
cpu 0x1f: Vector: 700 (Program Check) at [c000001fd6c675d0]
pc: c00000000035d018: apply_to_page_range+0x318/0x610
lr: c0000000000900bc: change_memory_attr+0x4c/0x70
sp: c000001fd6c67860
msr: 9000000000029033
current = 0xc000001fa4a47880
paca = 0xc000001ffffe5c80 irqmask: 0x03 irq_happened: 0x01
pid = 7168, comm = ftracetest
kernel BUG at mm/memory.c:2036!
Linux version 5.4.0-gcc-8.2.0-11694-gf1f9aa266811 (
michael@Raptor-2.ozlabs.ibm.com) (gcc version 8.2.0 (crosstool-NG
1.24.0-rc1.16-9627a04)) #1384 SMP Thu Dec 5 22:11:09 AEDT 2019
enter ? for help
[c000001fd6c67940] c0000000000900bc change_memory_attr+0x4c/0x70
[c000001fd6c67970] c000000000053c48 arch_prepare_kprobe+0xb8/0x120
[c000001fd6c679e0] c00000000022f718 register_kprobe+0x608/0x790
[c000001fd6c67a40] c00000000022fc50 register_kretprobe+0x230/0x350
[c000001fd6c67a80] c0000000002849b4
__register_trace_kprobe+0xf4/0x1a0
[c000001fd6c67af0] c000000000285b18 trace_kprobe_create+0x738/0xf70
[c000001fd6c67c30] c000000000286378
create_or_delete_trace_kprobe+0x28/0x70
[c000001fd6c67c50] c00000000025f024 trace_run_command+0xc4/0xe0
[c000001fd6c67ca0] c00000000025f128
trace_parse_run_command+0xe8/0x230
[c000001fd6c67d40] c0000000002845d0 probes_write+0x20/0x40
[c000001fd6c67d60] c0000000003eef4c __vfs_write+0x3c/0x70
[c000001fd6c67d80] c0000000003f26a0 vfs_write+0xd0/0x200
[c000001fd6c67dd0] c0000000003f2a3c ksys_write+0x7c/0x140
[c000001fd6c67e20] c00000000000b9e0 system_call+0x5c/0x68
--- Exception: c01 (System Call) at 00007fff8f06e420
SP (7ffff93d6830) is in userspace
1f:mon> client_loop: send disconnect: Broken pipe
Sorry I didn't get any more info on the crash, I lost the console and
then some CI bot stole the machine 8)
You should be able to reproduce just by running ftracetest.
The test that blew it up was test.d/kprobe/probepoint.tc for the
record. It goes away when replacing the memcpy with a
patch_instruction().
From: Russell Currey <hidden> Date: 2019-10-30 07:36:03
The set_memory_{ro/rw/nx/x}() functions are required for STRICT_MODULE_RWX,
and are generally useful primitives to have. This implementation is
designed to be completely generic across powerpc's many MMUs.
It's possible that this could be optimised to be faster for specific
MMUs, but the focus is on having a generic and safe implementation for
now.
This implementation does not handle cases where the caller is attempting
to change the mapping of the page it is executing from, or if another
CPU is concurrently using the page being altered. These cases likely
shouldn't happen, but a more complex implementation with MMU-specific code
could safely handle them, so that is left as a TODO for now.
Signed-off-by: Russell Currey <redacted>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/set_memory.h | 32 +++++++++++
arch/powerpc/mm/Makefile | 1 +
arch/powerpc/mm/pageattr.c | 77 +++++++++++++++++++++++++++
4 files changed, 111 insertions(+)
create mode 100644 arch/powerpc/include/asm/set_memory.h
create mode 100644 arch/powerpc/mm/pageattr.c
@@ -0,0 +1,77 @@+// SPDX-License-Identifier: GPL-2.0++/*+*MMU-genericset_memoryimplementationforpowerpc+*+*Copyright2019,IBMCorporation.+*/++#include<linux/mm.h>+#include<linux/set_memory.h>++#include<asm/mmu.h>+#include<asm/page.h>+#include<asm/pgtable.h>+++/*+*Updatestheattributesofapageinthreesteps:+*+*1.invalidatethepagetableentry+*2.flushtheTLB+*3.installthenewentrywiththeupdatedattributes+*+*Thisisunsafeifthecallerisattemptingtochangethemappingofthe+*pageitisexecutingfrom,orifanotherCPUisconcurrentlyusingthe+*pagebeingaltered.+*+*TODOmaketheimplementationresistanttothis.+*/+staticintchange_page_attr(pte_t*ptep,unsignedlongaddr,void*data)+{+intaction=*((int*)data);+pte_tpte_val;+intret=0;++spin_lock(&init_mm.page_table_lock);++// invalidate the PTE so it's safe to modify+pte_val=ptep_get_and_clear(&init_mm,addr,ptep);+flush_tlb_kernel_range(addr,addr+PAGE_SIZE);++// modify the PTE bits as desired, then apply+switch(action){+caseSET_MEMORY_RO:+pte_val=pte_wrprotect(pte_val);+break;+caseSET_MEMORY_RW:+pte_val=pte_mkwrite(pte_val);+break;+caseSET_MEMORY_NX:+pte_val=pte_exprotect(pte_val);+break;+caseSET_MEMORY_X:+pte_val=pte_mkexec(pte_val);+break;+default:+WARN_ON(true);+ret=-EINVAL;+gotoout;+}++set_pte_at(&init_mm,addr,ptep,pte_val);+out:+spin_unlock(&init_mm.page_table_lock);+returnret;+}++intchange_memory_attr(unsignedlongaddr,intnumpages,intaction)+{+unsignedlongstart=ALIGN_DOWN(addr,PAGE_SIZE);+unsignedlongsize=numpages*PAGE_SIZE;++if(!numpages)+return0;++returnapply_to_page_range(&init_mm,start,size,change_page_attr,&action);+}
The set_memory_{ro/rw/nx/x}() functions are required for STRICT_MODULE_RWX,
and are generally useful primitives to have. This implementation is
designed to be completely generic across powerpc's many MMUs.
It's possible that this could be optimised to be faster for specific
MMUs, but the focus is on having a generic and safe implementation for
now.
This implementation does not handle cases where the caller is attempting
to change the mapping of the page it is executing from, or if another
CPU is concurrently using the page being altered. These cases likely
shouldn't happen, but a more complex implementation with MMU-specific code
could safely handle them, so that is left as a TODO for now.
Signed-off-by: Russell Currey <redacted>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/set_memory.h | 32 +++++++++++
arch/powerpc/mm/Makefile | 1 +
arch/powerpc/mm/pageattr.c | 77 +++++++++++++++++++++++++++
4 files changed, 111 insertions(+)
create mode 100644 arch/powerpc/include/asm/set_memory.h
create mode 100644 arch/powerpc/mm/pageattr.c
I don't like too much the way you are making this function more complex
and less readable with local var, goto, etc ...
You could just keep the v4 version of change_page_attr(), rename it
__change_page_attr(), then add:
static int change_page_attr(pte_t *ptep, unsigned long addr, void *data)
{
int ret;
spin_lock(&init_mm.page_table_lock);
ret = __change_page_attr(ptep, addr, data);
spin_unlock(&init_mm.page_table_lock);
return ret;
}
Christophe
+{
+ int action = *((int *)data);
+ pte_t pte_val;
+ int ret = 0;
+
+ spin_lock(&init_mm.page_table_lock);
+
+ // invalidate the PTE so it's safe to modify
+ pte_val = ptep_get_and_clear(&init_mm, addr, ptep);
+ flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+
+ // modify the PTE bits as desired, then apply
+ switch (action) {
+ case SET_MEMORY_RO:
+ pte_val = pte_wrprotect(pte_val);
+ break;
+ case SET_MEMORY_RW:
+ pte_val = pte_mkwrite(pte_val);
+ break;
+ case SET_MEMORY_NX:
+ pte_val = pte_exprotect(pte_val);
+ break;
+ case SET_MEMORY_X:
+ pte_val = pte_mkexec(pte_val);
+ break;
+ default:
+ WARN_ON(true);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ set_pte_at(&init_mm, addr, ptep, pte_val);
+out:
+ spin_unlock(&init_mm.page_table_lock);
+ return ret;
+}
+
+int change_memory_attr(unsigned long addr, int numpages, int action)
+{
+ unsigned long start = ALIGN_DOWN(addr, PAGE_SIZE);
+ unsigned long size = numpages * PAGE_SIZE;
+
+ if (!numpages)
+ return 0;
+
+ return apply_to_page_range(&init_mm, start, size, change_page_attr, &action);
+}
From: Russell Currey <hidden> Date: 2019-10-30 07:38:28
Very rudimentary, just
echo 1 > [debugfs]/check_wx_pages
and check the kernel log. Useful for testing strict module RWX.
Updated the Kconfig entry to reflect this.
Also fixed a typo.
Signed-off-by: Russell Currey <redacted>
---
arch/powerpc/Kconfig.debug | 6 ++++--
arch/powerpc/mm/ptdump/ptdump.c | 21 ++++++++++++++++++++-
2 files changed, 24 insertions(+), 3 deletions(-)
@@ -370,7 +370,7 @@ config PPC_PTDUMPIfyouareunsure,sayN.configPPC_DEBUG_WX-bool"Warn on W+X mappings at boot"+bool"Warn on W+X mappings at boot & enable manual checks at runtime"depends onPPC_PTDUMPhelpGenerateawarningifanyW+Xmappingsarefoundatboot.
From: Russell Currey <hidden> Date: 2019-10-30 07:40:20
skiroot_defconfig is the only powerpc defconfig with STRICT_KERNEL_RWX
enabled, and if you want memory protection for kernel text you'd want it
for modules too, so enable STRICT_MODULE_RWX there.
Signed-off-by: Russell Currey <redacted>
---
arch/powerpc/configs/skiroot_defconfig | 1 +
1 file changed, 1 insertion(+)
From: Joel Stanley <joel@jms.id.au> Date: 2019-10-31 00:08:27
On Wed, 30 Oct 2019 at 07:31, Russell Currey [off-list ref] wrote:
skiroot_defconfig is the only powerpc defconfig with STRICT_KERNEL_RWX
enabled, and if you want memory protection for kernel text you'd want it
for modules too, so enable STRICT_MODULE_RWX there.
Signed-off-by: Russell Currey <redacted>
From: Russell Currey <hidden> Date: 2019-10-30 07:42:44
To enable strict module RWX on powerpc, set:
CONFIG_STRICT_MODULE_RWX=y
You should also have CONFIG_STRICT_KERNEL_RWX=y set to have any real
security benefit.
ARCH_HAS_STRICT_MODULE_RWX is set to require ARCH_HAS_STRICT_KERNEL_RWX.
This is due to a quirk in arch/Kconfig and arch/powerpc/Kconfig that
makes STRICT_MODULE_RWX *on by default* in configurations where
STRICT_KERNEL_RWX is *unavailable*.
Since this doesn't make much sense, and module RWX without kernel RWX
doesn't make much sense, having the same dependencies as kernel RWX
works around this problem.
Signed-off-by: Russell Currey <redacted>
---
This means that Daniel's test on book3e64 is pretty useless since we've
gone from being unable to turn it *off* to being unable to turn it *on*.
I think this is the right course of action for now.
arch/powerpc/Kconfig | 1 +
1 file changed, 1 insertion(+)
v4 cover letter: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198268.html
v3 cover letter: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198023.html
Changes since v4:
[1/5]: Addressed review comments from Michael Ellerman (thanks!)
[4/5]: make ARCH_HAS_STRICT_MODULE_RWX depend on
ARCH_HAS_STRICT_KERNEL_RWX to simplify things and avoid
STRICT_MODULE_RWX being *on by default* in cases where
STRICT_KERNEL_RWX is *unavailable*
[5/5]: split skiroot_defconfig changes out into its own patch
The whole Kconfig situation is really weird and confusing, I believe the
correct resolution is to change arch/Kconfig but the consequences are so
minor that I don't think it's worth it, especially given that I expect
powerpc to have mandatory strict RWX Soon(tm).
I'm not such strict RWX can be made mandatory due to the impact it has
on some subarches:
- On the 8xx, unless all areas are 8Mbytes aligned, there is a
significant overhead on TLB misses. And Aligning everthing to 8M is a
waste of RAM which is not acceptable on systems having very few RAM.
- On hash book3s32, we are able to map the kernel BATs. With a few
alignment constraints, we are able to provide STRICT_KERNEL_RWX. But we
are unable to provide exec protection on page granularity. Only on
256Mbytes segments. So for modules, we have to have the vmspace X. It is
also not possible to have a kernel area RO. Only user areas can be made RO.
Christophe
On Wed, Oct 30, 2019 at 09:58:19AM +0100, Christophe Leroy wrote:
Le 30/10/2019 à 08:31, Russell Currey a écrit :
quoted
v4 cover letter: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198268.html
v3 cover letter: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198023.html
Changes since v4:
[1/5]: Addressed review comments from Michael Ellerman (thanks!)
[4/5]: make ARCH_HAS_STRICT_MODULE_RWX depend on
ARCH_HAS_STRICT_KERNEL_RWX to simplify things and avoid
STRICT_MODULE_RWX being *on by default* in cases where
STRICT_KERNEL_RWX is *unavailable*
[5/5]: split skiroot_defconfig changes out into its own patch
The whole Kconfig situation is really weird and confusing, I believe the
correct resolution is to change arch/Kconfig but the consequences are so
minor that I don't think it's worth it, especially given that I expect
powerpc to have mandatory strict RWX Soon(tm).
I'm not such strict RWX can be made mandatory due to the impact it has on
some subarches:
- On the 8xx, unless all areas are 8Mbytes aligned, there is a significant
overhead on TLB misses. And Aligning everthing to 8M is a waste of RAM which
is not acceptable on systems having very few RAM.
- On hash book3s32, we are able to map the kernel BATs. With a few alignment
constraints, we are able to provide STRICT_KERNEL_RWX. But we are unable to
provide exec protection on page granularity. Only on 256Mbytes segments. So
for modules, we have to have the vmspace X. It is also not possible to have
a kernel area RO. Only user areas can be made RO.
As I understand it, the idea was for it to be mandatory (or at least
default-on) only for the subarches where it wasn't totally insane to
accomplish. :) (I'm not familiar with all the details on the subarchs,
but it sounded like the more modern systems would be the targets for
this?)
--
Kees Cook
On Wed, Oct 30, 2019 at 09:58:19AM +0100, Christophe Leroy wrote:
quoted
Le 30/10/2019 à 08:31, Russell Currey a écrit :
quoted
v4 cover letter: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198268.html
v3 cover letter: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198023.html
Changes since v4:
[1/5]: Addressed review comments from Michael Ellerman (thanks!)
[4/5]: make ARCH_HAS_STRICT_MODULE_RWX depend on
ARCH_HAS_STRICT_KERNEL_RWX to simplify things and avoid
STRICT_MODULE_RWX being *on by default* in cases where
STRICT_KERNEL_RWX is *unavailable*
[5/5]: split skiroot_defconfig changes out into its own patch
The whole Kconfig situation is really weird and confusing, I believe the
correct resolution is to change arch/Kconfig but the consequences are so
minor that I don't think it's worth it, especially given that I expect
powerpc to have mandatory strict RWX Soon(tm).
I'm not such strict RWX can be made mandatory due to the impact it has on
some subarches:
- On the 8xx, unless all areas are 8Mbytes aligned, there is a significant
overhead on TLB misses. And Aligning everthing to 8M is a waste of RAM which
is not acceptable on systems having very few RAM.
- On hash book3s32, we are able to map the kernel BATs. With a few alignment
constraints, we are able to provide STRICT_KERNEL_RWX. But we are unable to
provide exec protection on page granularity. Only on 256Mbytes segments. So
for modules, we have to have the vmspace X. It is also not possible to have
a kernel area RO. Only user areas can be made RO.
As I understand it, the idea was for it to be mandatory (or at least
default-on) only for the subarches where it wasn't totally insane to
accomplish. :) (I'm not familiar with all the details on the subarchs,
but it sounded like the more modern systems would be the targets for
this?)
Yes I guess so.
I was just afraid by "I expect powerpc to have mandatory strict RWX"
By the way, we have an open issue #223 namely 'Make strict kernel RWX
the default on 64-bit', so no worry as 32-bit is aside for now.
Christophe
From: Russell Currey <hidden> Date: 2019-10-31 00:11:33
On Wed, 2019-10-30 at 09:58 +0100, Christophe Leroy wrote:
Le 30/10/2019 à 08:31, Russell Currey a écrit :
quoted
v4 cover letter:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198268.html
v3 cover letter:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198023.html
Changes since v4:
[1/5]: Addressed review comments from Michael Ellerman
(thanks!)
[4/5]: make ARCH_HAS_STRICT_MODULE_RWX depend on
ARCH_HAS_STRICT_KERNEL_RWX to simplify things and avoid
STRICT_MODULE_RWX being *on by default* in cases where
STRICT_KERNEL_RWX is *unavailable*
[5/5]: split skiroot_defconfig changes out into its own patch
The whole Kconfig situation is really weird and confusing, I
believe the
correct resolution is to change arch/Kconfig but the consequences
are so
minor that I don't think it's worth it, especially given that I
expect
powerpc to have mandatory strict RWX Soon(tm).
I'm not such strict RWX can be made mandatory due to the impact it
has
on some subarches:
- On the 8xx, unless all areas are 8Mbytes aligned, there is a
significant overhead on TLB misses. And Aligning everthing to 8M is
a
waste of RAM which is not acceptable on systems having very few RAM.
- On hash book3s32, we are able to map the kernel BATs. With a few
alignment constraints, we are able to provide STRICT_KERNEL_RWX. But
we
are unable to provide exec protection on page granularity. Only on
256Mbytes segments. So for modules, we have to have the vmspace X. It
is
also not possible to have a kernel area RO. Only user areas can be
made RO.
Yes, sorry, this was thoughtless from me, since in my mind I was just
thinking about the platforms I primarily work on (book3s64).