• Sbrsh2

About This Document

This document discusses the reasons behind the next-generation sbrsh and plans for its implementation.

Glossary

Background

Current status

• NFS problems and clumsiness
• NFS security issues
• Unidirectional execution
• Signals not supported
• Arbitrary open file descriptors not supported

Vision

• No NFS
• Single connection (enables SSH tunneling)
• Bidirectional execution
• Signal support
• Generic open file descriptor support
• New name (it isn't a remote shell...)

Ideas

• Native SSL support
• X11 tunneling

Possible Implementation Techniques

Signal and generic open file descriptor support should be straightforward to add even to the current implementation.

LD_PRELOAD

Override all I/O-related (and other necessary) C-library functions and redirect I/O to the host system. This approach is similar to LD_PRELOAD-based userspace filesystems.

Pros

• No kernel modifications needed
• No architecture-specific code needed

Cons

• Need to wrap a large and complex API
• Requires rebuilding (or even partial reimplementation) for different C-libraries
• Doesn't work with statically linked binaries
• Doesn't support writable file-backed mmaps

ptrace

Execute the target binary in a strace-like fashion. Syscalls are trapped and redirected to the host system. Writable file-backed mmaps might be possible to implement by trapping SEGV signal and decoding the instruction.

[http://iki.fi/timo.savola/repos/?r=ptrace-test;a=tree Prototype]

Pros

• No kernel modifications needed
• Syscall API is simpler than the C-library API
• Supports all kinds of binaries

Cons

• Requires architecture-specific CPU register handling
• Can't execute arbitrary code in the target process space (syscall can only be replaced)
• Implementing writable file-backed mmaps is problematic

Coda

Replace NFS mounts in the chroot using custom virtual filesystem which redirects I/O to the host system through the sbrsh communication channel.

Pros

• Simple API to implement (probably)
• mmap works perfectly (probably)
• No architecture-specific code needed

Cons

• Kernel module is usually not available by default (on embedded systems)
• Coda is designed to be a network filesystem, not to host custom userspace filesystems

FUSE

Same idea as with Coda. FUSE is planned to be used anyway in [http://freedesktop.org/wiki/Software_2fsbox2 "Scratchbox2"].

Pros

• Simple API to implement
• mmap works perfectly
• No architecture-specific code needed
• FUSE is designed to host custom userspace filesystems

Cons

• Linux 2.6.15 required
• Kernel module is usually not available by default (on embedded systems)

Kernel module

All of this could obviously be implemented by a custom kernel, but the implementation is potentially complex and requires constant maintenance.

FUSE on the host system

Writable file-backed mmaps could be implemented in co-operation with any other approach if the file is accessed through a custom virtual filesystem at the host system. The file would be copied to the target system for as long as it is being mapped by target binaries.

Pros

• Robust mmap implementation

Cons

• Adds complexity to Scratchbox

Implementation Requirements

• Avoid the need to have a custom kernel on the target system
• Support all types of binaries
• Minimize maintenance

Proposed Approach

ptrace seems like the most robust and generic approach to implement most requirements. Writable file-backed mmaps could be implemented with the help of FUSE on the host system.

Prestudy

• Research the usage requency of writable file-backed mmaps in Linux software
• Figure out the complete list of syscalls to be redirected
• Analyse if the syscalls can be implemented with this technique
• Plan the implementation of new architecture support

Other Ideas

• gdb wrapper for automatically launching gdbserver at the target device and launching a gdb which attaches to that
• If NFS, tested by thousands of users is still fragile, what guarantees that our network FS implementation would be more stable? -- NFS is optimized, ours is very simple (and inefficient). But more importantly, the configuration and infrasturucture required for NFS are not needed with our system.

  • Check if using userland nfs server created with one of python nfs server classes [http://www.panix.com/~asl2/software/Pinefs/ PineFS], [http://www.citi.umich.edu/projects/nfsv4/pynfs/ pyNFS], or some of the others could be used with sbrsh..

• Crossplatform (Open)Mosix B-). OpenMosix seems almost dead (or zombie), but they had a filesystem that featured timestamp coherance, which is one problem we have seen with nfs.