[148569] in cryptography@c2.net mail archive
Re: [Cryptography] [IP] 'We cannot trust' Intel and Via's
daemon@ATHENA.MIT.EDU (ianG)
Sun Dec 22 01:51:46 2013
X-Original-To: cryptography@metzdowd.com
Date: Sun, 22 Dec 2013 09:36:44 +0300
From: ianG <iang@iang.org>
To: cryptography@metzdowd.com, Jerry Leichter <leichter@lrw.com>
In-Reply-To: <C1217AB3-FF61-4EFD-A9CE-25FAEA4C9D49@lrw.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 21/12/13 02:48 AM, Jerry Leichter wrote:
> On Dec 19, 2013, at 5:39 PM, Phillip Hallam-Baker <hallam@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.
This is a good point. Using RISC chips would be a substantial defence
against the attack that has been outlined (leaving aside the obviously
contentious debate as to whether the risk is serious).
What RISC CPUs are there these days in widespread deployment in
off-the-shelf general purpose computers?
> 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.)
If there was a way to reveal a signature of the PALcode, then it could
be checked against known good sigs. Just musing...
iang
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
