1 |
On 19 Mar 2007 at 22:09, Charles Taylor wrote: |
2 |
|
3 |
> What is the purpose of DEBUG_RODATA?? It sounded like |
4 |
> a good idea when I read its description. |
5 |
|
6 |
it's a good idea (after all, PaX has had it for 4 years now ;) |
7 |
but it's useful for debugging only, not security (to catch write |
8 |
attempts of read-only data, typically stuff that's declared as |
9 |
'const' in C). |
10 |
|
11 |
> I will not pretend to have anything more than an |
12 |
> superficial understanding of the various protected |
13 |
> mode descriptor tables, I'm just curious. |
14 |
|
15 |
KERNEXEC in PaX implements the same feature as DEBUG_RODATA and |
16 |
many others that actually improve security. one of these features |
17 |
is to mark more data read-only than usual (i.e. stuff that would |
18 |
remain writable even under DEBUG_RODATA). the GDT mentioned in |
19 |
particular is an i386 specific data structure that controls at |
20 |
the lowest level how virtual memory is segmented for both the |
21 |
kernel and userland use. there are two other descriptor tables, |
22 |
in particular the IDT (interrupt DT), that controls entry points |
23 |
into the kernel, this is also read-only under PaX (the third one |
24 |
is the Local DT/LDT and userland is allowed to manipulate it to |
25 |
an extent). |
26 |
|
27 |
in short, playing with these in a kernel exploit is of primary |
28 |
importance (google for 'call gate' and 'exploit' to see it in |
29 |
action). |
30 |
|
31 |
-- |
32 |
gentoo-hardened@g.o mailing list |