<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 28-Jan-18 18:04, Timothe Litt wrote:<br>
</div>
<blockquote type="cite"
cite="mid:34367a6a-f66e-0a50-ffd4-2ac9854bbfb0@ieee.org">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<br>
<div class="moz-cite-prefix">On 28-Jan-18 17:21, Jeremy Begg
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:01QOEXWMH8M6005516@haven.vsm.com.au">
<pre wrap="">Hi TIm,
</pre>
<blockquote type="cite">
<pre wrap="">...
Also I am figuring out how to set SSH2 terminal server. I successfully
generated SSH2 keys on emulated SIMH VAX system.
...
I installed SIMH and OpenVMS 7.3 on my new Tinker SoC (Pi clone) with
Armbian OS for 7/24 operation.
</pre>
</blockquote>
<pre wrap="">Once you get SSH working you may find it's unusable. On my RPi 3 it
takes the VMS MultiNet SSH server several *minutes* to negotiate the
SSL handshake. I suspect (without having attempted any diagnosis!)
that this is due to SIMH having to emulate a huge number of VAX floating
point instructions.
</pre>
</blockquote>
I suggest running PCA to determine if this is in fact the cause.
Or stop the emulation a few times while "hung" and look at the
history buffer.<br>
<br>
If I had to guess, I'd start by looking at where the required
randomness (for key generation) is coming from. In most
implementations, that's the cause of typical hangs like these. I
don't know what Multinet is using for a source of randomness -
perhaps Hunter can shed light on that.<br>
<br>
FP in SimH isn't that slow - the VAX format is unpacked, then
integer (hardware) operations are performed on the "mantissa" and
exponent, then the result repacked. These are all integer
operations, and should be reasonably fast on any processor, even a
Pi. The FP code would benefit from a high level of compiler
optimization, as there are lots of opportunities for inlining.<br>
<br>
Note that the PI, and many modern CPUs provide a hardware source
of randomness (which can be behind /dev/{u,}random). It may be
off by default, depending on your distribution. I don't think
that SimH VAX uses it, but it might be something to export. Most
older OS would try to gather randomness from device timing
(interrupt jitter), something that SimH alters... It can take
quite a bit of data to get enough bits to satisfy randomness (or
primality) tests used in key generation.<br>
<br>
Anyhow, FP would not be the first place I'd look.<br>
<br>
<blockquote type="cite"
cite="mid:01QOEXWMH8M6005516@haven.vsm.com.au">
<pre wrap="">(Even on my real VAXstation 4000/96 the MultiNet SSH server took up to a
minute to negotiate the SSL handshake, and of course the system would
"pause" every now and again while the session keys were renogotiated.</pre>
</blockquote>
</blockquote>
This supports the guess that the issue is more likely to be
generating random bits than the speed of FP emulation.<br>
<br>
When I stopped paying attention to VMS, there was no hardware RNG
support. The usual advice - MTH$RANDOM is a uniform software
pseudo-RNG that produces an F-float between 0.0 & 1.0. It is
fine for simulations (as in statistics, not what SimH does), but not
suitable for most crypto. Given the seed, the next number is
predictable as it's a simple congruential algorithm. And there's no
good way to initialize the seed (for crypto). Time, process ID, etc
are guessable. And these days, the limited range of an F-Floating
mantissa is susceptible to a dictionary. <br>
<br>
Things are actually more complicated than this summary, but the
bottom line is that if it is slow on hardware, it will be slow on
SimH. And I'd look at what is happening during the hangs. The root
cause is likely getting enough randomness...<br>
<br>
<blockquote type="cite"
cite="mid:34367a6a-f66e-0a50-ffd4-2ac9854bbfb0@ieee.org">
<blockquote type="cite"
cite="mid:01QOEXWMH8M6005516@haven.vsm.com.au">
<pre wrap="">
I had hoped that in moving from a 100MHz VAX to a 1.2GHz SIMH VAX things
might improve, but they went dramatically backwards.)
Regards
Jeremy Begg
+---------------------------------------------------------+
| VSM Software Services Pty. Ltd. |
| <a class="moz-txt-link-freetext" href="http://www.vsm.com.au/" moz-do-not-send="true">http://www.vsm.com.au/</a> |
|---------------------------------------------------------|
| P.O.Box 402, Walkerville, | E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:jeremy@vsm.com.au" moz-do-not-send="true">jeremy@vsm.com.au</a> |
| South Australia 5081 | Phone: +61 8 8221 5188 |
|---------------------------| Mobile: 0414 422 947 |
| A.C.N. 068 409 156 | FAX: +61 8 8221 7199 |
+---------------------------------------------------------+
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>