grsecurity forums

Hey brad, try commetning out gr_handle_creat(), I'm pretty sure thats cause..if that works try commenting out just the part in move_proc_subj_label() from the tasklist read lock to the read unlock. BTW mailed you some little diffs. I'm wondering if should move this stuff....have you strace'd evolution to see where it locks...I'm wondering if its cautching at open(),mkdir(),rmdir(),or unlink(). Later

Michael

just commented out gr_handle_create()....it still makes the process done outside of admin mode take up 100% cpu. after both cpus are taken up, running another app locks the system up.

Okay.. Have you tried with gr_handle_delete commented out? BTW
that 100% usage is defintaely a deadlock. I'm gonna
have to go through the code and check for any
possible deadly embraces I guess. (defined in russell's
docs on kernel locking). Later =)

Michael

ok, commented out the gr_handle_delete....no more problems.

it's broke...locks up on gradm -D, and so i can't even look at the previous logs as they're all corrupted.

-Brad

Damn, sorry about that log corruption. Thats very odd.
Okay, I've got some ideas. Maybe its a deadly embrace
bsed on move_proc_subj_acl's locks, but I checked out the
code and it seemsthat we always lock/unlock the same
stuff in the same order. and read lock orders shouldn't
matter anyway, only r/w and spinlocks. I mailed you another
patch a few minutes ago, it will at the least provide
more verbose debugging. I think gr_hnadle_create() and
gr_hnndle_delete() are at the very least properly placed,
as they work fine on my UMP box, creating and disabling
acls as I delete/create files. After this debug, I'm going
to have to add those mprotect() checks.

when enabling gracl:

Feb 27 10:01:59 grsecurity kernel: divide error: 0000
Feb 27 10:01:59 grsecurity kernel: CPU: 0
Feb 27 10:01:59 grsecurity kernel: EIP: 0010:[add_proc_obj_label+119/1472]
Not tainted
Feb 27 10:01:59 grsecurity kernel: EIP: 0010:[<c0127c77>] Not tainted
Feb 27 10:01:59 grsecurity kernel: EFLAGS: 00010206
Feb 27 10:01:59 grsecurity kernel: eax: 00082835 ebx: 00000000 ecx: 00000000
edx: 00000000
Feb 27 10:01:59 grsecurity kernel: esi: d9f5fae6 edi: 0001419b ebp: 00000001
esp: d9f5f9c8
Feb 27 10:01:59 grsecurity kernel: ds: 0018 es: 0018 ss: 0018
Feb 27 10:01:59 grsecurity kernel: Process gradm (pid: 1709, stackpage=d9f5f000)
Feb 27 10:01:59 grsecurity kernel: Stack: 00900306 03060000 00000001 00001b0c 00
a70307 00000002 dffaba00 d9faa740
Feb 27 10:01:59 grsecurity kernel: c1951e40 d9e87d40 3c7cf4e7 dd13ff60 00
000009 00000001 d9f5e000 d9f5faf4
Feb 27 10:01:59 grsecurity kernel: d9f5faf4 d9f5faf5 d9f5fade c01287d9 d9
f5fade c02b2ba4 c027ceae 00000004
Feb 27 10:01:59 grsecurity kernel: Call Trace: [add_line+713/736] [file_read_act_read+122/288] [filp_close+140/160] [grsecurity_init+368/1440] [set_termios+366/
384]
Feb 27 10:01:59 grsecurity kernel: [<c015629c>] [<c0142196>] [<c0132dca>] [<c
0140bcc>] [<c0128e90>] [<c01b449e>]
Feb 27 10:01:59 grsecurity kernel: [gr_proc_handler+629/2704] [do_rw_proc+106
/128] [tty_read+213/288] [proc_writesys+23/32] [sys_write+149/256] [sys_ioctl+49
7/504]
Feb 27 10:01:59 grsecurity kernel: [<c012b915>] [<c011d53a>] [<c01af805>] [<c
011d587>] [<c0141335>] [<c0151f31>]
Feb 27 10:01:59 grsecurity kernel: [system_call+51/56]
Feb 27 10:01:59 grsecurity kernel: [<c010701b>]
Feb 27 10:01:59 grsecurity kernel:
Feb 27 10:01:59 grsecurity kernel: Code: f7 f1 a1 34 c1 33 c0 8d 14 92 8d 1c 90
8d b6 00 00 00 00 8d

After this release I recommend that everyone wave their hands in the air and move them like they just don't care.

What about throwing up westside?

for the sake of everyone reading this, all the problems above have been completely fixed (except for jmh's ghettoness )

Fixing jMh's ghettoness will be as difficult as swallowing the statue of liberty. I think we're going to give up on that one :)

hi spender. Long time no see. Are you working on grsecurity?

yea sup? find a place for us to chat

efnet #port80, #se, #kiwis i will be there most days :)
Talk to you in a minute!