Mill Computing, Inc. Forums The Mill Architecture New class of side-channel vulnerability based on speculation of user space regis Reply To: New class of side-channel vulnerability based on speculation of user space regis

Ivan Godard
Post count: 689

The paper is a valuable contribution to the analysis of the security defects of legacy ISAs. It’s not clear what x86 and friends can do about the reported vulnerability, other than disabling run-ahead speculation completely, and pay the performance cost. However, I’m no x86 expert and there may in fact be some clever mitigation that will be available in the next ping cycle or two.

As for Mill, the short answer is “inherently immune”. The long answer is that Mill has no kernel state that can read all of physmem at will.

The paper is greatly concerned with the fact that the kernel is mapped into the same address mapping as the user image; by finding cases where the user virtual address matches a kernel virtual address and trigger a speculative kernel reference, the user can cause the secret to get moved to the L1 whence established exploits can exfiltrate it at useful bitrates. Mill actually makes the problem easier, because Mill uses a Single Shared Address Space model, with the caches in virtual. Consequently the attacker doesn’t need to coax the kernel mapping to match the attacker’s; they are the same a priori.

But things end there. Mill does not do speculative state update. Hence even giving the kernel (if there were such a thing) an attacker (or kernel) address, while it can initiate a load, no state gets updated, in cache or elsewhere, until the load passes protection check.

It is true that a user can initiate a load (valid in the user’s permissions) and then call (or get interrupted into) a different process, and that load may complete in the background and its result be made available after the call/interrupt returns. But the load is marked with the initiator, and the called code can’t see it. Of course, assuming the load was valid for the loader it will as a side effect update cache and other state in a way that is visible to to the callee; this is no different than a caller seeing the presence state of the caches after whatever work the caller had done. But there’s no way for either side to control what the other loads, because there’s no speculation.

Everyone in the security world knows that the only real security would come from avoiding all speculation. The only real difference between Mill and any other ISA is that the Mill avoids speculation in a cost-effective way.