# problem making hardened-sources-2.6.39-r9

## Bones McCracker

What could be causing this?

make builds hardened-sources-2.6.39-r8 just fine.  I've gone back and done it again to be sure.

When I run make on hardened-sources-2.6.39-r9, after a clean 'make oldconfig', I get this (and I've repeated it, by unmerging it, scrapping the directory, re-emerging it and so on).

```
linux # make

scripts/kconfig/conf --silentoldconfig Kconfig

  CHK     include/linux/version.h

  CHK     include/generated/utsrelease.h

  CC      kernel/bounds.s

  GEN     include/generated/bounds.h

  CC      arch/x86/kernel/asm-offsets.s

In file included from include/linux/fs.h:393:0,

                 from include/linux/module.h:19,

                 from include/linux/crypto.h:21,

                 from arch/x86/kernel/asm-offsets.c:8:

include/linux/semaphore.h: In function ‘sema_init’:

include/linux/semaphore.h:35:17: error: assignment of read-only location ‘*sem’

In file included from /usr/src/linux-2.6.39-hardened-r9/arch/x86/include/asm/uaccess.h:11:0,

                 from include/linux/uaccess.h:5,

                 from include/linux/crypto.h:26,

                 from arch/x86/kernel/asm-offsets.c:8:

include/linux/sched.h: In function ‘thread_group_cputime_init’:

include/linux/sched.h:2579:2: error: assignment of read-only member ‘lock’

At top level:

cc1: warning: unrecognized command line option "-Wno-unused-but-set-variable"

make[1]: *** [arch/x86/kernel/asm-offsets.s] Error 1

make: *** [prepare0] Error 2
```

Is this a case of PEBKAC (and what is my problem) or should I submit a bug?

----------

## hermes_jr

Same here. And with hardened-2.6.39-r10 too. Anyone?

----------

## mv

They had the "great" idea to include an gcc plugin to make all structures constant (which actually does not increase security except for very obvious mistakes of kernel/module developers themselves - already the previous unnecessary adding of "const" caused a lot of unnecessary headache for important kernel modules like aufs2).

Obviously, they tested only with amd64, so currently x86 breaks. Probably they tested also not with all modules, so I guess chances are likely that (especially less popular) kernel modules break, too. Be prepared that practically all externel modules will also need patching. nvidia-compilers, for instance, will not compile unpatched. Probably many externel modules will need patching of kernel (and not only patching of the modules).

----------

## Bones McCracker

Okay, so this resulted from the upgrade to gcc-4.5.3?  Is that right?

Also, is the problem only with hardened-sources; I am not having the same issue on my non-hardened x86 machine (or is that difference simply due to me having different kernel options selected)?

Do you know if there is a Gentoo bug where these related problems are being collected?

Thanks.   :Smile: 

----------

## Bones McCracker

I have submitted a bug.

https://bugs.gentoo.org/show_bug.cgi?id=378731

----------

## mv

 *BoneKracker wrote:*   

> Okay, so this resulted from the upgrade to gcc-4.5.3?  Is that right?

 

No, it comes from the module which hardened-sources adds to gcc for kernel compilation. Of course, gcc must be new enough to support this module - I haven't checked since which gcc version this is the case. If it works with some versions of gcc then this fact is in a sense also a bug, meaning that the "protection" module is not applied as intended.

 *Quote:*   

> Also, is the problem only with hardened-sources

 

Yes.

 *Quote:*   

> I am not having the same issue on my non-hardened x86 machine (or is that difference simply due to me having different kernel options selected)?

 

For me, it worked on amd64, too, but also I have much less kernel options selected on my amd64 system.

----------

## cach0rr0

https://forums.gentoo.org/viewtopic-t-881333.html#6779878

----------

## Bones McCracker

 *mv wrote:*   

>  *BoneKracker wrote:*   Okay, so this resulted from the upgrade to gcc-4.5.3?  Is that right? 
> 
> No, it comes from the module which hardened-sources adds to gcc for kernel compilation. Of course, gcc must be new enough to support this module - I haven't checked since which gcc version this is the case. If it works with some versions of gcc then this fact is in a sense also a bug, meaning that the "protection" module is not applied as intended.
> 
>  *Quote:*   Also, is the problem only with hardened-sources 
> ...

 

Apparently (from discussion in my bug), the ebuild was not tested against gcc-4.5.3.

----------

## mv

The issue is now reported upstrea here. As I had announced, they did not even test all in-kernel modules, and a lot of modules will need patching.

[Rant] If at least, this lot of work would really increase security, but it does not: It only helps to verify the code quality which may be useful for the developer but is not useful for the user who just wants to compile the kernel in order to use it.[/Rant]

----------

## PaX Team

 *mv wrote:*   

> They had the "great" idea to include an gcc plugin to make all structures constant[...]

 the constification plugin makes ops structures (structs with function pointers and const members only) const, not 'all structures'.

 *Quote:*   

> [...](which actually does not increase security[...]

 there're many ways one could respond to this, but let's see what makes you come down from that high horse  :Wink: . the value of const function pointers is that they can no longer be targeted by arbitrary write bugs, so any reduction of their numbers is a net reduction of the kernel's attack surface. constifying function pointers is also beneficial for function pointer dereference protection schemes (think ret2libc/ROP attacks).

 *Quote:*   

> [...]already the previous unnecessary adding of "const" caused a lot of unnecessary headache for important kernel modules like aufs2).

 the constification that affects aufs2 is not only necessary but also a kernel policy, per Al Viro. if aufs wants to play by the kernel rules, its author had better work out a solution with the kernel developers.

 *Quote:*   

> Obviously, they tested only with amd64, so currently x86 breaks. Probably they tested also not with all modules, so I guess chances are likely that (especially less popular) kernel modules break, too.

 you're wrong on every single guess there. i tested the plugins (there's more than one, imagine that) with allmodconfig on both i386 and amd64. what caused the original breakage reported in this thread was due to the !SMP config which unfortunately allmodconfig doesn't test (and i'm actually surprised that someone still builds !SMP kernels these days) and there's also some more breakage with allyesconfig (already fixed in grsec).

 *Quote:*   

