Replay Fail
Michael Elizabeth Chastain
<mec@duracef.shout.net>
Sat 18 Nov 1995

Copyright 1995 Michael Chastain
Licensed under the Gnu Public License, Version 2



Here are all the ways an event can become unreplayable:

    Permanent
	Executable not readable
	Executable not mmap'able
	IO port access enabled
	Mmap on changing file
	Shared memory

    Unknown
	Directory unknown
	Executable format unknown
	Ioctl unknown
	Mode unknown
	System call unknown

    Will Do
	Executable ELF format
	Executable shell scripts
	Signals
	System call not modelled



Permanent
---------    

Executable not readable

    If an executable file is not readable, I can't copy it for replaying!

Executable not mmap'able.

    I use mmap for imaging datasets, but sometimes a dataset is readable
    but not mmap'able.  Linux requires that shared libraries and ELF
    binaries be mmap'able.  It also loads QMAGIC and ZMAGIC binaries
    with a different address map if they are non-mmap'able.  Finally,
    every file system in Linux 1.3.36 supports mmap except for /proc.
    So handling non-mmap'able datasets would be a lot of code for
    epsilon functionality.

IO port access enabled

    The child process doesn't stop on 'in' and 'out' instructions,
    so I can't capture the values coming into the child.

    System calls: ioperm, iopl
    Ioctls: KDADDIO, KDDELIO, KDDISABIO, KDENABIO, KDMAPDISP, KDUNMAPDISP

Mmap on changing file

    I replay an 'mmap' by changing it to an anonymous mapping and
    storing into it.  If 'mmap' is used on a file and the file changes
    before the pages are fetched in, the replay will not reflect this.
    This is a silent failure.

Shared memory

    I can't handle shared memory, or other means by which memory changes
    in a volatile way.  Fortunately, the common uses of mmap are
    private, not shared.

    System calls: clone, mmap (shared writeable), mprotect (writeable),
	          phys, prof, profil, shmat, shmdt



Unknown
-------

Directory unknown

    This happens when the traced process calls one of
    {chdir,chroot,fchdir} followed by one of {execve,uselib}.  On Linux,
    I use '/proc/$pid/cwd' and '/proc/$pid/root' to follow the target
    process, so I never fail in this way.  On generic Unix, this
    facility is not available, and I may have to fail instead.

Executable format unknown

    ELF executables and libraries.

Ioctl unknown

    If an ioctl is unknown, either the target program has a bug and
    the call will have no effect, or the kernel has an ioctl in it which
    I don't know about.  Conservatively, I have to assume the latter.

Mode unknown

    This happens when a system call has modes and the mode called is
    not known.

System call unknown

    Again, either the target program has a bug, or the kernel has new
    system calls.



Will Do
---- --

Executable ELF format

    A much-needed enhancement.

Executable shell scripts

    I don't handle them yet.

Signals

    This needs a lot of work to model.
    System calls: pause, sigreturn, sigsuspend

System call not modelled

    These are calls I don't know enough about yet to model.
    System calls: afs_syscall, modify_ldt, quotactl, vhangup, vm86

