PiDP-8/I Software

A simpler option for remotely using one's PiDP-8/I than SSH'ing in and connecting to the screen(1) session would be if you could just telnet to it. This avoids the need for Windows users to go find an SSH client, and avoids the need to deal with passwords, SSH keys, etc. on all platforms.

SIMH does largely support this via a combination of SET CONSOLE TELNET and SET REMOTE TELNET. The first command redirects the normal stdout terminal interface to telnet on a TCP port of your choice, and the latter allows access to most SIMH commands via telnet on a different port.

This isn't perfect, so it needs to be optional:

• The simple way of doing this means you lose out on screen(1) features like scrollback and the ability to detach, reattach, and not lose the prior screen's contents. screen(1) does have the ability to act as a telnet client, but SIMH only supports a single telnet connection at a time, and screen(1) can't re-export its telnet connection. There must be some tee(1) like program for TCP (nc or ncat, maybe) but that's adding a lot of complexity.

• Short of doing that complex tee(1)/ncat hackery, you wouldn't have the ability to switch between the old straight screen(1) based method and the telnet based method other than reconfiguring and restarting everything, since enabling the telnet features disable the stdout features the current screen(1) method needs in order to work.

• Some SIMH commands like ! are blocked when using the remote telnet interface for security reasons. This is good, but it then means you can't do some things via telnet that you could when logged in via SSH and using screen(1).

Doing this would allow a bad actor on the [W]LAN to exfiltrate files from the local system readable by the user running the modified SIMH by using its paper tape and other media attachment features.

It is even possible that they could write to local files by attaching a file as, say, a raw RK05 disk pack and then modifying the file via PDP-8 code.

Keep in mind that if this is the default mode, it will affect people on their desktop development systems, laptops, etc., not just Raspberry Pis running our software.

This feature could only be done once we have a way of doing proper user isolation, so that the user running the simulator is only allowed to read and modify things in $prefix/share/media. This could get really complicated, and all to save people from having to figure out SSH.

It would be too easy to use this feature to exfiltrate data from the Pi via the media mounting feature. You could probably even use it to falsely mount a Pi-side file as a raw RK05 disk and then modify the Pi via the simulator this way.

Doing this would open a massive security hole.