[Info-vax] Software does wear out, was: Re: Raid Controller in I64 ans Alpha(MSA$UTIL)

[John E. Malmberg]

On 12/1/2013 4:56 PM, David Froble wrote:
> Simon Clubley wrote:
>> On 2013-11-30, David Froble <davef at tsoft-inc.com> wrote:
>>> Simon Clubley wrote:
>>>> On 2013-11-26, David Froble <davef at tsoft-inc.com> wrote:
>>>>> If you can assume that VMS is working today, no problems, then I
>>>>> feel that it is a safe assumption that it will work the same
>>>>> tomorrow. Software doesn't wear out.
>>>>>
>>>> Tut, tut. I expected better from you... :-)
>>> Ok, let's discuss it.  I sometimes like a challenge ...
>>>
>>
>> $ set response/mode=good_natured
>>
>> Ok, have a think about the following issues: :-)
>>
>>>> Software most certainly _can_ wear out in at least one form:
>>> If it does something today, it will do the same thing tomorrow.  I
>>> stand by that statement.
>>>
>>
>> Not always true. What happens when you hit some internal date/time
>> limit you might not have been aware of ?
>>
>> For example, the 19-May-1997 10,000 day limit (which was a pure VMS
>> problem) or when you start storing dates past 19-Jan-2038 in a signed
>> 32-bit integer with a 1970 base ?
>>
>> BTW, time_t is the perfect example of something which should have been
>> unsigned from day 1. (I think I may have mentioned one or twice my
>> opinions on defaulting to signed integers unless required. :-))
>>
>>>> What happens when someone comes along with a new exploit for your
>>>> networking stack or even in VMS itself and there's no one around
>>>> to fix it ?
>>> A very valid concern.  However, there could be multiple answers to
>>> such problems.
>>>
>>> If you are on an emulaltor, it's possible to control anything going
>>> to or from VMS.  Actually, from the virtual machine running VMS, to
>>> be percise.  Not saying that it would be optimal or easy.
>>>
>>
>> Not so easy.
>>
>> To pick a simple example (just to demonstrate the type of issue I am
>> thinking of), imagine you _need_ a SMTP server running on your VMS box
>> as part of your application workflow.
>>
>> Now imagine someone finds a exploit, triggered by, say, a specific
>> command
>> sequence or parameter format, which allows your SMTP server to do things
>> it must _not_ be allowed to do. [*]
>>
>> You now have to implement a method which allows your SMTP server to
>> continue to operate as normal for your application workflow, but blocks
>> the specific SMTP level sequence exploit.
>>
>> How do you do this when you can't get someone to fix your SMTP server
>> because VMS is no longer supported by HP ?
>>
>> You can't block SMTP at firewall level because the SMTP server is
>> required
>> as part of your application workflow. You may be able to get someone to
>> modify your firewall to do deep packet inspection (DPI) on the SMTP
>> packets,
>> but, depending on the specific exploit, that could still be tricky.

TCP protocols can usually be proxied through services or boxes that can 
do those types of checks.

In particular, SMTP can easily be proxied through a device that 
hopefully is secure.

>> You can't do it in a normal emulator however, because the emulator (with
>> some basic exceptions such as idle loop detection) emulates a machine
>> without any deep knowledge of what is running on that emulated machine.

That is a poor emulator.  A good emulator knows how to short-circuit 
stuff on the emulated machine.

This is usually done by installing paravirtualized drivers on the 
emulated machine, or other modifications to the OS to detect the 
emulator and cooperate with it.  A variation of the idle loop detection.

But an emulator can also do cached JIT compiling to get the same thing 
done.  Or a combination of the two techniques.

This allows offloading Kernel mode code actually run native on the 
emulator host instead of emulation.

More advanced, if you can tightly couple the VMS 
SYSUAF/Rightslist/External Authentication with the emulator host user 
security, then you can provide a way for user mode native images to be 
launched from the emulated system.

It would be an interesting thing to add to SimH/VAX.

Regards,
-John
wb8tyw at qsl.network
Personal Opinion Only