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

  • Author
  • joseph.h.garvin
    Post count: 21
    #3557 |

    These researchers are claiming that the Meltdown and Spectre vulnerabilities were misunderstood, and that the real cause is speculative dereferencing of user space registers. I have not read the paper yet but the article that linked me to it, suggest that it may only be possible when you have a separate address space for user space and kernel so I’m curious if the Mill would be vulnerable.

    Also just wondering how you all are doing and how things are progressing 🙂 I miss having a constant influx of new Ivan talks to watch 😉

  • 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.

You must be logged in to reply to this topic.