linux-kernel - Re: System call interposition/unprotecting the table

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20070818103722.GA15626@one.firstfloor.org>
Date:	Sat, 18 Aug 2007 12:37:22 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Dave Jones <davej@...hat.com>, Andi Kleen <andi@...stfloor.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Hajime Inoue <hinoue@...l.carleton.ca>,
	linux-kernel@...r.kernel.org
Subject: Re: System call interposition/unprotecting the table

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/