| 1 |
27.02.2011 22:32, "Tóth Attila" пишет: |
| 2 |
|
| 3 |
> More reliable? Interesting. Do you have a link about this? |
| 4 |
> Apart from older systems 32bit will be with us at least because of the ARM |
| 5 |
> architecture. |
| 6 |
|
| 7 |
http://grsecurity.net/pipermail/grsecurity/2010-April/001024.html - from here: |
| 8 |
|
| 9 |
> this is also where the similarities end :), so let's look at the bad stuff |
| 10 |
> now. UDEREF/amd64 doesn't ensure that the (legitimate) userland accessor |
| 11 |
> functions cannot actually access kernel memory when only userland is allowed |
| 12 |
> (some in-kernel users of certain syscalls can temporarily access kernel memory |
| 13 |
> as userland, and that is enforced on UDEREF/i386 but not on amd64). so if |
| 14 |
> there's a bug where userland can trick the kernel into accessing a userland |
| 15 |
> pointer that actually points to kernel space, it'll succeed, unlike on i386. |
| 16 |
> |
| 17 |
> the other bad thing is the presence of the userland shadow area. this has |
| 18 |
> two consequences: 1. the userland address space size is smaller under UDEREF |
| 19 |
> (42 vs. 47 bits, with corresponding reduction of ASLR of course), 2. this |
| 20 |
> shadow area is always mapped so kernel code accidentally accessing its range |
| 21 |
> may not oops on it and can be exploited (such accesses can usually happen only |
| 22 |
> if an exploit can make the kernel dereference arbitrary addresses in which |
| 23 |
> case the presence of this area is the least of your concerns though). |
| 24 |
> |
| 25 |
> what about performance? well, 'it depends', in particular it depends on the |
| 26 |
> amount of user/kernel transitions of your workload as that's where the extra |
| 27 |
> code really hits (it's basically a TLB flush and two CR0 writes if you have |
| 28 |
> KERNEXEC as well, say 600 cycles + TLB repopulation time). on a simple |
| 29 |
> compilation test i get these times: |
Archives