Re: Re: several messages

On Sat Nov 20 2004 at 02:35, Pavel Kankovsky wrote:

> It can be done but it requires familiarity with the exact behaviour of
> mmap() and memory layout of a platform the process runs on.

Is it portable?

> An alternative solution is to use offsets rather than pointers (hand-made
> PIC code). It adds some complexity to compute pointers (and extra CPU
> cycles) but the benefits of having one shared copy of the data *might*
> outweight the disadvantages.

I played with oprofile & gprof but the results look strange. It seems
that the NASL interpretor does not eat so much CPU.  
Anyway, I removed my "include cache", as the performance gain is tiny
-- if there is really any gain. Bison is really a good beast.

>> I can fix find_service2 & its brothers.
> Cool.

It's done, but only displayed with "verbose" reports.

> It is always possible to read the whole script with a single read()
> (unless some exception interrupts it). On the other hand, you cannot 
> do this with stdio and it'd be a waste of precious RAM to read the whole 
> source text (however big) just to parse it character by character and 
> discard it.

Yes, and it would probably lose the benefit of the filesystem read
ahead.

> BTW: the excessive use of ungetc() in the lexer is wierd.

I had to keep a buffer. As stdio provides one, I used it :)

> You mean getrusage(), right?

Yes

> BTW, have you tried compiling libnasl and libnessus with profiling enabled 
> (gcc -pg)?

Yes. But the results are strange and I prefer to get more reliable
results rather than publish something wrong.

> You yourself say you think the memory is more limiting than CPU
> power.

Because I use old laptops and scan a couple of machines at a time :)

> I think it'd be a standard case of premature optimization to rewrite the 
> whole interpreter now. Let's identify the bottlenecks first.

I think so. My (unreliable?) profiling results say so.

> Probably (although imho 64k buffer is a little bit too big for most 
> protocols).

8 KB?

> the former one suggests thrashing caused by excessive swapping or 
> something similar.

Definitely.

> BTW, I got an impression there is a lot of disk I/O (perhaps
> logging?) when the daemon "gets through all the script" even without
> running any of them.

Maybe. Buffering logs might be an answer -- but we need a logging
daemon to do that.

> You can add multiple keys for "at least version X.Y.Z is installed".
> I.e. 1.15 would have one key for 1.14 and 1.15 (assuming both versions 
> are interesting milestones, look below).
> Advantages:
> - works without any new code,
> - makes it easy to accomodate any wierd version numbering.

I see another problem. Let's say we have scripts that test flaws in
Apache/2.0.47 and we identify an Apache/2.0.50 on the target. So we
set : AtLeast/Apache/2.0.48 (and maybe AtLeast/Apache/2.0.50 too)
and our scripts use:
script_exclude_keys("AtLeast/Apache/2.0.48"); 
So far so good.
But if there is a 2nd vulnerable Apache running on another port, we
miss it.

That's why I implemented optimization_level: level 2 ignores
script_exclude_keys instructions, if you want to be sure that you do
not forget anything.

If we build the system in the other way, it will work: adding a key
that says that we have _at most_ version 2.0.50 installed. In my example,
we would have two keys, one for the vulnerable server and one for the
patch server, and our scripts would call
script_require_keys("AtMost/Apache/2.0.47", 
                    "AtMost/Apache/2.0.40" # for example...

But the list of dependencies could grow too big :-\

Note that this kind of problem can hardly happen with IIS, because it
is installed once. But Apache is bundled with many products: you may 
install your own Apache and also have IBM_HTTP_SERVER and Oracle web
server... So maybe we could use your system, but restrict it to
software like IIS that are (nearly) part of the operating system.

-- 
[email protected]	http://arboi.da.ru
NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
_______________________________________________
Nessus-devel mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus-devel