[librm] Do not unconditionally preserve flags across virt_call()
authorMichael Brown <mcb30@ipxe.org>
Sat, 12 Mar 2016 12:39:17 +0000 (12:39 +0000)
committerMichael Brown <mcb30@ipxe.org>
Sat, 12 Mar 2016 12:39:17 +0000 (12:39 +0000)
commitcc9f31ee0cfd4ef9cf05ef0621fc933814489b3d
tree8ddce36152aa0ade33b80aba9f451770025ce5ce
parent64acfd9ddd73bf38802f8c57e054d13a57b14198
[librm] Do not unconditionally preserve flags across virt_call()

Commit 196f0f2 ("[librm] Convert prot_call() to a real-mode near
call") introduced a regression in which any deliberate modification to
the low 16 bits of the CPU flags (in struct i386_all_regs) would be
overwritten with the original flags value at the time of entry to
prot_call().

The regression arose because the alignment requirements of the
protected-mode stack necessitated the insertion of two bytes of
padding immediately below the prot_call() return address.  The
solution chosen was to extend the existing "pushfl / popfl" pair to
"pushfw;pushfl / popfl;popfw".  The extra "pushfw / popfw" appears at
first glance to be a no-op, but fails to take into account the fact
that the flags restored by popfl may have been deliberately modified
by the protected-mode function.

Fix by replacing "pushfw / popfw" with "pushw %ss / popw %ss".  While
%ss does appear within struct i386_all_regs, any modification to the
stored value has always been ignored by prot_call() anyway.

The most visible symptom of this regression was that SAN booting would
fail since every INT 13 call would be chained to the original INT 13
vector.

Reported-by: Vishvananda Ishaya <vishvananda@gmail.com>
Reported-by: Jamie Thompson <forum.ipxe@jamie-thompson.co.uk>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
src/arch/x86/transitions/librm.S