/usr/src/linux-3.9.9-hardened/mm/slob.c: In function ‘slob_free_pages’: /usr/src/linux-3.9.9-hardened/mm/slob.c:213:2: error: implicit declaration of function ‘reset_page_mapcount’ [-Werror=implicit-function-declaration] Hardened patches use an outdated function name: 3.9.9/4420_grsecurity-2.9.1-3.9.9-201307050017.patch:+ reset_page_mapcount(sp); 3.9.9/4420_grsecurity-2.9.1-3.9.9-201307050017.patch:+ reset_page_mapcount(sp); Workaround: sed -i 's/reset_page_mapcount/page_mapcount_reset/' /usr/src/linux-3.9.9-hardened/mm/slob.c
yes, that's the correct fix but note that we stopped supporting 3.9 some time ago already. also SLOB has its own problems under USERCOPY (or maybe even without it, i forget now), i would advise against using it unless you can help us figure out the breakage :).
(In reply to PaX Team from comment #1) > yes, that's the correct fix but note that we stopped supporting 3.9 some > time ago already. I don't actually remember a time when Hardened had a grsecurity-supported kernel as latest stable. :) So supported or not, the fix should probably be in Gentoo. > also SLOB has its own problems under USERCOPY (or maybe > even without it, i forget now), i would advise against using it unless you > can help us figure out the breakage :). That's fine, I only use this configuration for a minimal KEXEC kernel that's used for anti-forensic RAM wipe (via memtest).
(In reply to Maxim Kammerer from comment #2) > (In reply to PaX Team from comment #1) > > yes, that's the correct fix but note that we stopped supporting 3.9 some > > time ago already. > > I don't actually remember a time when Hardened had a grsecurity-supported > kernel as latest stable. :) So supported or not, the fix should probably be > in Gentoo. 'we' above meant spender and me, not the hardened gentoo folks. that said, they already know that we're moving faster than gentoo's stabilization pace so there's some extra burden on them when they don't switch with us and i'm sure they'll handle this. > That's fine, I only use this configuration for a minimal KEXEC kernel that's > used for anti-forensic RAM wipe (via memtest). interesting, this is actually something i could support under SANITIZE if you're content with clearing only memory that the kernel allocators knew about (i.e., device specific memory, reserved ranges such as the kernel's own image, etc would not be cleared).
(In reply to PaX Team from comment #3) > 'we' above meant spender and me, not the hardened gentoo folks. Sure, that's what I meant above. The report was meant mainly for Anthony, I added you because I had no idea whether latest grsecurity/PaX patches still had the incorrectly named function. > interesting, this is actually something i could support under SANITIZE if > you're content with clearing only memory that the kernel allocators knew > about (i.e., device specific memory, reserved ranges such as the kernel's > own image, etc would not be cleared). That would be fantastic, because memtest is extremely primitive, and e.g. doesn't touch HIGHMEM (so you're limited to a bit less than 3G on 32-bit x86, with 1G/3G user/kernel memory split): https://bugzilla.kernel.org/show_bug.cgi?id=42630 Userspace solutions are, however, even worse, because it is nearly impossible to keep the kernel well-behaving once you approach memory exhaustion. It crashes, busy loops, etc. I did try, though: https://github.com/mkdesu/liberte/blob/0feeb59/src/usr/local/src/memwipe.c
For the records, slob + pax has another issue which I doubt has been resolved: see bug #349837
This is fixed in current stable (3.11.2).
