Re: [patch] Add basic sanity checks to the syscall execution patch

[Ingo Molnar <mingo@elte.hu>]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> 
> > and that'd be because at the same time they patch the syscall table (remember,
> > they already have to go to length to get around the read-only pages), they
> > can't also patch this 'protection'? sounds really plausible, right :).
> > 
> > [fixed hpa's address, .org bounces.]
> 
> Sure, they can :-)
> 
> It's just an idea I had on irc but I tend to agree that it wouldn't 
> have much effect in practice... regarding security, it will break some 
> existing rootkits ... until updated ones show up.

at which point we are left with a change that has no relevance to 
updated rootkits (they circumvent it just fine), while the kernel 
syscall entry path is left with 2 cycles (or more) overhead, forever.

Not a good deal.

We introduced the read-only syscall table because it has debugging and 
robustness advantages, with near zero cost. This change is not zero cost 
- it's ~1% of our null syscall latency. (which is ~100 nsecs, the cost 
of this check is ~1 nsec)

The other, more fundamental problem that nobody has mentioned so far is 
that the check returns -ENOSYS and thus makes rootkit attacks _more 
robust_ and hence more likely!

The far better solution would be to insert uncertainty into the picture: 
some sort of low-frequency watchdog [runs once a second or so] that 
tries to hide itself from the general kernel scope as much as possible, 
perhaps as ELF-PIC code at some randomized location, triggered by some 
frequently used and opaque kernel facility that an attacker can not 
afford to block or fully filter, and which would just check integrity 
periodically and with little cost.

When it finds a problem it immediately triggers a hard to block/filter 
vector of alert (which can be a silent alarm over the network or to the 
screen as well).

that method does not prevent rootkits in general (nothing can), but sure 
makes their life more risky in practice - and a guaranteed livelihood 
and risk reduction is what typical criminals are interested in 
primarily, not whether they can break into a particular house.

If we implement it then it should not be present in distro .config's, 
etc. - it should be as invisible as possible - perhaps only be part of 
the kernel image .init.data section in some unremarkably generic manner. 

[ It would be nice to have a 'randomize instruction scheduling' option 
  for gcc, to make automated attacks that recognize specific instruction 
  patterns less reliable. ]

A good benchmark for such a silent alarm facility would be whether an 
experienced kernel developer could reliably tell it via a kgdb session 
and full access to memory and system symbols that such a silent alarm is 
running on a box. If he cannot do it reliably then there's probably no 
good way for an attacker either.

And of course all the other layers of security play a bigger role: an 
attacker should not get to (native) kernel level access to begin with.

	Ingo