Can someone dumb this down for me please?

Declan Moriarty junk_mail at iol.ie
Tue Jan 31 12:58:32 PST 2006


In trying to take advantage of my (nearly theoretical) new found
DRI 'capability' here, I am running into a _very_ swift kneejerk
reaction from the kernel. I transpose a little here from the logs
in the hope of words of wisdom to sort me out.

In the xterm:

bash: ./src/stellarium

    -----------------------------------------
    | ## ### ### #   #   ### ###  #  # # # #|
    | #   #  ##  #   #   ### ##   #  # # ###|
    |##   #  ### ### ### # # # #  #  ### # #|
    |                       Stellarium 0.7.1|
    -----------------------------------------

Copyright (C) 2000-2005 Fabien Chereau et al.

Please check last version and send bug report & comments
on stellarium web page : http://www.stellarium.org

> Found data files in . : local version.
Loading configuration file /root/.stellarium/config.ini ...
Killed.

And from /var/log/sys.log:

Jan 31 20:23:33 genius kernel: PAX: execution attempt in: <anonymous
mapping>, 01075000-01095000 01075000
Jan 31 20:23:33 genius kernel: PAX: terminating task:
/usr/src/stellarium-0.7.1/src/stellarium(stellarium):17739, uid/euid:
0/0, PC: 01075400, SP: bc67c4ac
Jan 31 20:23:33 genius kernel: PAX: bytes at PC: 55 56 33 c9 8b 6c 24
10 3b e9 0f 84 8a 00 00 00 8b
44 24 14
Jan 31 20:23:33 genius kernel: PAX: bytes at SP-4: bc67c508 00f2eeb4
12f170c0 00000002 abc6a000 00f2ecc0 00ca4188 00fdd844 00000003
abc6a000 12f170c0 00000000 12fd1218 12fcfd50 a03601af 00ca4188
1306a2d0 0100b5c0 01028120 00000005 00010000
Jan 31 20:23:33 genius kernel: grsec: denied resource overstep by
requesting 4096 for RLIMIT_CORE against limit 0 for
/usr/src/stellarium-0.7.1/src/stellarium[stellarium:17739]
uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3108] uid/euid:0/0
gid/egid:0/0

and GLXGEARS, which ran when the box was dri incapable,  fails in a 
similar manner:

Jan 31 20:26:45 genius kernel: PAX: execution attempt in: <anonymous
mapping>, 02e38000-02e58000 02e38000
Jan 31 20:26:45 genius kernel: PAX: terminating task:
/usr/X11R6/bin/glxgears(glxgears):14170, uid/euid: 0/0, PC: 02e38400,
SP: b1f4218c
Jan 31 20:26:45 genius kernel: PAX: bytes at PC: 55 56 33 c9 8b 6c 24
10 3b e9 0f 84 64 00 00 00 8b
44 24 14
Jan 31 20:26:45 genius kernel: PAX: bytes at SP-4: b1f421e8 02cf5eb4
13a6f6c8 00000052 a3705000 02cf5cc0 02b84188 02da4844 00000002
a3705000 13a6f6c8 00000000 13b28e48 13b27980 0c8e4610 00000000
00000000 02c1b33e 02def120 00000004 00010000
Jan 31 20:26:45 genius kernel: grsec: denied resource overstep by
requesting 4096 for RLIMIT_CORE against limit 0 for
/usr/X11R6/bin/glxgears[glxgears:14170] uid/euid:0/0 gid/egid:0/0,
parent /bin/bash[bash:5188] uid/euid:0/0 gid/egid:0/0


I would gather the kernel (wisely imho) objects to anything grabbing
hold of any section of ram like video ram and saying "That's mine!"

glxgears -info gives a few stats, notable of which is a maximum 
writable page size of video memory of 4096k, and  is this what the
kernel objects to? Therefore, DRI would seem too insecure ever to be
allowed. Is that analysis correct? I have these 2 options set
if they are relevant.

CONFIG_PAX_RANDMMAP=y
CONFIG_GRKERNSEC_PROC_MEMMAP=y


-- 

	With best Regards,


	Declan Moriarty.



More information about the hlfs-dev mailing list