Re: (maybe) crash your VAX from userspace

[Johnny Billquist <bqt%softjar.se@localhost>]

I think there might be bugs in there in old versions of simh. I remember 
having to deal with that for the PDP-11 emulation.

Thing is, the controller as such will handle packets larger than the 
buffer fine. This is what "chained buffers" are in the DEQNA/DELQA. And 
on a PDP-11 it's quite common to have buffers smaller than 1500, since 
the most common usecase is DECnet, which usually runs with an MTU of 576.

However, when I wrote my TCP/IP implementation for RSX, I designed it to 
be able to co-exist with DECnet, and having DECnet in charge of the 
controller, which meant that I constantly were getting packets larger 
than a buffer. And I remember that there were issues in older versions 
of simh, which were then fixed (can't remember, I might have been 
directly involved in those fixes, or maybe just testing things...)

Anyway, I know that it works fine on 3.9 and newer. However, there is a 
design problem in the API for the DEQNA/DELQA in that if you have short 
buffers, the controller can get into a catatonic state under some 
circumstances. So I would really recommend that any code still use 1500 
(plus overhead) buffers, even if the MTU is set lower, since large 
packets can still come in.
You basically do not want the controller to create chainer buffers for 
incoming packets, even though it can.
I also know that this design problem/issue is replicated in simh, and I 
can get simh instances at home into this state if I just set that up and 
let it run. But it takes some time and provocation... (Easier on real 
hardware... :P )

  Johnny

On 2024-03-23 16:23, Alexander Schreiber wrote:
> On Sat, Mar 23, 2024 at 10:41:51AM -0400, Mouse wrote:
> > > I think the point was that he wanted confirmation on real hardware.
> > > He also already observed this in simh. :)
> >
> > Yes...after seeing simh itself segfault, which leads to doubt that simh
> > is to be entirely trusted here.
>
> Observed behaviour:
>   - network traffic with small packets (ping, DNS, NTP) is fine
>   - TCP traffic with small packets (e.g. "telnet osgiliath.yauz.de 666")
>     is also fine
>   - TCP traffic with large packets, such as fetching pkgsrc via ftp
>     or via https reliably crash the simulator
>   - the backtrace always runs through the pcap library (not a surprise,
>     given that it is network traffic triggering the asplosion)
>   - on host=aarch64 I just get a crash inside glibc (Debian Bookworm)
>   - on host=amd64, I also get a crash inside glibc (Debian Bookworm),
>     but with more details: inside an assembly helper module that uses
>     AVX code for memory copying
>
> working theory:
>   - SIMH allocates a memory buffer for copying network packets
>   - the copy call runs over the boundaries of that buffer because of
>     either wrong buffer size or wrong parameters of the copy call
>   - I would expect such a fault in libpcap to have been found and
>     fixed already, so I suspect SIMH
>   - this is 3.8.1 as packaged by Debian, so somewhat old
>   - I need to build SIMH from last release or HEAD and test again
>   - this is also why I tried setting a silly small paket size on the
>     interface ... which led to this
>   - this might be specific to the simulation of the qe device, as I've
>     gotten "failed to repliced" reports with e.g. the qt device
>
>
> > I've fetched the 10.0_RC6 VAX sets and am in the process of setting it
> > up on my emulator.  It's not real iron, but it is a completely
> > independent emulator implementation.
>
> Thanks!
>
>
> Kind regards,
>             Alex.

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol