Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 401669 - sys-kernel/hardened-sources-2.6.32-r89: Compilation broken on ia64
Summary: sys-kernel/hardened-sources-2.6.32-r89: Compilation broken on ia64
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: IA64 Linux
: Normal normal (vote)
Assignee: The Gentoo Linux Hardened Kernel Team (OBSOLETE)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-31 17:41 UTC by Dennis Schridde
Modified: 2013-06-24 21:33 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Non Gentoo specific fixes for pax kernels on IA64 (pax-kernel-fix-fox-ia64.patch,1.76 KB, patch)
2012-02-01 11:53 UTC, Dennis Schridde
Details | Diff
Fix tty_compat_ioctl section type conflict (hardened-sources-2.6.32-r89-tty_compat_ioctl-fix-section-type-conflict.patch,494 bytes, patch)
2012-02-01 14:41 UTC, Dennis Schridde
Details | Diff
Fix defconfig LRO (can't be a module) (hardened-sources-2.6.32-r89-defconfig-fix-for-ia64.patch,395 bytes, patch)
2012-02-01 14:57 UTC, Dennis Schridde
Details | Diff
Stub to make PAX_KERNEXEC compile on ia64 (hardened-sources-2.6.32-r89-pax_kernexec-stub-for-ia64.patch,1.35 KB, patch)
2012-02-01 14:58 UTC, Dennis Schridde
Details | Diff
Stub to make PAX_MEMORY_STACKLEAK compile on ia64 (hardened-sources-2.6.32-r89-pax_memory_stackleak-stub-for-ia64.patch,503 bytes, patch)
2012-02-01 14:59 UTC, Dennis Schridde
Details | Diff
vmlinux.lds of linux-2.6.32-hardened-r91 with 64kb pages (linux-2.6.32-hardened-r91.vmlinux.lds,26.93 KB, text/plain)
2012-02-25 01:11 UTC, Dennis Schridde
Details
config of linux-2.6.32-hardened-r91 with 64kb pages (linux-2.6.32-hardened-r91.config,45.74 KB, text/plain)
2012-02-25 01:11 UTC, Dennis Schridde
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Schridde 2012-01-31 17:41:47 UTC
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"
Comment 1 Dennis Schridde 2012-01-31 17:42:18 UTC
P.S: r87 had the same issue.
Comment 2 Dennis Schridde 2012-01-31 17:46:55 UTC
(In reply to comment #1)
> P.S: r87 had the same issue.
As does r83. r78 compiles and runs.
Comment 3 Jeroen Roovers gentoo-dev 2012-01-31 22:37:41 UTC
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.
Comment 4 Anthony Basile gentoo-dev 2012-01-31 23:24:16 UTC
Hi Dennis, do you get the same problem with vanilla?
Comment 5 Dennis Schridde 2012-02-01 07:15:41 UTC
(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.
Comment 6 Dennis Schridde 2012-02-01 07:35:44 UTC
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)
Comment 7 Dennis Schridde 2012-02-01 07:38:30 UTC
P.S: Forgot to mention: It is related to PAX_KERNEXEC ("Enforce non-executable kernel pages").
Comment 8 Dennis Schridde 2012-02-01 07:42:02 UTC
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?
Comment 9 Dennis Schridde 2012-02-01 07:47:23 UTC
(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;
Comment 10 Dennis Schridde 2012-02-01 08:25:41 UTC
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.
Comment 11 Dennis Schridde 2012-02-01 11:47:02 UTC
(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".
Comment 12 Dennis Schridde 2012-02-01 11:53:48 UTC
Created attachment 300621 [details, diff]
Non Gentoo specific fixes for pax kernels on IA64
Comment 13 Anthony Basile gentoo-dev 2012-02-01 12:46:38 UTC
CC-ing upstream.
Comment 14 PaX Team 2012-02-01 13:16:23 UTC
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.
Comment 15 Dennis Schridde 2012-02-01 14:41:39 UTC
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).
Comment 16 Dennis Schridde 2012-02-01 14:43:02 UTC
(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?
Comment 17 Dennis Schridde 2012-02-01 14:57:30 UTC
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").
Comment 18 Dennis Schridde 2012-02-01 14:58:17 UTC
Created attachment 300659 [details, diff]
Stub to make PAX_KERNEXEC compile on ia64
Comment 19 Dennis Schridde 2012-02-01 14:59:14 UTC
Created attachment 300661 [details, diff]
Stub to make PAX_MEMORY_STACKLEAK compile on ia64
Comment 20 PaX Team 2012-02-01 15:42:41 UTC
(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).
Comment 21 Dennis Schridde 2012-02-01 16:10:43 UTC
(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
Comment 22 PaX Team 2012-02-01 18:17:21 UTC
(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?
Comment 23 Dennis Schridde 2012-02-01 20:58:15 UTC
(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.
Comment 24 PaX Team 2012-02-01 22:36:42 UTC
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.
Comment 25 Dennis Schridde 2012-02-21 00:38:48 UTC
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.
Comment 26 PaX Team 2012-02-24 13:22:52 UTC
(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.
Comment 27 Dennis Schridde 2012-02-24 14:46:06 UTC
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
Comment 28 PaX Team 2012-02-24 15:13:37 UTC
(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?
Comment 29 Dennis Schridde 2012-02-24 15:52:42 UTC
(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.
Comment 30 PaX Team 2012-02-24 16:00:27 UTC
(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.
Comment 31 Dennis Schridde 2012-02-25 01:11:29 UTC
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.
Comment 32 Dennis Schridde 2012-02-25 01:11:57 UTC
Created attachment 303111 [details]
config of linux-2.6.32-hardened-r91 with 64kb pages
Comment 33 Dennis Schridde 2012-02-25 01:56:23 UTC
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.
Comment 34 Brad Spengler 2012-02-25 02:52:39 UTC
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
Comment 35 Anthony Basile gentoo-dev 2012-02-25 20:00:39 UTC
(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.
Comment 36 Dennis Schridde 2012-02-26 18:14:42 UTC
(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 37 Dennis Schridde 2012-02-26 18:26:50 UTC
Comment on attachment 300655 [details, diff]
Fix tty_compat_ioctl section type conflict

It appears this has been applied already.
Comment 38 Dennis Schridde 2012-02-26 18:28:16 UTC
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?
Comment 39 Anthony Basile gentoo-dev 2012-02-27 00:00:02 UTC
(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?
Comment 40 Dennis Schridde 2012-02-27 01:07:20 UTC
(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)
Comment 41 Anthony Basile gentoo-dev 2013-06-24 21:33:58 UTC
still an issue, this is ancient.  reopen if it is.