CONFIG_GRKERNSEC_PAX_KERNEXEC

[supermike]

hello pax people, is there any way this option together with CONFIG_SMP could be a problem? I've had more than one machine completely lock up and may have tracked it down to these 2 options being enabled together. used clean kernel w/1.9.9g and also wolk4.0s-rc7 w/same result...
thanks!

[PaX Team]

hello pax people, is there any way this option together with CONFIG_SMP could be a problem? I've had more than one machine completely lock up and may have tracked it down to these 2 options being enabled together. used clean kernel w/1.9.9g and also wolk4.0s-rc7 w/same result...

since this is not the first time i've seen this reported, a few questions:

1. what's your gcc/ld version (you should be using gcc 2.95.3 or 3.2.2+ and ld 2.13+)? also, are there any special optimizations on (like -O3)?

2. does it happen on true SMP systems or UP w/ CONFIG_SMP on as well?

3. can you get any details of the lockup (in what function in particular)?

4. can you try it with the plain PaX patch?

5. have you got CONFIG_HIGHMEM64G enabled in the kernel config?

i'd like to track it down but for now i could neither reproduce it myself nor gather enough debug info from others (what i have so far indicates some weird memory corruption).

[supermike]

1) gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)
GNU ld version 2.11.93.0.2 20020207
damn it was easier using the redhat packages ;( do i really need to use those vers.
-02

2) only tried on true smp systems

3) no logs or anything produced, sorry but no time to debug as this hw is going production now

5) nope but CONFIG_HIGHMEM4G is

[PaX Team]

1) gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)
GNU ld version 2.11.93.0.2 20020207
damn it was easier using the redhat packages ;( do i really need to use those vers.

well, the versions i mentioned are known to produce a working kernel (both on my UP P3 and spender's SMP Athlon at least). in fact, i'm wondering how that ld was able to link the kernel image at all as i had reports that such old versions had complained and produced something really broken (truncated vmlinux file). anyway, thanks for the info.

[PaX Team]

last night i took another look at the KERNEXEC code and eventually found some bad code of mine that could cause all these problems. the fix is in the PaX tree already (arch/i386/kernel/traps.c), give it a try if you want to. one thing that i'd like to ask is whether you have booted with mem=nopentium or had CPUs that don't support PSE (these are the conditions to trigger this bug)?

[supermike]

hi, sorry i've just revisited this now and saw your question...
i've tried the new traps.c as included in the wolk patches with no luck here.
also, nope to using the mem option and to no pse support.

another possibly related item is a single xeon i have that won't boot with some pax option(s) (haven't had time to narrow down which ones).
will forward you an email on that...