On Fri, Aug 17, 2007 at 10:19:00AM -0400, Dave Jones wrote:
> On Wed, Aug 15, 2007 at 12:48:35AM +0200, Andi Kleen wrote:
>
> > > > In general the .data protection is only considered a debugging
> > > > feature. I don't know why Fedora enables it in their production
> > > > kernels.
> > >
> > > That would be because we think you are wrong 8)
> >
> > Well, it might at best buy you a few weeks/months in
> > terms of the exploit arms race, but thrash your user's TLBs
> > forever.
>
> Show me a single situation where this matters.
We had a couple of benchmarks where compiled in vs external
4K mapped drivers made a noticeable difference.
> When we first enabled, we tried both benchmarks and real-world
> loads, and it didn't matter at all. Unless something fundamental
It also depends on the CPU -- the sizes of the TLBs vary widely.
On some older CPUs using 2/4MB pages was indeed a bad idea
because the number of large TLB entries were very small.
Also there are sometimes effects where the CPU splits the
TLBs internally so even with 2MB pages you effectively
get 4K TLB use. You could have run in one of those
> has changed since then, the story should still be the same.
Well if you believe it is that hyper useful you should try to convince
Linus then to readd the text protection for DEBUG_RODATA and a working text_poke()
that handles it correctly. The last version was nearly there, unfortunately the
time allowed for a new feature to be buggy and getting fixed before it
is reverted is very short these days[1].
Even if you say "my dumb attacker can patch sys_call_table but not
root_inode->i_ops in memory" it is still much harder to say
"my dumb attacker can patch sys_call_table but not a jump into *sys_read"
So without text protection your scheme is really double plus useless.
Modules could be also protected early BTW if you waste enough memory
to make .data page aligned [so likely raising minimal module size
from one page to two]
-Andi
[1] unless you name it pci sysinfo -- then anything is allowed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