> Be prepared that practically all externel modules will also need patching. nvidia-compilers, for instance, will not compile unpatched. Probably many externel modules will need patching of kernel (and not only patching of the modules).

 so far i only ran into nvidia-drivers and virtulabox, for both of which i provided patches already. if you see more issues, you know where to report them. mindless ranting on a forum we don't read doesn't lead anywhere.

----------

## cach0rr0

 *PaX Team wrote:*   

> mindless ranting on a forum we don't read

 

the obvious solution there is to become a regular poster here


(that is, of course, meant in a playful/joking tone, I think a small fraction of the hardened-sources stuff we post on f.g.o would interest upstream, though it does happen on occasion; but the bigger point - welcome! And thanks for the work on these patches, lets me sleep 5 hours a night instead of 3. I have 'em pushed out to every server I actually care about)

----------

## Bones McCracker

 *PaX Team wrote:*   

> and i'm actually surprised that someone still builds !SMP kernels these days

 

I have hardened-sources installed on a uniprocessor Pentium-III machine that I use as a firewall/router.  Is there a reason, other than this bug, that I would want "CONFIG_SMP=y"?

Here are the configuration changes that automatically propagate from setting "CONFIG_SMP=y":

+CONFIG_X86_32_SMP=y

+CONFIG_X86_HT=y

-CONFIG_BROKEN_ON_SMP=y

+CONFIG_GENERIC_PENDING_IRQ=y

-CONFIG_TINY_RCU=y

+CONFIG_TREE_RCU=y

+CONFIG_RCU_FANOUT=32

+CONFIG_USE_GENERIC_SMP_HELPERS=y

+CONFIG_STOP_MACHINE=y

+CONFIG_MUTEX_SPIN_ON_OWNER=y

-CONFIG_NR_CPUS=1

+CONFIG_NR_CPUS=8

+CONFIG_SCHED_MC=y

-CONFIG_X86_UP_APIC=y

+CONFIG_X86_IO_APIC=y

-CONFIG_NEED_PER_CPU_KM=y

+CONFIG_ARCH_SUPPORTS_MSI=y

+CONFIG_HT_IRQ=y

+CONFIG_RPS=y

+CONFIG_RFS_ACCEL=y

+CONFIG_XPS=y

+CONFIG_RCU_CPU_STALL_DETECTOR=y

+CONFIG_RCU_CPU_STALL_TIMEOUT=60

+CONFIG_RCU_CPU_STALL_DETECTOR_RUNNABLE=y

+CONFIG_CPU_RMAP=y

The resulting kernel is 140 KiB (6.4%) larger and undoubtedly allocating memory that is never used and performing operations that are unnecessary.  This isn't the end of the world, but on a machine that has been carefully optimized to function well with limited resources (such as a firewall/router or a NAS), it is a perturbation.

----------

## mv

 *PaX Team wrote:*   

> but let's see what makes you come down from that high horse 

 

Yes, I am sorry - I was a bit aggressive since I had currently almost no time but had to spend half a day to make aufs2 and nvidia-drivers work with the new patches on my amd64, only to realize that it did not compile on my x86 anyway and that I will probably need to fix further modules like ltmodem.

 *Quote:*   

> the value of const function pointers is that they can no longer be targeted by arbitrary write bugs

 

How that? Does declaring them "const" make them move to some part of the memory where they cannot be changed, in principle? I doubt that this is the case since the aufs2 author has also written a patch where he is able to modify them (using some pointer casting tricks). So it only prevents from accidental access by kernel code - which you can exclude by compiling once with this plugin.

 *Quote:*   

> the constification that affects aufs2 is not only necessary but also a kernel policy, per Al Viro.

 

If it is a kernel policy then why doesn't the kernel declare it const?

 *Quote:*   

> if aufs wants to play by the kernel rules, its author had better work out a solution with the kernel developers.

 

AFAIK, the kernel developers rejected to even review any union type fs, because "nobody needs it" (even Valeries less intrusive attempts led to nothing). So I am not surprised that there are contradictions if there is some kernel policy which is undocumented and not reflected in the code, but I am also not surprised if this happens to many kernel modules which are not officially included.

 *Quote:*   

> what caused the original breakage reported in this thread was due to the !SMP config

 

Might be. All my three x86 systems are !SMP.

 *Quote:*   

> mindless ranting on a forum we don't read doesn't lead anywhere.

 

Of course not. I just wanted to explain the situation to the OP (and was admittedly too aggressive when doing this...).Last edited by mv on Tue Aug 16, 2011 9:29 am; edited 3 times in total

----------

## mv

 *BoneKracker wrote:*   

> I have hardened-sources installed on a uniprocessor Pentium-III machine that I use as a firewall/router.  Is there a reason, other than this bug, that I would want "CONFIG_SMP=y"?

 

No. Probably it will just slow down your system, so as soon as hardened-sources is fixed, I suggest to return to !SMP.

----------

## Bones McCracker

hardened-sources-2.6.39-r{9,10,11,12) all fail because of this same error.  I think we should be getting a fix soon.  I'm just going to mask them rather than make such dramatic reconfiguration of my kernel as a temporary work-around and have to track and undo the changes later.

```
# /etc/portage/package.mask

=sys-kernel/hardened-sources-2.6.39-r9

=sys-kernel/hardened-sources-2.6.39-r10

=sys-kernel/hardened-sources-2.6.39-r11

=sys-kernel/hardened-sources-2.6.39-r12
```

----------

## blueness

 *BoneKracker wrote:*   

> hardened-sources-2.6.39-r{9,10,11,12) all fail because of this same error.  I think we should be getting a fix soon.  I'm just going to mask them rather than make such dramatic reconfiguration of my kernel as a temporary work-around and have to track and undo the changes later.
> 
> ```
> # /etc/portage/package.mask
> 
> ...

 

I just stabilized -r8 which is not susceptible to this problem.  Use that for now, I'm getting a better idea what's causing this but I've had difficulties debugging because I haven't hit it.

If people want, post your kernel config files to the bug so I can better reproduce.

----------

## KutuluMike

 *blueness wrote:*   

> 
> 
> I just stabilized -r8 which is not susceptible to this problem.  Use that for now, I'm getting a better idea what's causing this but I've had difficulties debugging because I haven't hit it.
> 
> If people want, post your kernel config files to the bug so I can better reproduce.
> ...

 

Here's one .config file that is currently broken. The hardware is a single-core Pentium 4, so x86: http://pastebin.com/71DGBybP

----------

## Bones McCracker

 *blueness wrote:*   

> If people want, post your kernel config files to the bug so I can better reproduce.

 

I have posted by -r12 config to the bug.  Thanks.

----------

## PaX Team

 *BoneKracker wrote:*   

>  *PaX Team wrote:*   and i'm actually surprised that someone still builds !SMP kernels these days 
> 
> I have hardened-sources installed on a uniprocessor Pentium-III machine that I use as a firewall/router.  Is there a reason, other than this bug, that I would want "CONFIG_SMP=y"?

 obviously if all you care about is a single specific box then you're best off by customizing a kernel for it. but this approach doesn't scale well when you have to maintain many machines, where 'many' doesn't have to be enterprise/organization level, even in today's homes you'll likely find several computers (not to mention virtual machines) and it's a maintenance burden to have to keep customized kernels for each. the other reason for not using !SMP is because those machines are a dying breed, my P3 box is over a decade old now and frankly, it was years ago when i'd last turned it on  :Wink: .

 *Quote:*   

> +CONFIG_NR_CPUS=8
> 
> The resulting kernel is 140 KiB (6.4%) larger

 i wonder how much of that overhead would be reduced if you used a lower NR_CPUS value (but then the same kernel wouldn't work that well on the i7  :Wink: . *Quote:*   

>  and undoubtedly allocating memory that is never used and performing operations that are unnecessary.

 i hate to break the news here but if you use PaX then you're already wasting potentially MBs of memory on vmlinux itself (because ELF segments are padded to 2/4MB and there's the special module area on i386/KERNEXEC). so before you begin to worry about that 140k, you should reconsider using PaX then  :Wink: .

----------

## PaX Team

 *mv wrote:*   

> and that I will probably need to fix further modules like ltmodem.

 if you run into broken modules then report them in the gentoo bugzilla and cc me. i've fixed nvidia and virtualbox myself (to the extent that the latter can be fixed at all for PaX), if there's more, i'll take a look.

 *Quote:*   

> How that? Does declaring them "const" make them move to some part of the memory where they cannot be changed, in principle? I doubt that this is the case since the aufs2 author has also written a patch where he is able to modify them (using some pointer casting tricks). So it only prevents from accidental access by kernel code - which you can exclude by compiling once with this plugin.

 while C's 'const' is primarily compile time policy enforcement, on virtual memory based systems one can do better and make it also a runtime enforcement, at least for statically allocated variables. the exact details are somewhat complex, so for now just accept the fact that the toolchain (compiler/assembler/linker) and the kernel linker script all conspire to separate out all read-only data and put them into a specific area of memory that then can be made read-only in the page tables (this is what PaX//KERNEXEC does, among others). so you can cast away the 'const' all you want, at runtime your write attempt will still fail and cause an oops (for exceptional cases where such writes must be allowed one has to open up the kernel for temporary writing, see pax_open_kernel() and friends).

 *Quote:*   

> If it is a kernel policy then why doesn't the kernel declare it const?

 because well, it's the kernel devs we're talking about who aren't known for consistently enforcing kernel policies  :Wink: . e.g., take a look at scripts/checkpatch.pl and see how it tries to check that $struct_ops are all const in submitted patches. the fact that patches that violate such a policy are getting in means that noone really runs or cares about checkpatch, let alone actually reads the code. on the other hand putting such enforcement into the compiler means it cannot be circumvented (at least not without being explicit about it).

 *Quote:*   

> AFAIK, the kernel developers rejected to even review any union type fs, because "nobody needs it" (even Valeries less intrusive attempts led to nothing). So I am not surprised that there are contradictions if there is some kernel policy which is undocumented and not reflected in the code, but I am also not surprised if this happens to many kernel modules which are not officially included.

 Miklos Szeredi's overlay fs seems to be a recent effort, so i wouldn't write off such efforts just yet. as for the policies being undocumented/unenforced, that's life and we'll have to deal with it  :Wink: . for me it means compile time and runtime enforcement and there's more coming in the future  :Wink: .

----------

## Bones McCracker

 *PaX Team wrote:*   

>  *BoneKracker wrote:*    *PaX Team wrote:*   and i'm actually surprised that someone still builds !SMP kernels these days 
> 
> I have hardened-sources installed on a uniprocessor Pentium-III machine that I use as a firewall/router.  Is there a reason, other than this bug, that I would want "CONFIG_SMP=y"? obviously if all you care about is a single specific box then you're best off by customizing a kernel for it. but this approach doesn't scale well when you have to maintain many machines, where 'many' doesn't have to be enterprise/organization level, even in today's homes you'll likely find several computers (not to mention virtual machines) and it's a maintenance burden to have to keep customized kernels for each. the other reason for not using !SMP is because those machines are a dying breed, my P3 box is over a decade old now and frankly, it was years ago when i'd last turned it on .
> 
>  *Quote:*   +CONFIG_NR_CPUS=8
> ...

 

It seems to me that anybody who might want to use hardened gentoo for their routers is going to run into the same problem.  How many commercially-made routers and network appliances are multiprocessor devices?  Just casually writing off uniprocessor devices with a hand-wave seems like rationalizing the bug, to me.  Also, since when is it the Linux way to blow off support for aging hardware that is in extremely widespread use?

Also, losing a little RAM to PaX is not the same as wasting it by because of a bug.

If nobody wants to do anything about this for the 2.6.39 kernel and only wants to remediate 3.0, that I can understand.  But this is a bug, and it should be fixed, not rationalized away using the logic that someday it won't matter.

----------

## PaX Team

 *BoneKracker wrote:*   

> Just casually writing off uniprocessor devices with a hand-wave seems like rationalizing the bug, to me.  Also, since when is it the Linux way to blow off support for aging hardware that is in extremely widespread use?

 i didn't write them off, i said... well you can re-read it again, i'll stop wasting everyone's time on this. *Quote:*   

> Also, losing a little RAM to PaX is not the same as wasting it by because of a bug.

 and the difference is (besides being an order of magnitude bigger)...? psychological?  :Wink: 

 *Quote:*   

> If nobody wants to do anything about this for the 2.6.39 kernel and only wants to remediate 3.0, that I can understand.  But this is a bug, and it should be fixed, not rationalized away using the logic that someday it won't matter.

 the bug's been fixed already for all of .32/.39/3.0 (and no, it wasn't !SMP specific at all and at no time did i consider not fixing it. jeez, where do you guys get such ideas?).

----------

## Bones McCracker

I didn't realize it had been fixed.  The kernel I installed yesterday (2.6.39-r13) failed with the same CONFIG_SMP-related error.

As to the RAM, it's not just RAM, it's the whole principle of enabling whole branches of kernel features you don't need or want.  While this is fine for the generic desktop computing model, it's not appropriate for a good percentage of the devices I would expect people require the highest levels of hardening on.  Not to mention, it's contrary to basic security principles.

But since it has been fixed, no point blathering on about it. I see hardened-sources-3.0.3 now keyworded ~x86 and will give that a try.

Also, I appreciate your efforts and thank you.  Don't get me wrong in that regard.   :Smile: 

Edit: hardened-sources-3.0.3 seems to be building fine with "CONFIG_SMP=n".

----------

## mv

 *Quote:*   

> if you run into broken modules then report them in the gentoo bugzilla and cc me

 

This does not help for modules which are not in the main gentoo tree.

As expected, first try first hit: The (most current) martian-full-20100123 doesn't like that its code doesn't mean what it's supposed to mean by C Standard: It introduces a struct of function pointers by itself.

Of course, it is not difficult to add an __no_const, but anyway it costs time to debug and patch actually correct code...

 *PaX Team wrote:*   

> on virtual memory based systems one can do better and make it also a runtime enforcement, at least for statically allocated variables.

 

That one could implement it this way is clear. But does this really happen for the kernel code (on amd64 or x86 systems)?

 *Quote:*   

> so you can cast away the 'const' all you want

 

I was surprised that Okajima did not cast away the 'const': He used a much more tricky approach with unions and intermediate storage, I have not checked precisely. I guess he must have had a reason to do it this cumbersome way, although he shouldn't be able to succeed if the corresponding memory area is really protected by hardware.

 *Quote:*   

> Miklos Szeredi's overlay fs seems to be a recent effort

 

If something would have been included in 3.0 or at least 3.1, it might have had a chance. Now this seems already over. Moreover, it is completely unclear why some new code should be used if there is aufs which is working and tested since years: I did not consider details, but according to the critics of Valerie and Okajima it seems that the overlay fs is not less intrusive (or acts on a different layer) than aufs.

----------

## GenProm

Hi 

Just as a side note: I use the ck kernel and x64 bit, i think the ck sources are not hardened. But the problem of compile error with make also occours on my machine.... So not only hardened sources are affected.

----------

## PaX Team

 *mv wrote:*   

> This does not help for modules which are not in the main gentoo tree.

 but it's the same situation when upsream linux makes a change that breaks these modules (e.g., recent years saw several explicit ops constification patches). that's why out-of-tree modules should get into the kernel.

 *Quote:*   

> As expected, first try first hit: The (most current) martian-full-20100123 doesn't like that its code doesn't mean what it's supposed to mean by C Standard: It introduces a struct of function pointers by itself.

 there's no such thing as the 'C Standard'. there do exist at least the following entities:

C89 spec

C99 spec

any specific gcc svn revision

any specific clang svn revision

PaX constify plugin

etc

which one is the one true 'C Standard'?  :Wink: 

so the point is, the standard a given piece of code was written to is not very well defined (i bet there're very few people who even know what standard they're writing their code to, most just have vague ideas about the 'C Standard'). so it's no surprise that differences between all these 'standards' cause various failures and it's up to a programmer to resolve them. since the consitfy plugin was created with the explicit goal to detect attempts of modifying ops structures, obviously code that does so 'breaks'. and the correct fix is not adding __no_const by default, rather, you have to examine what the code is doing, whether it actually needs to modify said stuctures, etc and use __no_const only as a last resort. in this case there's no reason for runtime modification of these ops structs because they could be statically allocated and initialized with a little bit of code reorganization.

 *Quote:*   

> That one could implement it this way is clear. But does this really happen for the kernel code (on amd64 or x86 systems)?

 sure, the kernel creates page tables for its own code/read-only data (including those of the modules) that enforce low-level access rights. for vanilla kernels you need to enable DEBUG_RODATA and SET_MODULE_RONX, for PaX it's KERNEXEC and some things are enforced by default.

 *Quote:*   

> I was surprised that Okajima did not cast away the 'const': He used a much more tricky approach with unions and intermediate storage, I have not checked precisely. I guess he must have had a reason to do it this cumbersome way, although he shouldn't be able to succeed if the corresponding memory area is really protected by hardware.

 his approach doesn't work under PaX, he must use pax_open_kernel and friends.

----------

## mv

 *PaX Team wrote:*   

> there's no such thing as the 'C Standard'.

 

Well, there is C89 ANSI and several extensions thereof. Except in some rare corner cases where this is not possible, all extensions try to be downward compatible. There is no standard which makes things constant without the programmer specifying them to be so.   :Wink: 

 *Quote:*   

> Since the consitfy plugin was created with the explicit goal to detect attempts of modifying ops structures, obviously code that does so 'breaks'.

 

Unfortunately, contrary to other hardened patches, the user cannot switch off that feature in menuconfig if it breaks his applications/modules.

 *Quote:*   

> and the correct fix is not adding __no_const by default

 

Well, it is certainly a correct fix: Whether it can be done also in a better way by which even root has more difficulties to start an exploit is another question.

 *Quote:*   

> you have to examine what the code is doing, whether it actually needs to modify said stuctures, etc and use __no_const only as a last resort.

 

I have not written that code and do not want to spend time decreasing a theoretical danger of some unlikely attacking scenario. Even less do I want to examine what the closed source part is really doing and needing - perhaps the binary part needs some data structured (and writable) in this way. Sure, for you it is the "job" to look for such improvements, but I have another job and need a running kernel with working modules. It is the usual tradeoff between security and usability: Using a hardened kernel and having a theoretically safer system is fine, but if it hinders my actual work on the machine (which is not at all related with programming), I have to think about switching to a more usable system.   :Sad: 

 *Quote:*   

> sure, the kernel creates page tables for its own code/read-only data (including those of the modules) that enforce low-level access rights. for vanilla kernels you need to enable DEBUG_RODATA and SET_MODULE_RONX, for PaX it's KERNEXEC and some things are enforced by default.

 

Thanks. Unfortunately, I run only desktops, so setting KERNEXEC and droping X11 is an absolute no-go. And the other two depend on CONFIG_BROKEN which does not sound as if one should seriously activate these options...

----------

## blueness

 *BoneKracker wrote:*   

> I didn't realize it had been fixed.  The kernel I installed yesterday (2.6.39-r13) failed with the same CONFIG_SMP-related error.

 

I can confirm that its not fixed in -r9 through -r13, so I will not be marking any of those stable.  The only stable 2.6.39 kernel is -r8.  The next stable candidate will be coming from 3.0.3.

As I stated in the bug, unless there's a *very* good reason, I will not try to backport the fix to 2.6.39.  Anyone who needs to use a 2.6.39 kernel can use -r8.

----------

## Bones McCracker

Yes, I have no need for 2.6.29 and 3.0.3 is working fine for me.  Thank you, Anthony.

----------

## PaX Team

 *mv wrote:*   

> Well, there is C89 ANSI and several extensions thereof. Except in some rare corner cases where this is not possible, all extensions try to be downward compatible. There is no standard which makes things constant without the programmer specifying them to be so.   

 

there is now, it's called PaX  :Smile: . that's why it exists, it sets new standards in the world of security. you could have said 10 years ago that there was no standard to give random addresses back from mmap without the programmer explicitly asking for them, yet it's pretty standard now and most code that broke due to the randomization is fixed now and you would never argue that ASLR must be reverted instead, would you? the same thing will happen with constification (and it already did, observe the several patches that entered vanilla over the years that constify certain structures, this gcc plugin only accelerates this process).

 *Quote:*   

> Unfortunately, contrary to other hardened patches, the user cannot switch off that feature in menuconfig if it breaks his applications/modules.

 

there're many things in PaX that you cannot turn off that can break kernel code (e.g., some variables are made read-only even without KERNEXEC and the constification plugin so any code trying to write them would oops). also specifically for the plugin case, you can turn them off by overriding CONSTIFY_PLUGIN on the make command line you use to compile the kernel (or put it into EXTRA_CFLAGS).

 *Quote:*   

> Well, it is certainly a correct fix: Whether it can be done also in a better way by which even root has more difficulties to start an exploit is another question.

 

constifying function pointers is not a protection from root, it's a protection from kernel exploits, regardless of who runs them.

 *Quote:*   

> I have not written that code and do not want to spend time decreasing a theoretical danger of some unlikely attacking scenario.

 overwriting function pointers in an exploit is not theoretical danger but standard practice. and it's not unlikely, every kernel exploit you can find out there does so.

 *Quote:*   

> Even less do I want to examine what the closed source part is really doing and needing - perhaps the binary part needs some data structured (and writable) in this way.

 

you know the standard answer for using binary modules: if they break, you get to keep both pieces. seriously, you have to make up your mind eventually whether you actually care about the security of your system(s) or just want to have a feeling of security.

 *Quote:*   

> Sure, for you it is the "job" to look for such improvements, but I have another job and need a running kernel with working modules. It is the usual tradeoff between security and usability: Using a hardened kernel and having a theoretically safer system is fine, but if it hinders my actual work on the machine (which is not at all related with programming), I have to think about switching to a more usable system.   

 

i understand that you don't want to spend your own time on properly fixing things, but i still wanted to make it clear that __no_const is usually not the right fix because eventually people will find this discussion on google and they'd better have an idea about the problem and the solutions.

 *Quote:*   

> Thanks. Unfortunately, I run only desktops, so setting KERNEXEC and droping X11 is an absolute no-go.

 what doesn't work with KERNEXEC? the  catalyst  binary driver?

 *Quote:*   

>  And the other two depend on CONFIG_BROKEN which does not sound as if one should seriously activate these options...

 

they're marked BROKEN in PaX only, not in vanilla (as that's how i can make sure they cannot be selected as they directly conflict with KERNEXEC).

----------

## mv

 *PaX Team wrote:*   

> you know the standard answer for using binary modules: if they break, you get to keep both pieces. seriously, you have to make up your mind eventually whether you actually care about the security of your system(s) or just want to have a feeling of security.

 

There is no choice: I need these drivers occassionally and they are only available as binary.

 *Quote:*   

>  *Quote:*   Thanks. Unfortunately, I run only desktops, so setting KERNEXEC and droping X11 is an absolute no-go. what doesn't work with KERNEXEC? the  catalyst  binary driver?

 

 *Quote:*   

> 
> 
> ```
> Notable examples are the XFree86 4.x server, the java runtime and wine.
> ```
> ...

 

Besides that it is not realistic to exclude java and wine for a desktop system:

There was some option (I think it was KERNEXEC, but maybe I confuse it) which blocked nvidia-drivers from starting X (yes, I do not like binary nvidia either, but did never succeed to start nouveau without an immediate X-server segfault). However, I didn't recheck previous pax options recently, maybe nvidia-drivers has improved.

----------

## PaX Team

 *Quote:*   

> Notable examples are the XFree86 4.x server, the java runtime and wine.

 that's a description for the userland protections, not KERNEXEC. also i doubt you're still using xfree86  :Wink: .

 *Quote:*   

> Besides that it is not realistic to exclude java and wine for a desktop system:

 you don't need to. they're an emerge away and they'll work  :Smile: . there's no magic behind it either, PaX has always provided a method to disable certain protections on incompatible binaries and portage makes use of it (if some binaries are not marked properly, you know where to report gentoo bugs).

 *Quote:*   

> There was some option (I think it was KERNEXEC, but maybe I confuse it) which blocked nvidia-drivers from starting X

 i tested the latest nvidia driver myself and it works fine (with a few lines of patching needed to cooperate with USERCOPY and constification).

----------

## mv

 *PaX Team wrote:*   

> that's a description for the userland protections, not KERNEXEC.

 

It is the description of PAX_NOEXEC which you must first select to activate KERNEXEC, so it gives the impression that it applies to KERNEXEC as well.

 *Quote:*   

> also i doubt you're still using xfree86 .

 

Maybe you should point out in the description that this is not something which is inherited by xorg: I never played with this option, because the description of PAX_NOEXEC appeared to me as if any xserver (and even more programs like java and wine) would certainly break with it.

I activated now all options and had no problems so far. Thanks a lot   :Smile: 

 *Quote:*   

> (with a few lines of patching needed to cooperate with USERCOPY and constification).

 

Yes, now I remember: It was USERCOPY which had blocked nvidia (not KERNEXEC which I had never tried.)

----------

