Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unexpected Page Fault In Virtualized Environment Advisory

intel.com

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Unexpected Page Fault In Virtualized Environment Advisory

#31

Post by monocasa »

sillysaurusx wrote: post #29
thu2111 wrote: post #13

Earlier quoted context omitted.

Is that actually better in this case? Intel found the issue internally. Nobody knows what it is. The advisory isn't sufficient information to figure it out. People can patch at their leisure, fairly sure that nobody is about to pop up with a 1-day exploit for it. With an open source CPU, by now someone would have looked at the commits that fixed the Verilog/microcode, figured out what the bug is, and there'd be a con…

Is that actually better in this case? Intel found the issue internally. Nobody knows what it is. The advisory isn't sufficient information to figure it out. People can patch at their leisure, fairly sure that nobody is about to pop up with a 1-day exploit for it. That's pretty bad, actually. It means a determined adversary can simply look at the patch to figure out how to exploit vulnerable systems. (Presumably there…

They're encrypted with a key that's shipped on every processor they ship. A combo of classic espionage and electron microscopes means that we should assume state actors can know the exact mechanism of microcode update changes.

Re: Unexpected Page Fault In Virtualized Environment Advisory

#32

Post by sillysaurusx »

monocasa wrote: post #31
sillysaurusx wrote: post #29

Earlier quoted context omitted.

Is that actually better in this case? Intel found the issue internally. Nobody knows what it is. The advisory isn't sufficient information to figure it out. People can patch at their leisure, fairly sure that nobody is about to pop up with a 1-day exploit for it. That's pretty bad, actually. It means a determined adversary can simply look at the patch to figure out how to exploit vulnerable systems. (Presumably there…

They're encrypted with a key that's shipped on every processor they ship. A combo of classic espionage and electron microscopes means that we should assume state actors can know the exact mechanism of microcode update changes.

Thanks! In that case, they seemed to have a good point: if it was an open source CPU, it seems like security might be an issue.

One way to do it: ship security updates using the same technique as intel, and don't release the source code for the fix until much later. I think I remember an open source project doing something similar. But of course, it seems pretty hard to manage that complexity: what if the fix introduces code changes that future commits depend on?

Interesting problem...

Re: Unexpected Page Fault In Virtualized Environment Advisory

#33

Post by cortesoft »

throwawaymath wrote: post #26
cortesoft wrote: post #18

Earlier quoted context omitted.

Isn't that a pretty standard bug bounty requirement? The idea is that you submit the bug to the company and they fix it before it is disclosed.

It is standard in the sense that it's not uncommon. But about as frequently it's not a requirement. Many companies allow complete or partial vulnerability disclosure once resolution is complete. It's often on a case by case basis and requires approval.

Oh, I thought that was what you meant (until resolution).. didn't realize they block disclosure forever

Re: Unexpected Page Fault In Virtualized Environment Advisory

#34

Post by erk__ »

strstr wrote: post #9

Anyone know what conditions are required? The advisory is sparse on details. The errata lists the same vague info: https://www.intel.com/content/dam/www/public/us/en/documents...

>November 2910

They seem to have gotten information about the bug from the future :P

This could also show that trhey released it in a hurry since they did not fix that typing mistake.

Re: Unexpected Page Fault In Virtualized Environment Advisory

#35

Post by dnautics »

xvector wrote: post #21
dmead wrote: post #15

Earlier quoted context omitted.

IIRC intel stopped doing as much validation like 10ish years ago (so, 2009/2010). it would be nice to see then publish a paper about how those decisions lead into these problems...

Intel willingly admitting mistakes is just about as likely as hell freezing over

It really is. I got hit pretty bad by an ubuntu intel-microcode package regression, which has this annoying property that soft reboots fail (and hard reboots are fine). I lost about 3 days of work to this[0], and our mitigation (pinning the package to an earlier version) is still painful, because you have to go through one OS installation cycle and still manually reboot (we do a lot of manual OS installations, and debugging "first installs").

Anyways I was bitching about this to my roommate, and she remarked that hey you know acquaintance X we know works in Intel software security division. I told her to give him crap about it and apparently his response was something like "we should have closed comments on that github issue". I feel like this is not a really appropriate response, even between friends.

AFACIT the package still hasn't been fixed and the official ubuntu solution is to roll back to the nonbroken version.

[0] admittedly slightly poor internal communication is also responsible, since this was observed by our support staff for our customers which didn't make it known to R&D - me

Re: Unexpected Page Fault In Virtualized Environment Advisory

#36

Post by ars »

erk__ wrote: post #34
strstr wrote: post #9

Anyone know what conditions are required? The advisory is sparse on details. The errata lists the same vague info: https://www.intel.com/content/dam/www/public/us/en/documents...

>November 2910 They seem to have gotten information about the bug from the future :P This could also show that trhey released it in a hurry since they did not fix that typing mistake.

It's not a typo, it's in Middle-endian format. :)

Re: Unexpected Page Fault In Virtualized Environment Advisory

#37

Post by klyrs »

sillysaurusx wrote: post #32
monocasa wrote: post #31

Earlier quoted context omitted.

They're encrypted with a key that's shipped on every processor they ship. A combo of classic espionage and electron microscopes means that we should assume state actors can know the exact mechanism of microcode update changes.

Thanks! In that case, they seemed to have a good point: if it was an open source CPU, it seems like security might be an issue. One way to do it: ship security updates using the same technique as intel, and don't release the source code for the fix until much later. I think I remember an open source project doing something similar. But of course, it seems pretty hard to manage that complexity: what if the fix introdu…

I'm by no means an expert, but open design and verification of secure enclaves seems quite feasible -- keys would differ between different chip makers, I imagine. Folks could write patches, but perhaps not sign them for hardware they own. Though I'd expect most maintainers to work with the community to get bugs fixed.

Re: Unexpected Page Fault In Virtualized Environment Advisory

#38

Post by ShroudedNight »

dmead wrote: post #15
sp332 wrote: post #10

Earlier quoted context omitted.

AMD never had one as boneheaded as Meltdown. Intel keeps having more and more uncovered, and according to researchers who went on the record in the NYT, they are not handling reported vulnerabilities quickly or thoroughly. https://www.nytimes.com/2019/11/12/technology/intel-chip-fix...

IIRC intel stopped doing as much validation like 10ish years ago (so, 2009/2010). it would be nice to see then publish a paper about how those decisions lead into these problems...

My understanding is that chip QA at Intel took somewhat of a nosedive post Haswell. From my ignorant but interested outsider perspective, everything from Broadwell on seemed to be a mess execution-wise compared to Haswell (modulo TSX), and _especially_ compared to Ivy Bridge.

Some of the recorded comments on https://danluu.com/cpu-bugs/ (First update section) mesh with my observations, but I wouldn't know enough to tell if I was on to something, or just confirming my own biases.

Re: Unexpected Page Fault In Virtualized Environment Advisory

#39

Post by hinkley »

ars wrote: post #36
erk__ wrote: post #34

Earlier quoted context omitted.

>November 2910 They seem to have gotten information about the bug from the future :P This could also show that trhey released it in a hurry since they did not fix that typing mistake.

It's not a typo, it's in Middle-endian format. :)

It looks more like a concurrency bug to me.

Re: Unexpected Page Fault In Virtualized Environment Advisory

#40

Post by hinkley »

monocasa wrote: post #24
vajrabum wrote: post #8

Earlier quoted context omitted.

I'm pretty sure that high performance open source CPUs will have their own obscure problems. Too much complexity, too many dependencies, too many possible feature interactions.

They will, but you'll be able to understand the problem, the fix, and how it combines with other fixes. I can def see a world soon where all of Intel's woes have combined to the point that they've run out of patch space for their microcode updates, and you have to pick and choose what you want mitigations for.

"Good news, our brand new processor has twice as much space for microcode as the old versions!"
Post reply on HN