CC arch/ia64/kernel/asm-offsets.s In file included from include/linux/device.h:23:0, from include/linux/rtc.h:111, from include/linux/efi.h:19, from /usr/src/linux-2.6.32-hardened-r89/arch/ia64/include/asm/sal.h:40, from /usr/src/linux-2.6.32-hardened-r89/arch/ia64/include/asm/mca.h:20, from arch/ia64/kernel/asm-offsets.c:17: include/linux/module.h: In function _within_module_range_: include/linux/module.h:405:2: error: implicit declaration of function _ktla_ktva_ make[1]: *** [arch/ia64/kernel/asm-offsets.s] Error 1 Portage 2.2.0_alpha84 (hardened/linux/ia64/server, gcc-4.5.3, glibc-2.13-r4, 2.6.32-hardened-r78 ia64) ================================================================= System Settings ================================================================= System uname: Linux-2.6.32-hardened-r78-ia64-31-with-gentoo-2.0.3 Timestamp of tree: Tue, 31 Jan 2012 11:45:01 +0000 app-shells/bash: 4.1_p9 dev-lang/python: 2.7.2-r3, 3.2.2 dev-util/cmake: 2.8.6-r4 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.0.3 sys-apps/openrc: 0.8.3-r1 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.68 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.21.1-r1 sys-devel/gcc: 4.5.3-r1 sys-devel/gcc-config: 1.4.1-r1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r1 sys-kernel/linux-headers: 2.6.39 (virtual/os-headers) sys-libs/glibc: 2.13-r4 Repositories: gentoo sunrise local Installed sets: ACCEPT_KEYWORDS="ia64" ACCEPT_LICENSE="* -@EULA" CBUILD="ia64-unknown-linux-gnu" CFLAGS="-pipe -mtune=mckinley -O2" CHOST="ia64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-pipe -mtune=mckinley -O2" DISTDIR="/var/cache/portage/distfiles" EMERGE_DEFAULT_OPTS="--usepkg --buildpkg --binpkg-respect-use --with-bdeps y --keep-going" FEATURES="assume-digests binpkg-logs buildpkg distlocks ebuild-locks fixlafiles news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="" GENTOO_MIRRORS="http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://ftp.spline.inf.fu- berlin.de/mirrors/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://distfiles.gentoo.org" LANG="en_GB.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--hash-style=gnu" MAKEOPTS="-j3" PKGDIR="/var/cache/portage/packages" PORTAGE_COMPRESS="xz" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS=" --delete-excluded --include='/sci-libs/' --include='/sci-libs/gsl/' --exclude='/sci-l ibs/*/' --include='/x11-libs/' --include='/x11-misc/' --include='/x11-proto/' --exclude='/games*/' --exclude='/gnome*/' --exclu de='/gnustep*/' --exclude='/gpe*/' --exclude='/kde*/' --exclude='/lxde*/' --exclude='/rox*/' --exclude='/sci*/' --exclude='/x11*/' --exclude='/xf ce*/'" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/di stfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/cache/portage/gentoo" PORTDIR_OVERLAY="/var/cache/portage/layman/sunrise /var/cache/portage/local" [...] Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS_FLAGS ================================================================= Package Settings ================================================================= sys-kernel/hardened-sources-2.6.32-r89 was built with the following: USE="-build -deblob -symlink"
P.S: r87 had the same issue.
(In reply to comment #1) > P.S: r87 had the same issue. As does r83. r78 compiles and runs.
Please don't CC arch teams. Also, if you're going to paste the error message, then please leave in the filename - it's an important part of the message.
Hi Dennis, do you get the same problem with vanilla?
(In reply to comment #3) > Please don't CC arch teams. Also, if you're going to paste the error message, > then please leave in the filename - it's an important part of the message. I appear to have been a bit sleepy, sorry. (In reply to comment #4) > Hi Dennis, do you get the same problem with vanilla? I tried 2.6.32.55 and arch/ia64/kernel/asm-offsets.s compiles fine.
After grepping for those macros, I expect you run into the same problem on all arches except um, powerpc and x86. Looking at ./arch/x86/include/asm/pgtable_32_types.h (the only header where it has a different definition from the one I used, s.b.), I believe that ktla means Kernel Text-segment Load Address and both together might map the current address in kernel memory to addresses at link/load time and back. That's what I guess from ./kernel/kallsyms.c:is_kernel(), ./include/linux/module.h:within_module_range(), etc. Looking at the the #ifdefs, it seems to be relevant mostly on x86-32. I copied the definitions of ktla_ktva and ktva_ktla from ./arch/powerpc/include/asm/page.h to ./arch/ia64/include/asm/page.h - following patch makes it compile: --- ./arch/ia64/include/asm/page.h.orig 2012-02-01 08:19:59.000000000 +0100 +++ ./arch/ia64/include/asm/page.h 2012-02-01 08:21:00.000000000 +0100 @@ -55,6 +55,9 @@ # define HAVE_ARCH_HUGETLB_UNMAPPED_AREA #endif /* CONFIG_HUGETLB_PAGE */ +#define ktla_ktva(addr) (addr) +#define ktva_ktla(addr) (addr) + #ifdef __ASSEMBLY__ # define __pa(x) ((x) - PAGE_OFFSET) # define __va(x) ((x) + PAGE_OFFSET)
P.S: Forgot to mention: It is related to PAX_KERNEXEC ("Enforce non-executable kernel pages").
Hm, one issue solved, next ahead: CC fs/exec.o fs/exec.c: In function _pax_track_stack_: fs/exec.c:1918:32: error: _struct thread_info_ has no member named _lowest_stack_ fs/exec.c:1920:24: error: _struct thread_info_ has no member named _lowest_stack_ make[1]: *** [fs/exec.o] Error 1 Shall I file a new bug?
(In reply to comment #8) > Hm, one issue solved, next ahead: > CC fs/exec.o > fs/exec.c: In function _pax_track_stack_: > fs/exec.c:1918:32: error: _struct thread_info_ has no member named > _lowest_stack_ > fs/exec.c:1920:24: error: _struct thread_info_ has no member named > _lowest_stack_ > make[1]: *** [fs/exec.o] Error 1 > > Shall I file a new bug? --- ./arch/ia64/include/asm/thread_info.h.orig 2012-02-01 08:44:49.000000000 +0100 +++ ./arch/ia64/include/asm/thread_info.h 2012-02-01 08:44:57.000000000 +0100 @@ -31,6 +31,7 @@ mm_segment_t addr_limit; /* user-level address space limit */ int preempt_count; /* 0=premptable, <0=BUG; will also serve as bh-counter */ struct restart_block restart_block; + unsigned long lowest_stack; #ifdef CONFIG_VIRT_CPU_ACCOUNTING __u64 ac_stamp; __u64 ac_leave;
Who would have guessed: kernel/built-in.o: In function `module_alloc_update_bounds_rx': module.c:(.text+0x86182): undefined reference to `module_alloc_exec' kernel/built-in.o: In function `free_module': module.c:(.text+0x89102): undefined reference to `module_free_exec' module.c:(.text+0x89182): undefined reference to `module_free_exec' kernel/built-in.o: In function `load_module': module.c:(.text+0x8b662): undefined reference to `module_free_exec' module.c:(.text+0x8b682): undefined reference to `module_free_exec' module.c:(.text+0x8ceb2): undefined reference to `module_free_exec' kernel/built-in.o:module.c:(.text+0x8cf12): more undefined references to `module_free_exec' follow Copied from ./arch/powerpc/kernel/module.c: --- ./arch/ia64/kernel/module.c.orig 2012-02-01 09:14:44.000000000 +0100 +++ ./arch/ia64/kernel/module.c 2012-02-01 09:15:06.000000000 +0100 @@ -322,6 +322,13 @@ vfree(module_region); } +#ifdef CONFIG_PAX_KERNEXEC +void module_free_exec(struct module *mod, void *module_region) +{ + module_free(mod, module_region); +} +#endif + /* Have we already seen one of these relocations? */ /* FIXME: we could look in other sections, too --RR */ static int mm/built-in.o: In function `list_slab_objects.clone.41': slub.c:(.text+0x72252): undefined reference to `pax_check_alloca' crypto/built-in.o: In function `cipher_crypt_unaligned': cipher.c:(.text+0x2112): undefined reference to `pax_check_alloca' crypto/built-in.o: In function `shash_final_unaligned': shash.c:(.text+0x12a12): undefined reference to `pax_check_alloca' crypto/built-in.o: In function `shash_update_unaligned': shash.c:(.text+0x12d12): undefined reference to `pax_check_alloca' crypto/built-in.o: In function `alg_test_crc32c': testmgr.c:(.text+0x18cc2): undefined reference to `pax_check_alloca' block/built-in.o:elevator.c:(.text+0xb42): more undefined references to `pax_check_alloca' follow This seems to be a bug in Kconfig - ./arch/x86/kernel/dumpstack_*.c defines this only if CONFIG_PAX_MEMORY_STACKLEAK which is defined as follows: Symbol: PAX_MEMORY_STACKLEAK [=y] Prompt: Sanitize kernel stack Defined at security/Kconfig:531 Depends on: X86 [=X86] Location: -> Security options -> PaX -> Miscellaneous hardening features Selected by: GRKERNSEC_HARDENED_SERVER [=y] && <choice> || GRKERNSEC_HARDENED_WORKSTATION [=n] && <choice> || GRKERNSEC_HARDENED_VIRTU... Consequently no other arches define pax_check_alloca.
(In reply to comment #10) > mm/built-in.o: In function `list_slab_objects.clone.41': > slub.c:(.text+0x72252): undefined reference to `pax_check_alloca' > [...] > This seems to be a bug in Kconfig > [...] I am quite certain that this is a bug in the Gentoo config. Setting it =n in .config and running make oldconfig enables it again. Following patch fixes it: --- grsecurity/Kconfig.orig 2012-02-01 09:32:31.000000000 +0100 +++ grsecurity/Kconfig 2012-02-01 09:32:51.000000000 +0100 @@ -255,7 +255,7 @@ select PAX_REFCOUNT if (X86 || SPARC64) select PAX_USERCOPY if ((X86 || PPC || SPARC || ARM) && (SLAB || SLUB || SLOB)) select PAX_MEMORY_SANITIZE - select PAX_MEMORY_STACKLEAK + select PAX_MEMORY_STACKLEAK if (X86) help If you say Y here, a configuration for grsecurity/PaX features will be used that is endorsed by the Hardened Gentoo project. That fixes this part of the compilation. My previous patch regarding PAX_KERNEXEC missed a function, though - I will attach a patch including everything "upstream".
Created attachment 300621 [details, diff] Non Gentoo specific fixes for pax kernels on IA64
CC-ing upstream.
all i can say is that in PaX itself neither KERNEXEC nor STACKLEAK can be enabled for ia64 (it needs a whole lot more infrastructure work). if someone else overrides that decision without doing all that work then it's definitely not my problem :P.
Created attachment 300655 [details, diff] Fix tty_compat_ioctl section type conflict Found another one. This sone fixes a section type conflict for tty_compat_ioctl (static symbols cannot be exported on ia64).
(In reply to comment #14) > all i can say is that in PaX itself neither KERNEXEC nor STACKLEAK can be > enabled for ia64 (it needs a whole lot more infrastructure work). if someone > else overrides that decision without doing all that work then it's definitely > not my problem :P. So PAX_KERNEXEC should also be disabled for non-x86 in the Kconfig preset, as I did with STACKLEAK?
Created attachment 300657 [details, diff] Fix defconfig LRO (can't be a module) Due to recent discussion I split up the previous patch and submit the chunks separately. The Gentoo Kconfig patch should be thoroughly redone by the Gentoo/Hardened team, because the current "select" statements totally ignore the "if"s that are present in the default presets (e.g. "HIGH").
Created attachment 300659 [details, diff] Stub to make PAX_KERNEXEC compile on ia64
Created attachment 300661 [details, diff] Stub to make PAX_MEMORY_STACKLEAK compile on ia64
(In reply to comment #16) > So PAX_KERNEXEC should also be disabled for non-x86 in the Kconfig preset, as I > did with STACKLEAK? more precisely, noone should be overriding my original security/Kconfig settings ;). KERNEXEC cannot be enabled on anything but x86 and ppc. STACKLEAK is x86 only, you can't 'fix' it by patching compile errors, it needs proper infrastructure (look at pax_erase_kstack in arch/x86/kernel/entry_*.S to get an idea about what's required).
(In reply to comment #20) > (In reply to comment #16) > > So PAX_KERNEXEC should also be disabled for non-x86 in the Kconfig preset, as I > > did with STACKLEAK? > > more precisely, noone should be overriding my original security/Kconfig > settings ;). KERNEXEC cannot be enabled on anything but x86 and ppc. STACKLEAK > is x86 only, you can't 'fix' it by patching compile errors, it needs proper > infrastructure (look at pax_erase_kstack in arch/x86/kernel/entry_*.S to get an > idea about what's required). Renamed those to "stub" and warn everyone that the resulting kernel does boot, but not run properly. It had troubles auto loading modules, especially iptables, which often results in a in-kernel null deref at 0x50. Now I am trying with CONFIG_GRKERNSEC_HIGH=y and get: LD .tmp_vmlinux1 arch/ia64/kernel/vmlinux.lds:643 cannot move location counter backwards (from ffffffffffff7604 to 0000000000000000) make: *** [.tmp_vmlinux1] Error 1 No idea what this is about - I don't think I ever encountered such issue. And it did not happen before I ran "make defconfig" and had CONFIG_GRKERNSEC_HARDENED_SERVER enabled. My sys-devel/binutils is at 2.21.1-r1, in case you might be wondering about [1]. [1] http://sourceware.org/bugzilla/show_bug.cgi?id=12066
(In reply to comment #21) > Renamed those to "stub" and warn everyone that the resulting kernel does boot, > but not run properly. It had troubles auto loading modules, especially > iptables, which often results in a in-kernel null deref at 0x50. dmesg/backtrace would be nice to see here. > Now I am trying with CONFIG_GRKERNSEC_HIGH=y and get: > LD .tmp_vmlinux1 > arch/ia64/kernel/vmlinux.lds:643 cannot move location counter backwards (from > ffffffffffff7604 to 0000000000000000) what is around line 643 in that file?
(In reply to comment #22) > (In reply to comment #21) > > Renamed those to "stub" and warn everyone that the resulting kernel does boot, > > but not run properly. It had troubles auto loading modules, especially > > iptables, which often results in a in-kernel null deref at 0x50. > > dmesg/backtrace would be nice to see here. The calltrace is empty, hence I tried to fix that somehow by recompiling with more debugging (starting from defconfig), but now I get that "cannot move location counter backwards" problem. (In reply to comment #22) > (In reply to comment #21) > > Now I am trying with CONFIG_GRKERNSEC_HIGH=y and get: > > LD .tmp_vmlinux1 > > arch/ia64/kernel/vmlinux.lds:643 cannot move location counter backwards (from > > ffffffffffff7604 to 0000000000000000) > > what is around line 643 in that file? That is the last and empty line.
ok, maybe time to start from a clean slate 'cos i'm afraid we're mixing too many variables here. first, can you try the PaX patch alone and see if it builds/runs? then the same with grsecurity, then we can get to gentoo's config.
I am now trying again with -r91 using GRKERNSEC_HIGH (s.b. for the reason). @Gentoo/Hardened: It seems you still unconditionally select PAX_MEMORY_STACKLEAK in grsecurity/Kconfig despite it depending on X86 in security/Kconfig. @everyone: I get another error: fs/exec.c: In function _do_execve_: fs/exec.c:1530:2: error: implicit declaration of function _atomic64_inc_return_unchecked_ Is CONFIG_GRKERNSEC_PROC_MEMMAP also supposed to be disabled on ia64? The PaX and GrSecurity Kconfig files do not suggest this.
(In reply to comment #25) > fs/exec.c: In function _do_execve_: > fs/exec.c:1530:2: error: implicit declaration of function > _atomic64_inc_return_unchecked_ make it atomic64_inc_return if you want to compile it on ia64 as the _unchecked API exists only on archs where the refcount protection is supported, spender will have to accomodate them somehow.
Here is the patch, though I assume that the condition (ia64) is not what you want in the final code: --- fs/exec.c.orig 2012-02-24 14:43:57.000000000 +0100 +++ fs/exec.c 2012-02-24 14:44:13.000000000 +0100 @@ -1527,7 +1527,11 @@ /* execve succeeded */ #ifdef CONFIG_GRKERNSEC_PROC_MEMMAP +# ifdef CONFIG_IA64 + current->exec_id = atomic64_inc_return(&global_exec_counter); +# else current->exec_id = atomic64_inc_return_unchecked(&global_exec_counter); +# endif #endif current->fs->in_exec = 0; And now I am again at the old problem: LD .tmp_vmlinux1 arch/ia64/kernel/vmlinux.lds:643 cannot move location counter backwards (from ffffffffffff75f4 to 0000000000000000) make: *** [.tmp_vmlinux1] Error 1
(In reply to comment #27) > And now I am again at the old problem: > LD .tmp_vmlinux1 > arch/ia64/kernel/vmlinux.lds:643 cannot move location counter backwards (from > ffffffffffff75f4 to 0000000000000000) can you attach arch/ia64/kernel/vmlinux.lds please?
(In reply to comment #27) > LD .tmp_vmlinux1 > arch/ia64/kernel/vmlinux.lds:643 cannot move location counter backwards (from > ffffffffffff75f4 to 0000000000000000) > make: *** [.tmp_vmlinux1] Error 1 I figured out what causes this: CONFIG_IA64_PAGE_SIZE_64KB which appears to be the default: arch/ia64/configs/generic_defconfig:CONFIG_IA64_PAGE_SIZE_64KB=y Setting CONFIG_IA64_PAGE_SIZE_16KB instead solved the issue. (Do you still want the linker script or do we just abandon this issue?) So that leaves us with the following issues: * atomic64_inc_return_unchecked not existing on ia64 ("corrected" by my patch) * CONFIG_GRKERNSEC_HARDENED_SERVER setting bogus values ("corrected" by using CONFIG_GRKERNSEC_HIGH instead) Thanks for your support so far and hopefully the rest can also be properly fixed.
(In reply to comment #29) > I figured out what causes this: CONFIG_IA64_PAGE_SIZE_64KB which appears to be > the default: arch/ia64/configs/generic_defconfig:CONFIG_IA64_PAGE_SIZE_64KB=y > > Setting CONFIG_IA64_PAGE_SIZE_16KB instead solved the issue. (Do you still want > the linker script or do we just abandon this issue?) well, there should be nothing in PaX that would interfere with 64k page sizes, so yes, i'd like to see the .lds and figure out what's really going on here.
Created attachment 303109 [details] vmlinux.lds of linux-2.6.32-hardened-r91 with 64kb pages (In reply to comment #30) > (In reply to comment #29) > > I figured out what causes this: CONFIG_IA64_PAGE_SIZE_64KB which appears to be > > the default: arch/ia64/configs/generic_defconfig:CONFIG_IA64_PAGE_SIZE_64KB=y > > > > Setting CONFIG_IA64_PAGE_SIZE_16KB instead solved the issue. (Do you still want > > the linker script or do we just abandon this issue?) > > well, there should be nothing in PaX that would interfere with 64k page sizes, > so yes, i'd like to see the .lds and figure out what's really going on here. Here you go.
Created attachment 303111 [details] config of linux-2.6.32-hardened-r91 with 64kb pages
Another issue I found when trying to compile with CONFIG_IA64_GENERIC=y: drivers/char/mmtimer.c: In function _mmtimer_init_: drivers/char/mmtimer.c:827:2: error: assignment of read-only variable _sgi_clock_ It appears that ia64 receives very little testing in general (unless that assignment is PaX/grsec specific - haven't checked). :( I'll just ignore that and build with CONFIG_IA64_ZX1 again.
I fixed it before you reported it ;) I did a successful ia64/sparc32/ppc32 build here on both 2.6.32 and 3.2 with the latest patches. You'll either have to wait for them to be included in gentoo or just use mine directly. -Brad
(In reply to comment #34) > I fixed it before you reported it ;) I did a successful ia64/sparc32/ppc32 > build here on both 2.6.32 and 3.2 with the latest patches. You'll either have > to wait for them to be included in gentoo or just use mine directly. > > -Brad I just added these to the tree. They should have the fix: hardened-sources-2.6.32-r92 = grsecurity-2.9-2.6.32.57-201202251202 hardened-sources-3.2.7 = grsecurity-2.9-3.2.7-201202251203 @Dennis. Please reopen if these do not fix the issue.
(In reply to comment #14) > all i can say is that in PaX itself neither KERNEXEC nor STACKLEAK can be > enabled for ia64 (it needs a whole lot more infrastructure work). if someone > else overrides that decision without doing all that work then it's definitely > not my problem :P. This seems to be still true: config PAX_KERNEXEC depends on (PPC || X86) && (!X86_32 || X86_WP_WORKS_OK) && !XEN && !GRKERNSEC_HARDENED_VIRTUALIZATION config PAX_MEMORY_STACKLEAK depends on X86 And still the Gentoo config selects it unconditionally: config GRKERNSEC_HARDENED_SERVER select PAX_KERNEXEC select PAX_MEMORY_STACKLEAK Reopening, until this is fixed.
Comment on attachment 300655 [details, diff] Fix tty_compat_ioctl section type conflict It appears this has been applied already.
In addition the defconfig LRO patch (attachment #300657 [details, diff]) is not yet applied: == net/ipv4/Kconfig == config INET_LRO bool "Large Receive Offload (ipv4/tcp)" == arch/ia64/configs/generic_defconfig == CONFIG_INET_LRO=m Selecting m there would require it to be a tristate instead of a bool, right?
(In reply to comment #36) > (In reply to comment #14) > > all i can say is that in PaX itself neither KERNEXEC nor STACKLEAK can be > > enabled for ia64 (it needs a whole lot more infrastructure work). if someone > > else overrides that decision without doing all that work then it's definitely > > not my problem :P. > This seems to be still true: > config PAX_KERNEXEC > depends on (PPC || X86) && (!X86_32 || X86_WP_WORKS_OK) && !XEN && > !GRKERNSEC_HARDENED_VIRTUALIZATION > config PAX_MEMORY_STACKLEAK > depends on X86 > > And still the Gentoo config selects it unconditionally: > config GRKERNSEC_HARDENED_SERVER > select PAX_KERNEXEC > select PAX_MEMORY_STACKLEAK > > Reopening, until this is fixed. What should it be on ia64?
(In reply to comment #39) > What should it be on ia64? It appears that the following is needed, if I read the abovementioned dependencies correctly: select PAX_KERNEXEC if ((PPC || X86) && (!X86_32 || X86_WP_WORKS_OK) && !XEN) select PAX_MEMORY_STACKLEAK if (X86)
still an issue, this is ancient. reopen if it is.
