[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Linux'es ESPFIX


  • To: "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: "Jan Beulich" <JBeulich@xxxxxxxx>
  • Date: Thu, 08 Jan 2015 14:41:35 +0000
  • Delivery-date: Thu, 08 Jan 2015 14:41:52 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

All,

after having decided with the rest of the security team that we ought
to be dealing with this in public considering it's been public on the Linux
side for quite a while, here's an issue we should try to find a solution
for, or decide whether a partial solution like Linux is using (see below)
is sufficient: IRET back to a 16-bit segment updates only SP (i.e. only
the low 16 bits of RSP), both corrupting what may have been put there
(mostly relevant only for 16-bit code using a 32-bit stack pointer, as
e.g. Wine is reported to be doing) and leaking the prior kernel (or
hypervisor in our case) value.

Linux not so long ago invented a mechanism to deal with bits 16..31
(setting up mini stacks and mapping them 64k times, picking the
appropriate one to restore the original value in those bits), but that
doesn't deal with the (more remote but still possible afaict) leak
through bits 32..63. As a follow-up to a query to understand the
full background here, I asked H. Peter Anvin about this remaining
leak but didn't get any response so far.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.