
Xen Security Advisory: x86 – mishandling of debug exceptions - ingve
https://xenbits.xen.org/xsa/advisory-260.html
======
amluto
This is an issue affecting many operating systems. Linux could be DoSed. Xen
PV, Windows, Mac OS, and several BSD variants were vulnerable to privilege
escalation.

[http://www.openwall.com/lists/oss-
security/2018/05/08/4](http://www.openwall.com/lists/oss-
security/2018/05/08/4)

[https://news.ycombinator.com/item?id=17023531](https://news.ycombinator.com/item?id=17023531)

------
userbinator
This reminds me of the bug in very early 8086/8088 which didn't disable
interrupts when switching the stack segment:

[https://trixter.oldskool.org/2007/03/17/post-something-
dammi...](https://trixter.oldskool.org/2007/03/17/post-something-dammit/)

[https://www.pcjs.org/pubs/pc/reference/intel/8086/](https://www.pcjs.org/pubs/pc/reference/intel/8086/)

[http://www.malinov.com/Home/sergeys-projects/sergey-s-
xt/his...](http://www.malinov.com/Home/sergeys-projects/sergey-s-
xt/historical-notes)

~~~
strstr
Isn't this why MOVSS interrupt shadowing exists?

~~~
yuhong
They didn't even do the LSS instruction until the 386.

------
0x0
Apparently this was already patched in the previous macOS security update, but
Apple updated the documentation for it with additional references to this bug
only just today. I've seen them do these documentation updates a few times
now, is that a recent thing? Isn't it kind-of breaking embargoes if a binary
security update goes out weeks before the vulnerability is documented in
public? Not sure if it's a good or bad thing... happy to be already protected,
but concerned about installing updates which aren't fully documented on
release and which might let bad guys discover issues early?

~~~
duskwuff
> Isn't it kind-of breaking embargoes if a binary security update goes out
> weeks before the vulnerability is documented in public?

Sort of. But it's a balancing act -- if you delay the release of a fix until
the day of disclosure, users are all vulnerable _to a known exploit_ until
they patch. If you release a patch before public disclosure, chances are much
better that users will update before the vulnerability is disclosed, either
officially or through reverse-engineering of the patch.

------
strstr
This is reminiscent of the #TF CVE from last year:
[https://bugzilla.redhat.com/show_bug.cgi?id=1464473](https://bugzilla.redhat.com/show_bug.cgi?id=1464473)

... Except not requiring a buggy instruction emulator.

Traps and MOVSS shadowing (and any other temporary state after an instruction
pointer increment) are very complex/bug prone, and I kinda wish x86 weren't so
willing to keep adding these in (recent additions that come to mind being MTF
and PEBS).

------
yuhong
It is funny how poorly designed AMD's SYSCALL seems to be compared to Intel's
SYSENTER. As a side note, I have been thinking of the removal of segmentation
from x86 for a while now.

~~~
userbinator
IMHO the whole amd64 was poorly designed. A misguided attempt at "cleaning up"
the architecture by removing features that actually turn out to be quite
useful and in active use, so much that they had to put some of those features
back in later revisions (with feature bits, creating further mess):

[https://www.pagetable.com/?p=25](https://www.pagetable.com/?p=25)

[https://github.com/dynamorio/dynamorio/issues/181](https://github.com/dynamorio/dynamorio/issues/181)

Especially in the case of LAHF/SAHF, it's not like they reused the opcode for
something else --- since amd64 processors must be able to execute 16 and
32-bit code, the circuitry required to execute those instructions is there and
perfectly functional; they just inexplicably become invalid in 64-bit mode.
AMD could've made it far more seamless and compatible; instead they seemingly
ripped stuff out without much consideration of what could be depending on it,
hence the strange invalidation of certain instructions and the absurd semi-
presence of segmentation.

For example, they could've made segmentation disappear completely (and
certainly break more applications...) in 64-bit mode, reassigning all the
opcodes related to their usage, etc.; or they could've fit 64-bit segments
into the existing segmentation model, but the current "segmentation half-
working" state is just bizarre.

~~~
yuhong
My favorite is features from IA-64 that had to be ported to AMD64 after the
fact. For example, IA-64 had two stacks. Before SYSCALL was fixed for AMD64,
it was so poorly designed that the only OS I know supporting it was XP pre-
SP2.

~~~
duskwuff
> features from IA-64 that had to be ported to AMD64 after the fact

I'm not sure what you mean by this. IA-64 was Itanium. While it did have two
stacks, that feature never existed on either vendor's implementation of
x86-64.

~~~
yuhong
Intel CET I believe.

------
phyller
Would anyone mind providing some context for those of us not familiar with
running enterprise grade cloud services?

~~~
organicmultiloc
I don't think you need a ton of context, it looks like a straighforward
exploit for breaking out of a VM on Xen, affects most (all?) operating
systems.

