[Cryptography] [IP] 'We cannot trust' Intel and Via's chip-based crypto, FreeBSD developers say

[Jerry Leichter]

On Dec 19, 2013, at 5:39 PM, Phillip Hallam-Baker <hallam at gmail.com> wrote:

Off topic, but:
> Some chips have microcode on microcode. The DEC Alpha even let the operating system write instructions into the microcode (this allowed the chip to emulate the VAX four ring security system).
Alpha's were not microcoded.  The standard instructions were all implemented RISC-style.  What the Alpha had was a special privileged "PALcode" mode with complete access to the hardware.  It ran the same instruction set as "normal" code, though it had special instructions to get at model-specific features (hardware control registers, a mechanism to save and restore the non-PALcode state of the machine, etc.)

PALcode managed TLB refill, so it defined how the page tables worked - the hardware itself could only access pages for which there were active TLB entries.  It also implemented process context switching and the flow during interrupt/exception handling - including for "illegal" instructions, so PALcode could implement what looked to the software like instructions.  (This idea, of course, goes way, way back - and, yes, this kind of looks like a microcoded instruction.)  In practice, there was a reserved op code (CALL_PAL - instruction code 0) that was used for PALcode instructions.  Yes, the PALcode implemented four access rings for VMS (and two for OSF/1), but that's a matter of controlling TLB's and deciding what to do with "privileged" PALcode calls:  All the hardware-defined instructions were non-privileged.

OS's didn't, as far as I know, load PALcode.  Rather, the PALcode needed to support a particular OS was loaded before the OS was loaded.  PALcode *could* provide a way for an OS to change the code later, but I don't think any standard variant did.  (Keep in mind that even the OS couldn't touch the perfectly ordinary system memory where the PALcode resided unless the PALcode consented to fill a TLB entry to map that memory - which I very much doubt the standard PALcode would ever do.)
                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131220/b26d5a1f/attachment.bin>