[Cryptography] RAM memories as one source of entropy

[Dennis E. Hamilton]

RE: Jerry Leichter
Sent: Saturday, February 15, 2014 11:28
Subject: Re: [Cryptography] RAM memories as one source of entropy

On Feb 15, 2014, at 1:56 PM, Theodore Ts'o wrote:
> IBM Power servers may have already beaten you to this.  Indeed, with
> the publically available interfaces, it is impossible to get access to
> the raw CPU; the BIOS is always running as a hypervisor.
One might argue that the Burroughs "Algol" machines of the 1960's were way ahead on this.  (The lowest level documented interface was a simplified/extended for systems programming purposes form of Algol.)

REPLY:
Umm, not so fast.  The hardware instruction set of the B5000/5500 was known.  There were ways to use it, even though this is probably the first machine where "assembly language" was not the common choice for good-performance programming. I have never examined ESPOL to see how it extends versus diverges from its ALGOL inspiration -- there were features in the hardware that seem to have impeded full handling of ALGOL.  ESPOL was definitely the software-development language of choice, but ALGOL (and COBOL) were the preferred application-development languages, as I recall.  Considering the machine architecture, ESPOL would be to the hardware essentially like the relationship of C Language its typical platforms.

I agree that all of the process isolation probably prevented access to the "sources" that one would require for some sort of entropy gathering.  That might not be an absolute limitation, but the fact that they are server systems also limits what kinds of peripheral activities one might be able to rely upon.

 - Dennis

FURTHER MUSINGS

The architectures had three innovative qualities that are now achieved differently: (1) Use of reverse-polish and a pushdown stack for evaluation, (2) use of descriptors and tagged memory for data access that provided both typing and a basis for memory protection, data relocation, garbage collection, and swapping to a backing store and (3) use of a procedure invocation and instruction-sequence mechanism that achieved pure procedures, re-entrance, and dynamic handling of procedural scoping (though not quite what Algol required to work perfectly).  

As the architectures were extended and grown, there was an amazing amount of performance improvement by caching of various kinds, along with other support for multiple processors and shared memory.  The use of microcode is also a big factor.

The current Unisys Clearpath systems seem to preserve those ideas, now including ability to present different microcoded/emulated/virtualized hardware architectures (including native Java Machine) to running applications.  Emulation is often done atop multi-processors on Intel these days.  There is a developer's version that runs on Windows 7.  The Master Control Program (MCP) that was built as the operating system and service stack atop the B5000 (the first commercial OS written entirely in non-assembly system-programming language, ESPOL) survives.  ESPOL itself survives as the language NEWP. 

Finally, when ALGOL is mentioned, it is the Burroughs/Unisys version, not the ALGOL standard.  NEWP is not a superset but a subset with additional extensions for system development.  There are some pretty-low-level primitive operations.

 - dh