| Summary: | sys-kernel/hardened-sources: CONFIG_GRKERNSEC_KMEM disables CONFIG_X86_MSR and breaks sys-power/powertop | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Nikoli <nikoli> |
| Component: | Hardened | Assignee: | Anthony Basile <blueness> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | pageexec, rene.rheaume, spender |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
It is straightforward to decouple kmem and msr with the following patch, but i'm not sure what the consequences would be. I'll pass the question by upstream. ' diff -Naur linux-3.11.8-hardened/arch/x86/Kconfig linux-3.11.8-hardened.orig/arch/x86/Kconfig --- linux-3.11.8-hardened/arch/x86/Kconfig 2013-11-26 11:07:49.023038486 -0500 +++ linux-3.11.8-hardened.orig/arch/x86/Kconfig 2013-11-17 13:50:01.792291860 -0500 @@ -1088,6 +1088,7 @@ config X86_MSR tristate "/dev/cpu/*/msr - Model-specific register support" + depends on !GRKERNSEC_KMEM ---help--- This device gives privileged processes access to the x86 Model-Specific Registers (MSRs). It is a character device with this is a preemptive measure until someone analyzes every single MSR and determines whether the ones capable of compromising the kernel are under proper access control. (In reply to PaX Team from comment #2) > this is a preemptive measure until someone analyzes every single MSR and > determines whether the ones capable of compromising the kernel are under > proper access control. I understand, but does it make sense to lump it in with GRKERNSEC_KMEM. Could we have an independant GRKERNSEC_MSR? (In reply to Anthony Basile from comment #3) > (In reply to PaX Team from comment #2) > > this is a preemptive measure until someone analyzes every single MSR and > > determines whether the ones capable of compromising the kernel are under > > proper access control. > > I understand, but does it make sense to lump it in with GRKERNSEC_KMEM. > Could we have an independant GRKERNSEC_MSR? @pipacs. It doesn't look like you did anything with this. Is it still an issue? (In reply to Anthony Basile from comment #4) > > I understand, but does it make sense to lump it in with GRKERNSEC_KMEM. > > Could we have an independant GRKERNSEC_MSR? > > @pipacs. It doesn't look like you did anything with this. Is it still an > issue? this is spender's call as this restriction is in grsec, not PaX per se ;). Unless you need access to /dev/mem, you can disable both DEVMEM and DEVKMEM. Is /dev/port still a thing? If not, that may be a workaround allowing you to turn off GRKERNSEC_KMEM. This has been my plan to get cpupower working on our servers. |
Until some 3.9.* version sys-kernel/hardened-sources did not have this dep: linux # grep X86_MSR ./arch/x86/Kconfig -A3 config X86_MSR tristate "/dev/cpu/*/msr - Model-specific register support" depends on !GRKERNSEC_KMEM ---help--- It was possible to protect /dev/kmem /dev/mem /dev/port and use powertop, but now it is not. It is still possible to protect (aka remove) /dev/kmem by disabling CONFIG_DEVKMEM and make /dev/mem read only with CONFIG_STRICT_DEVMEM=y, but it seems not possible to disable /dev/port and enable additional checks added when CONFIG_GRKERNSEC_KMEM is defined. I need powertop, but i would like to use as secure kernel as possible.