Re: [NSE] [Call for Testers] Nsock Library Binding Improvements

[Patrick Donnelly <batrick () batbytes com>]

On Fri, Sep 17, 2010 at 8:08 PM, David Fifield <david () bamsoftware com> wrote:
> What's new about lua_yield in 5.2?
>
> > +/* Lua 5.2 compatibility macro */
> > +#define lua_yieldk(L,n,ctx,k)  lua_yield(L,n)

Lua 5.2 is adding "C continuations". Here's the relevant documentation:

http://www.lua.org/work/doc/manual.html#4.7

Basically, it allows us to yield across C functions and resume C
functions. This has a couple immediate ramifications:

a) The socket_lock function can be called directly by l_connect. Right
now we use some simple Lua code which calls socket_lock repeatedly
until we obtain one, then calls l_connect. The reason l_connect cannot
call socket_lock directly is because socket_lock yields. When it
yields, l_connect can no longer resume running because it doesn't know
where it stopped.

   Lua always removes the C frame on a yield via "return
lua_yield(...)". When a coroutine is resumed after yielding in this
way, the C function that called lua_yield returns the results passed
to resume. In NSE, when we call l_connect, l_connect will yield but
later on the coroutine is resumed with the return values of l_connect.

   The new C continuations allow for us to restart the function rather
than being able to only return the results of the function. This also
applies to the receive_buf function. An implementation of the
receive_buf function in pure C is wrapped in "#if 0" for when we
integrate Lua 5.2.

b) We can now throw errors instead of returning nil + error message
inside socket functions. (We throw errors already for serious mistakes
like bad arguments.) Scripts can now pcall (C function) a routine
which does work with sockets. Any errors in the sockets will be caught
by the pcall. (This eliminates the need for the current try/catch
functions in the nmap library.) Right now we do not have these errors
because scripts cannot catch them. The reason being, in Lua 5.1, you
cannot yield across a C call boundary. For example:

batrick@menzoberranzan:~$ lua
Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> function f() return pcall(coroutine.yield, 1, 2) end; print(coroutine.wrap(f)())
false   attempt to yield across metamethod/C-call boundary

   Now, this doesn't mean we need to add real errors for all socket
function failure conditions. We just can if we want to. I'm not really
decided how I feel about it.

We should see Lua 5.2 hopefully by the end of the year according to
word on the Lua mailing list.

> > o pcap_open takes boolean (promiscous) for 3rd argument. Callback removed.
> > o pcap_register obsolete and removed.
> > o pcap_receive returns packets matching the bpf filter. Packet
> > "hashes" via callbacks which filter extraneous packets is gone. You do
> > this yourself by inspecting the returned packets by pcap_receive.
>
> I think this is a good idea. We've discussed before how the reason for
> the registration scheme is to allow many instances of a script to share
> the same pcap descriptor and BPF filter. However your implementation
> keeps the caching of descriptors so that the same script using the same
> BPF will use the same descriptor. If I understand correctly, if lots of
> scripts used a different BPF in the old scheme, they would get different
> descriptors anyway. I think this would be the case for scripts that
> build up BPF using host.ip.

I came to the same conclusions.

> I got some Valgrind errors when running the sniffer-detect script. (At
> the end of this message.) It looks like memory is being used after being
> freed. My first guess would be to check open_eth_cached.

Your guess was right. The weak table for the cache was wrong. This is
fixed in r20261.

-- 
- Patrick Donnelly
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/