You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 5, 2021. It is now read-only.
More articles I am reading , the more confused I am. Many articles say that speculative execution and out-of-order execution leads to these vulns. I don't think so, because I find that exploiting either of these two vulns to leak kernel addressspace is nearly possible, except for the situation that the target kernel address is cached in L1.
So it seems in fact it's because that the memory load operation from L1 cache didn't carry the privilege verification quite well . Am I understanding right?
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
More articles I am reading , the more confused I am. Many articles say that speculative execution and out-of-order execution leads to these vulns. I don't think so, because I find that exploiting either of these two vulns to leak kernel addressspace is nearly possible, except for the situation that the target kernel address is cached in L1.
So it seems in fact it's because that the memory load operation from L1 cache didn't carry the privilege verification quite well . Am I understanding right?
The text was updated successfully, but these errors were encountered: