Port-vax archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: (maybe) crash your VAX from userspace
On Sat, Mar 23, 2024 at 04:23:41PM +0100, 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
And to close the loop on the SIMH VAX crashes: I grabbed SIMH source
from git HEAD and built it. Fired up the vax binary (MicroVAX 3900
simulator) as before. Interestingly, with this much newer version,
NetBSD by default attaches the qt device. After disabling qt in userconf,
I got the qe device. Tried my testcase of fetching the current pkgsrc
tarball and was able to grab the entire tarball via ftp with no
problems. So this crash is fixed in current SIMH and I only saw it
because the Debian current version was way behind, as usual ;-)
Also, thank you very much to Johnny Billquist for explaining the hardware
background behind the behaviour, that was very interesting to read.
When I got my hands on current computers (way back then), VAXen were
already on the way out ...
Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Home |
Main Index |
Thread Index |
Old Index