Speed up trace mode (GSoC Project)

[Clemens Lang]

On Sun, Mar 31, 2019 at 10:06:12PM +0530, Mihir Luthra wrote:
> I need help understanding *static* *int* TracelibRunCmd(Tcl_Interp
> *in), it has blown my mind, I am totally new with these kevents.
> 
> I have been trying to understand that from a while now. Till what I
> understand, the thread responsible for creating server eventually
> calls tracelib run and then here
>  *if* (1 != kevent(kq, &kev, 1, &kev, 1, *NULL*)).  —— (1)
> 
> waits here until the kqueue detects that someone is trying to read via
> socket and returns a value.
> 
> in porttrace.tcl, the library gets injected and sandbox gets set. and
> then in portutil.tcl tracelib setdeps sets the dependencies.
> 
> Now the in  (1) , it would only return when someone tries to read data
> from the socket, when does that happen?

Note that kevent(2) is a multi-purpose API. The call you refer to as (1)
is not actually the mainloop of tracelib run. Rather, the call a little
further down is:

  keventstatus = kevent(kq, NULL, 0, res_kevents, MAX_SOCKETS, NULL))

This will also return for new connections to the socket, which
darwintrace.dylib creates. Depending on why kevent returned, the code
will either process a line from a socket, or accept a new socket and
then eventually call kevent again.

> Is it when darwintrace calls frecv? That seems to be the only part
> where data is read from that socket and for breaking going beyond that
> kevent(), reading seems necessary. But to do that accept() must be
> called which is called later.

The darwintrace side never reads input without first sending a command
to the server-side. It's always a request-and-answer protocol, so the
server side will only send messages to the client when they are
requested using a command.

On Sun, Mar 31, 2019 at 10:51:10PM +0530, Mihir Luthra wrote:
> Demo would be kind of like replicating functionality of client side
> trace mode in a 2 process program also with 2 threads which call
> functions like open, close etc (which I will replace by my own
> implementations by a library with dyld_insert_libraries). For their
> sandbox bounds I will pass my own arguments and try mapping memory
> with a file using Ctrie which will be checked before sandbox bounds
> function.
> Most probably I will deliver this demo in 3-4 days.

I actually think it would be enough to just implement a Ctrie, but if
you can find a suitable BSD-licensed (or compatible) implementation that
you can reuse instead of re-implement you could also do the demo you
suggested. I don't mind either way.

> https://docs.google.com/document/d/1qH5VMtrQ3tvd5gFPf51lmJtd6dYfUuEmO1AvXmU_4qM/edit#heading=h.9cfgiuh00i0k
> 
> I have made some changes in technical details “problem” & “solutions”
> and I have correctly specified right deliverables for first
> evaluation. If this way is correct, I may proceed the same way for
> second and final evals.
> Currently, ctrie seemed the best implementation for checking a path,
> although, if I get more time before submission data I will try the
> best to look for even better alternative if possible.

>From what I can see, the proposal looks more detailed to me now.
However, you are not yet addressing the inherent race conditions with
the suggested approach in the shared memory area and the special
conditions required due to use of shared memory, such as not being able
to use normal pointers.

Please also look into the paper on arXiv I sent you a while ago, because
that did seem the data structure proposed there would already solve some
of our problems.

You will also have to consider how to expand the shared memory area if
the space we initially reserve is no longer enough for what we are
trying to store (and how to do so in a race-condition free way, or at
least a way that is unlikely to cause a race-condition in our use case).


On Mon, Apr 01, 2019 at 12:15:13AM +0530, Mihir Luthra wrote:
> I was wondering if the trace mode optimisation project would be
> sufficient for entire summer? Because maximum effort is about
> understanding the code which needs to be done before gsoc starts.

In general, I'd rather have proposals that underpromise and overdeliver
than overpromise and underdeliver.

> After that maybe the shared memory concept can be achieved within a
> month. Maybe testing that will be a big deal because bugs maybe
> possible. I donno if I am right.

Don't underestimate the effort required to get the data structure
implemented given the constraints of the environment. To be certain that
your data structure works as it should, you will also have to write an
extensive test suite for all functionality of the data structure,
possibly using code coverage measurements.

Additionally, if you really think you'd be done with all of that early,
you can include optional "stretch goals" that we can take up if you're
done early, such as writing a test suite for trace mode functionality,
writing documentation for the on-wire format between darwintrace.dylib
and the server, etc.


-- 
Clemens