after upgrading from previous version of hardened-sources (2.6.20-r10) and running make oldconfig I tried compiling the new kernel with make all, error as below. As a stopgap from the forums, I have enabled loadable kernal module support and the kernel compiles OK but this is something I wish to avoid as I see modules as a possible security risk as far as a malicious kernel module root kit being loaded if my system is compromised Reproducible: Always Steps to Reproduce: 1.cd /usr/src/linux 2.make oldconfig 3.make all Actual Results: GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD vmlinux drivers/built-in.o: In function `vesafb_probe': vesafb.c:(.init.text+0x1097): undefined reference to `module_alloc_exec' vesafb.c:(.init.text+0x1597): undefined reference to `module_free_exec' make: *** [vmlinux] Error 1 Expected Results: kernel to compile correctly kernel compiles correctly if loadable kernel module support is enabled, and fails every time if lkm support is not enabled.
Could you please attach your .config ?
Created attachment 134793 [details] .config thats fails
please note architecture is x86 not AMD64 as initially filed
I'm seeing it too.
(In reply to comment #4) > I'm seeing it too. Though that is w/ 2.6.23 with yesterday's snapshot.
it's my bug again, i reused a function in vesafb that isn't compiled for non-modular kernels, hence the link error. i'll have to think about this one, it's not that easy to fix (w/o lots of otherwise unnecessary code reorganization, that is). in the meantime you can enable module support or not use vesafb...
The third option is to stay at the previous kernel version, 2.6.20-r10. How does this compare with enabling kernel modularity for security? I too would prefer not to allow kernel modules on this hardened-kernel box.
(In reply to comment #7) > How does this compare with enabling kernel modularity for security? sorry if i'm about to burst your security bubble ;-), but module support had never anything to do with security, even if it was advertized as such. the thing is, the kernel's module loading mechanism is only one of the many ways to load and execute code in kernel context. sure, it's probably the only officially supported interface, but in real (and hence buggy) kernel software, it's never been the only one. if you disable module support for security reasons you're only preventing the run-of-the-mill type script kiddie from installing his rootkit (but then if he can get even that far you've got bigger system security issues to begin with), it won't prevent anyone with a decent kernel exploit to get around your module-less kernel 'security'. it's especially true for the 2.6 kernel series which is about the most (security) bug ridden open source kernels out there. in short, module support will become a security concern when kernel bugs become non-exploitable (at least for code execution purposes). that day has yet to come (and many people in the field think it's flat out impossible to achieve, i disagree with them but don't have the proof yet ;-).
In reply to comment 8, that's very interesting, and plausible to boot, but I fear it doesn't answer the question. Do I enable module loading to get to 2.6.22-r8, or shall I stay with 2.6.20-r10? I need to exercise my judgement, but it would be good to hear some advice. So module loading is only one route to compromising a system, but it is still there, and I assume it's better to plug each gap than to leave them open just because they haven't all been closed. How much better? That seems to be the question. For the moment, I think I'll stick to the older kernel version. Or does the newer one include enough security advances to outweigh the introduction of module loading? It's hard for mere mortals to find out what has improved in each kernel release.
(In reply to comment #9) > In reply to comment 8, that's very interesting, and plausible to boot, but I > fear it doesn't answer the question. Do I enable module loading to get to > 2.6.22-r8, or shall I stay with 2.6.20-r10? I need to exercise my judgement, > but it would be good to hear some advice. if you need 2.6.22+ for some specific reason and want PaX in it, you have to enable modules for now, until i fix it properly (it's not a 5 line change, else i would have done it already, and right now i got higher priority bugs to figure out, sorry). > So module loading is only one route to compromising a system it's one route to backdoor a system. if one can load modules, he must have compromised the system already. now compromising the system to the point to become able to load modules is equivalent to gaining root (or similar, modulo capabilities, etc) and that can be done either by exploiting some userland bug, or more professionally, a kernel bug. and this is the latter which also allows executing code at the kernel's privilege level, regardless of module support. > but it is still there, and I assume it's better to plug each gap than to > leave them open just because they haven't all been closed. How much better? > That seems to be the question. depends on what you assume of your potential attackers. if your concern is script kiddies with a rootkit they don't understand and hence can't fix when module support is missing from the kernel, then you'll be safe from them (well, safe from installing the kernel part of the rootkit). > It's hard for mere mortals to find out what has improved in each kernel release. it's probably of little help, but at times it's hard for me as well ;-).
Thank you for your clear description, pageexec. As far as I can see, I don't particularly need the latest kernel version on my gateway box, so I'll stick with my present one and await developments. I appreciate that few things in life are simple :-)
Reproducible in 2.6.23-r7, the latest version keyworded stable. Cross-referencing to the 2.6.23-r8 tracker.
My apologies, my last comment was erroneous in that 2.6.23-r7 has only been marked stable on amd64.
so i decided to go the easy way and fixed it by disabling the use of pmi under a non-modular KERNEXEC kernel. it's in the latest -test24 patch for 2.6.24.2. on another note, i hope the recent vmsplice exploit drove home my point about how irrelevant a non-modular kernel is for security ;-).
Created attachment 143817 [details, diff] patch for inclusion in 2.6.23
Fixed in 2.6.23-r8.
