Re: [Simulavr-devel] GDB to stdin connection & threading

[Petr Hluzín]

On 30 January 2012 19:23, ThomasK <address@hidden> wrote:
> Hi Petr,
>
>
>> * attackers on network are able to abuse the poor simulavr
>
>
> I think, this is really a security problem. It's an open port for somebody,
> which is able to connect to it and nobody can be sure, that there is no
> possiblity to abuse it.
>
> The first is: NOBODY SHOULD RUN SIMULAVR AS ROOT! No no, don't do it! :-)
>
> But even if running as normal, unpriviledged user it's not secure. A hint
> for me, to write a warning in documentation. To hold it in mind, if you use
> simulavr as gdbserver!

I think it is obvious once user sees that "-p" creates a listening port.

>
>> So I am trying to allow launching simulavr by using GDB command
>> "target remote | simulavr.exe --something". (The existing ways will
>> remain available.)
>
>
> This could be really a solution for the problem. If it works! Topics are: it
> should run in Linux AND windows. (but maybe with 2 different implementations
> for the connection), performance.

Of course. I would say explicitly if I were to suggest something which
does not work on Linux.

As I wrote in the original post, Linux can have the feature without
needing the special workaround. I mentioned the EXE file extension to
make it obvious that GDB is launching a new process and the word
"simulavr" is not some special command token or GDB script.

>
>> This means that simulavr would not be able to process inputs from
>> other TCP connections, e.g. fake terminal, the display thing (I do not
>
> I'm not really sure, if this is possible in current simulavr. Because, if
> running as gdb server the processing in simulavr depends completely on
> commands from gdb. There is no asynchronous processing of whatever. (my
> opinion) And anything else could end in a complete redesign of simulavr.

Yes, there is no asynchronous processing. If simulation is paused,
e.g. by a breakpoint + GDB, then simulavr is blocked waiting on GDB. I
think the loop in GdbServer::Step() used to burn 100% CPU by polling
on other GDB connections (not other TCP connections), but it seems I
killed the polling months ago.

-- 
Petr Hluzin