[Simh] VMS multinet DHCLIENT/SSH2 configuration problem

[Timothe Litt]

On 28-Jan-18 18:04, Timothe Litt wrote:
>
> On 28-Jan-18 17:21, Jeremy Begg wrote:
>> Hi TIm,
>>
>>> ...
>>> 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.
>> 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.
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Anyhow, FP would not be the first place I'd look.
>
>> (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.
This supports the guess that the issue is more likely to be generating
random bits than the speed of FP emulation.

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. 

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...

>> 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.              |
>>   |                 http://www.vsm.com.au/                  |
>>   |---------------------------------------------------------|
>>   | P.O.Box 402, Walkerville, |  E-Mail:  jeremy at vsm.com.au |
>>   | South Australia 5081      |   Phone:  +61 8 8221 5188   |
>>   |---------------------------|  Mobile:  0414 422 947      |
>>   |  A.C.N. 068 409 156       |     FAX:  +61 8 8221 7199   |
>>   +---------------------------------------------------------+
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180128/a4cf3aff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4577 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180128/a4cf3aff/attachment-0001.bin>