> Jeff,
>
> You're exactly right. If you don't recognize the "knowledge-based"
> aspect of this problem and try to apply an ad-hoc approach, it's very
> unlikely you'll ever come up with a really useful tool.
>
> Offhand, I'd say that to make this concept work one would need to
> apply conventional compiler construction techniques (lexical and
> syntax analysis, of course, but more importantly, as much data flow
> analysis as you can muster), plus an open-ended, declarative KB with
> a suitable inference engine.
This was exactly what I was pointing towards, you need a classical frontend
that can deal with all the parsing troubles and present a intermediate level
(and thus much simplified) description of the code, this representation then
needs to be investigated by a inference engine which has a fundamental suite
of rules being set up. Then, the inference engine needs to be accelerated for
common rule combinations so that the task becomes computational feasable.
Having done similar things (including handcoded accelerations) I'd say it is
possible to do it to some degree, but there are some issues which is sort of
not very nice about these systems.
> Given all this and lots of work developing the KB representing the
> tests to apply (and that's got to be ongoing work, as the exploits
> and the understanding of them evolve), this concept would probably be
> feasible. It would require domain experts in information system
> security and processor architectures, knowledge engineers, people
> with in-depth compiler expertise and a good software engineering team
> if you wanted to support this.
Certainly, diffrent parts of expertice is needed. One of the things is that
the one has to fix is that the security, processor and kernel writing people
needs to understand how to write rules and good rules. In many cases have
systems with this theoretical power had an inherently obscure interface
language which migth be nice for research environment but does not cut it
outside that environment.
> I would not start from "scratch," naturally. Obviously one would use
> the available compiler construction tools and, if you add access to
> it, much of an optimizing compiler would be helpful, too (GCC / EGCS,
> is an obvious candidate). More importantly, I'd also employ a mature
> KB system such as Cyc for the knowledge-based aspects. Not to avail
> one's self of these tools would only add unnecessarily to the work
> required to realize this concept.
I think that the GCC frontend and intermediate code is fairly suitable without
having looked at it in this ligth.
> It's a lot of work, no doubt about it, but I certainly does sound fascinating.
Sure, and it is bound to happend somewhere else than here on linux-kernel.
Cheers,
Magnus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/