public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Dave Jones <davej@redhat.com>, Andi Kleen <andi@firstfloor.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Hajime Inoue <hinoue@ccsl.carleton.ca>,
	linux-kernel@vger.kernel.org
Subject: Re: System call interposition/unprotecting the table
Date: Sat, 18 Aug 2007 12:37:22 +0200	[thread overview]
Message-ID: <20070818103722.GA15626@one.firstfloor.org> (raw)
In-Reply-To: <20070817141900.GA7223@redhat.com>

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.


      reply	other threads:[~2007-08-18 10:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-13 22:05 System call interposition/unprotecting the table hinoue
2007-08-13 23:09 ` Alan Cox
2007-08-14  5:12   ` Avi Kivity
2007-08-14 11:34     ` Alan Cox
2007-08-14 14:22     ` James Morris
2007-08-14 17:27   ` Hajime Inoue
2007-08-14 17:48     ` Alan Cox
2007-08-14 17:57     ` Arjan van de Ven
2007-08-14 19:50     ` Andi Kleen
2007-08-14 21:09       ` Jan Engelhardt
2007-08-14 22:42       ` Alan Cox
2007-08-14 22:48         ` Andi Kleen
2007-08-17 14:19           ` Dave Jones
2007-08-18 10:37             ` Andi Kleen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070818103722.GA15626@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davej@redhat.com \
    --cc=hinoue@ccsl.carleton.ca \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox