grsecurity forums

Early in the build it dies with this on my AMD64 machine:

Code: Select all

  CC      arch/x86/kernel/process_64.o
  CC      arch/x86/kernel/signal_64.o
  AS      arch/x86/kernel/entry_64.o
  CC      arch/x86/kernel/traps_64.o
  CC      arch/x86/kernel/irq_64.o
  CC      arch/x86/kernel/time_64.o
  CC      arch/x86/kernel/ioport.o
  CC      arch/x86/kernel/ldt.o
  CC      arch/x86/kernel/setup_64.o
  CC      arch/x86/kernel/i8259_64.o
  CC      arch/x86/kernel/setup.o
  CC      arch/x86/kernel/sys_x86_64.o
  CC      arch/x86/kernel/x8664_ksyms_64.o
arch/x86/kernel/x8664_ksyms_64.c:59: error: 'cpu_gdt_descr' undeclared here (not in a function)
arch/x86/kernel/x8664_ksyms_64.c:59: warning: type defaults to 'int' in declaration of 'cpu_gdt_descr'
make[1]: *** [arch/x86/kernel/x8664_ksyms_64.o] Error 1
make: *** [arch/x86/kernel] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.19467 (%build)


Build error is for both the latest grsecurity and pax patches, but not for my grsec-nopax build.

Didn't have the problem on x86

It works for me using grsecurity-2.1.12-2.6.26.2-200808091136.patch.

cormander wrote:Build error is for both the latest grsecurity and pax patches, but not for my grsec-nopax build.

Didn't have the problem on x86

thanks, i forgot to propagate a fix for this from .25.

Looks like the test10 patch fixed it. Thanks.

Ran into another (unrelated?) issue with the test10 build:

Code: Select all

Kernel: arch/x86/boot/bzImage is ready  (#1)
+ make modules
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  CALL    scripts/checksyscalls.sh
  CC [M]  arch/x86/kernel/msr.o
  CC [M]  arch/x86/kernel/cpuid.o
  CC [M]  arch/x86/kernel/microcode.o
  CC [M]  arch/x86/kernel/cpu/cpufreq/powernow-k8.o
  CC [M]  arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.o
  CC [M]  fs/mbcache.o
  CC [M]  fs/9p/vfs_super.o
  CC [M]  fs/9p/vfs_inode.o
fs/9p/vfs_inode.c: In function 'v9fs_vfs_follow_link':
fs/9p/vfs_inode.c:1001: warning: passing argument 2 of 'v9fs_readlink' discards qualifiers from pointer target type
fs/9p/vfs_inode.c:1007: error: assignment of read-only location
fs/9p/vfs_inode.c: In function 'v9fs_vfs_put_link':
fs/9p/vfs_inode.c:1025: warning: initialization discards qualifiers from pointer target type
make[2]: *** [fs/9p/vfs_inode.o] Error 1
make[1]: *** [fs/9p] Error 2
make: *** [fs] Error 2


I removed this section from the pax test10 patch:

Code: Select all

diff -NurpX linux-2.6.26.2-pax/Documentation/dontdiff linux-2.6.26.2/fs/9p/vfs_inode.c linux-2.6.26.2-pax/fs/9p/vfs_inode.c
--- linux-2.6.26.2/fs/9p/vfs_inode.c    2008-07-14 03:51:42.000000000 +0200
+++ linux-2.6.26.2-pax/fs/9p/vfs_inode.c        2008-07-14 03:52:23.000000000 +0200
@@ -991,7 +991,7 @@ static int v9fs_vfs_readlink(struct dent
 static void *v9fs_vfs_follow_link(struct dentry *dentry, struct nameidata *nd)
 {
        int len = 0;
-       char *link = __getname();
+       const char *link = __getname();
 
        P9_DPRINTK(P9_DEBUG_VFS, "%s n", dentry->d_name.name);
 


Build didn't fail after that change was reverted.

It seems odd to me that your change in cast type of __getname() would break things here. Why would it need to be "writeable memory"? Could this be a compiler quark? (gcc-4.1.2-14.el5 on centos5)

Guess this shows how little I know about the inner workings of the kernel

cormander wrote:Build didn't fail after that change was reverted.

It seems odd to me that your change in cast type of __getname() would break things here. Why would it need to be "writeable memory"? Could this be a compiler quark? (gcc-4.1.2-14.el5 on centos5)

Guess this shows how little I know about the inner workings of the kernel

this was a mismerge (notice how the chunk in v9fs_vfs_put_link got dropped), it's fixed in test11.