FWIW I see nothing about Meltdown that requires OoO execution to leak data. The exact same approach should work on in-order cores that have caches and branch prediction. (Read, basically all but the tiniest microcontrollers.)
-
Show this thread
-
NB this is talking about the underlying problem of "discarded speculative execution paths have observable effects on committed paths". The specific vuln here (continuing speculation after reading kernel mem from user space) is definitely fixable.
4 replies 1 retweet 15 likesShow this thread -
(One approach: check protection bits earlier and make sure that data returned from cache access path on exception-generating reads is 0, not "garbage" [usually "whatever is there"] so no privileged info leaks into the dataflow.)
4 replies 2 retweets 16 likesShow this thread -
Replying to @rygorous
Doesn't seem like they can fix it in microcode though, at least, that's my assumption, given that OSes are being modified instead.
1 reply 0 retweets 0 likes -
Replying to @Scalibq
of course they can't fix it in microcode. People have totally wrong ideas about what microcode is. _This is not a bug in microcoded sequences_. (Which is almost none of the code the CPU runs.)
3 replies 0 retweets 4 likes -
Just curious, since you know things: there was a firmware (microcode?) update to fix the Skylake/Kaby Lake hyperthreading crashes with high byte registers, right? Any idea how that could have been fixable?
1 reply 0 retweets 0 likes -
If a bug is fixable in microcode, that means it's triggered by one or more of: 1) a ucoded instr (there aren't many, and most are privileged) 2) an internal, non-architectural fault in the core (e.g. FP specials) 3) an architectural exception 4) an interrupt
2 replies 0 retweets 3 likes -
can't you flip chicken bits using "microcode updates", even if that's not strictly speaking microcode?
1 reply 0 retweets 2 likes -
Via BIOS updates etc. yes, and it's true that these are often conflated with ucode updates.
1 reply 0 retweets 2 likes
Jann Horn Retweeted Alex Ionescu
and https://lkml.org/lkml/2018/1/4/615 … / https://twitter.com/aionescu/status/948983847672102912 … / https://twitter.com/aionescu/status/948753795105697793 … / https://twitter.com/aionescu/status/948750715844898817 … sounds like microcode can flip chicken bits, or change MSR availability, or something vaguely like that?
Jann Horn added,
-
-
@rygorous actually Intel Atom's Bonnell microarchitecture is immune to that attack precisely because it is In-Order. BIOS updates often come with uCode update packages part of them. If an MSR is a 'test register' or normally 'hidden' in retail, a uCode update is needed to expose.1 reply 0 retweets 3 likes -
I've seen Lenovo T470 bios update referencing var2 cve few days ago...
0 replies 0 retweets 0 likes
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.