[lkml]   [2008]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] Add basic sanity checks to the syscall execution patch

* Benjamin Herrenschmidt <> 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 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.


 \ /
  Last update: 2008-09-05 13:45    [W:0.076 / U:8.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site