Single-address space, no processes?

[Sebastian Huber]

Hello,

I would like to use SSH to do some remote administration for an
application running with the RTEMS real-time operating system. In this
environment we have no virtual memory and user and kernel space
separation. So this is like an application running in kernel mode only.
Is it in possible to use the dropbear SSH server in such an environment?
A quick grep showed that fork() is used for example to spawn new
processes. Would it be possible to spawn a new thread instead (e.g. via
pthread_create())?
--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : [phone]
Fax : [phone]
E-Mail : ***@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

[Konstantin Tokarev]

Post by Sebastian Huber
Hello,
I would like to use SSH to do some remote administration for an
application running with the RTEMS real-time operating system. In this
environment we have no virtual memory and user and kernel space
separation. So this is like an application running in kernel mode only.
Is it in possible to use the dropbear SSH server in such an environment?
A quick grep showed that fork() is used for example to spawn new
processes. Would it be possible to spawn a new thread instead (e.g. via
pthread_create())?

fork() is not a mandatory part of SSH server workflow, e.g. look at inetd mode.

[Matt Johnston]

Hi Sebastian,

Dropbear probably won't fit without some modifications, though likely wouldn't be that hard to get working with only a single connection at a time. There's a global state variable, and may be a few other assumptions that the vforked child is going to exec() (like uClinux).
Recent releases have better memory cleanup on exit, though there may still be some circumstances where heap memory is leaked - the code was originally written assuming exit() would clean it up.


Cheers,
Matt

Post by Sebastian Huber
Hello,
I would like to use SSH to do some remote administration for an application running with the RTEMS real-time operating system. In this environment we have no virtual memory and user and kernel space separation. So this is like an application running in kernel mode only. Is it in possible to use the dropbear SSH server in such an environment? A quick grep showed that fork() is used for example to spawn new processes. Would it be possible to spawn a new thread instead (e.g. via pthread_create())?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : [phone]
Fax : [phone]
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

[Ed Sutter]

Sebastian,
(sorry for the late reply)
I ported dropbear SSH to uC/OS-I that used a sockets-api TCP/IP stack.
Point being: it is certainly doable.
Unfortunately, I can't release it, and I can tell you that it wasn't
trivial; however, it is certainly doable.
Ed

Post by Sebastian Huber
Hello,
I would like to use SSH to do some remote administration for an
application running with the RTEMS real-time operating system. In this
environment we have no virtual memory and user and kernel space
separation. So this is like an application running in kernel mode
only. Is it in possible to use the dropbear SSH server in such an
environment? A quick grep showed that fork() is used for example to
spawn new processes. Would it be possible to spawn a new thread
instead (e.g. via pthread_create())?

[Sebastian Huber]

Hello,

thanks for the hints.

So, running dropbear in a single-address space and no process
environment seems to be doable. However, it requires probably some
possible large code modifications, e.g.

* encapsulate the global state in a context structure and pass a pointer
to this structure around,
* add cleanup code instead of exit().

If I work on this, would it be possible to upstream these changes?
--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : [phone]
Fax : [phone]
E-Mail : ***@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

[Matt Johnston]

Hi Sebastian,

I'd be interesting in merging changes upstream, I think it would be of interest to a few people. It would need to be under a similar license to the current code.

Currently the session state is kept in ses, svr_ses, and cli_ses global variables (all structs defined in session.h). Changing eg ses.payload to ses->payload throughout the codebase is fairly straighforward. It mightn't be necessary to pass pointers around everywhere if ses/svr_ses/cli_ses could be thread-local pointer variables - how widely supported is thread-local storage?

Some of the state in ses might need to move to a process-wide state structure - "childpids" for example. That mightn't be relevant for your situation.

There is also some recent work to use Dropbear as a Perl module - that might have some useful changes in terms of avoiding Unix user authentication etc. https://github.com/atrodo/Net-Dropbear/tree/master/dropbear

Cheers,
Matt

Post by Sebastian Huber
Hello,
thanks for the hints.
So, running dropbear in a single-address space and no process environment seems to be doable. However, it requires probably some possible large code modifications, e.g.
* encapsulate the global state in a context structure and pass a pointer to this structure around,
* add cleanup code instead of exit().
If I work on this, would it be possible to upstream these changes?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : [phone]
Fax : [phone]
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

[Jamie Lokier]

Post by Matt Johnston
It mightn't be necessary to pass pointers around everywhere if
ses/svr_ses/cli_ses could be thread-local pointer variables - how widely
supported is thread-local storage?

If you can get a "current thread id" or set one "thread-local value", you can
make thread-local variables in portable C using macros without compiler
support.

It's not as fast as compiler supported thread-local storage, but it's portable
other than function to get the id, and provided you can set the value, it's
not necessarily slow.

Best,
-- Jamie