[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Linux'es ESPFIX
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |