Maynard Handley (name99.delete@this.name99.org) on December 11, 2018 7:20 am wrote:
> Howard Chu (hyc.delete@this.symas.com) on December 11, 2018 4:17 am wrote:
> > Adrian (a.delete@this.acm.org) on December 1, 2018 10:05 pm wrote:
> > > Adrian` (a.delete@this.acm.org) on December 1, 2018 2:43 pm wrote:
> > >
> > > > some problems), but I cannot verify that, so I would never trust it. I trust Intel even less than AMD.
> > > >
> > > >
> > >
> > >
> > > I have not made it clear here, but the fact that I do not trust Intel about security issues does
> > > not come from any kind of prejudice, but it is a simple consequence of Intel's actions.
> > >
> > >
> > > The case of the Optane memories is a new example that it is absolutely impossible to trust Intel
> > > about security, because they are either at best completely incompetent or at worst malevolent.
> > >
> > >
> > > When they planned the processor support for Optane DIMMs,
> > > the first feature that should have been added before
> > > anything else is memory encryption. Instead of doing so, Intel
> > > reluctantly announced support for memory encryption
> > > in some future processors, possibly only in server processors, and only after AMD forced their hand.
> > >
> > >
> > > Only the most amateurish of the security amateurs could not
> > > have been aware that non-volatile memory encryption
> > > is a sine qua non feature. Such an omission is hard to
> > > explain in a company of the size of Intel, unless you
> > > believe the conspiracy theories that they really are trying to actively add backdoors in their products.
> > >
> > >
> > > Of course like in any large company, among Intel's employees there are a lot of very good
> > > professionals who do great things, but about security I do not remember anything but a long
> > > list of horrible blunders, since the introduction of 80386SL in 1990 and until now.
> >
> > Will definitely be interesting to follow this issue going forward. It looks like
> > MRAM is poised to replace SRAM for on-chip caches, down the road. Encrypting cache
> > contents would quite impractical.
>
> The crypto has to be appropriate to the problem. This is NOT the equivalent of network crypto.
> For example, suppose the equivalent of a random key burned into the device is XOR'd with everything
> going into and out of an MRAM cache (maybe also XOR-in the relevant addresses).
> Is that good enough? On the off-chance that someone could extract the contents
> of the MRAM cache (which may or may not be true?) the assumption is always
> that they CANNOT extract the contents of these sorts of hardware keys.

I guess that would work if doubled the size of all the caches (to store the cryptostream) and created the cryptostream for each cacheline (at a specific memory location) as it was read in from memory. You would then pass the cryptostream along with the data up and down the levels as needed. It would need twice the size and twice the bandwidth, but I suppose that if you have non-volitile cache somebody will want an encrypted cache (too easy to read out the non-volitile cache otherwise). Note that the encryption stream is still non-volitile and cleartext, and always in danger of someone physically attacking the chip

Still sounds bizarre (although not as slow as I thought, since all the encryption rounds have to happen during a memory read/cacheline initialization). Maybe some sort of niche design that an ARM server would be good for.