From: Andi Kleen <andi@firstfloor.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: pageexec@freemail.hu,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Andi Kleen <andi@firstfloor.org>,
Arjan van de Ven <arjan@infradead.org>,
linux-kernel@vger.kernel.org, tglx@tglx.de, hpa@zytor.com
Subject: Re: [patch] Add basic sanity checks to the syscall execution patch
Date: Fri, 5 Sep 2008 19:26:44 +0200 [thread overview]
Message-ID: <20080905172644.GV18288@one.firstfloor.org> (raw)
In-Reply-To: <20080905165239.GA12645@elte.hu>
First such checkers already exist -- they are called root kit checkers.
There are various around.
Usually operate from user space. You could run them in a cron job.
> well at least in the case of Linux we have a fairly good tally of what
> kernel code is supposed to be executable at some given moment after
> bootup, and can lock that list down permanently until the next reboot,
> and give the list to the checker to verify every now and then? Such a
Doing it in a hypervisor implicitely like Alan proposed would seem much
stronger and also somewhat cleaner than doing it delayed.
> verification pass certainly wouldnt be cheap though: all kernel
> pagetables have to be scanned and verified, plus all known code (a few
> megabytes typically), and the key CPU data structures.
The issue is that a lot of non key data structures all over the memory
have function pointers (or pointers to function pointers) too.
So if you protect syscall table they are just going to patch some dentry
instead. Still if it's reasonable clean it might be still useful to
raise the bar a bit, but I'm not sure a checker qualifies for that.
-Andi
next prev parent reply other threads:[~2008-09-05 17:23 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-04 2:51 [patch] Add basic sanity checks to the syscall execution patch Arjan van de Ven
2008-09-04 12:01 ` Andi Kleen
2008-09-04 12:34 ` Alan Cox
2008-09-04 13:06 ` Andi Kleen
2008-09-04 12:44 ` Arjan van de Ven
2008-09-05 9:43 ` pageexec
2008-09-05 10:14 ` Benjamin Herrenschmidt
2008-09-05 10:49 ` pageexec
2008-09-05 10:57 ` Benjamin Herrenschmidt
2008-09-05 11:42 ` Ingo Molnar
2008-09-05 12:00 ` pageexec
2008-09-05 15:42 ` Ingo Molnar
2008-09-05 16:23 ` pageexec
2008-09-05 16:52 ` Ingo Molnar
2008-09-05 17:26 ` Andi Kleen [this message]
2008-09-05 19:42 ` pageexec
2008-09-05 20:48 ` Andi Kleen
2008-09-05 19:37 ` pageexec
2008-09-06 15:42 ` Ingo Molnar
2008-09-07 0:17 ` pageexec
2008-09-05 12:01 ` Andi Kleen
2008-09-05 20:41 ` Willy Tarreau
2008-09-06 15:45 ` Ingo Molnar
2008-09-06 16:34 ` Jeroen van Rijn
2008-09-07 12:53 ` Pavel Machek
2008-09-05 16:05 ` Arjan van de Ven
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=20080905172644.GV18288@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=benh@kernel.crashing.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pageexec@freemail.hu \
--cc=tglx@tglx.de \
/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