This repository has been archived on 2020-12-06. You can view files and clone it, but cannot push or open issues or pull requests.

Michael Brown cc9f31ee0c [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>		2016-03-12 12:39:17 +00:00
..
liba20.S	[bios] Add bin-x86_64-pcbios build platform	2016-02-16 19:32:32 +00:00
libkir.S	[bios] Add bin-x86_64-pcbios build platform	2016-02-16 19:32:32 +00:00
libpm.S	[bios] Add bin-x86_64-pcbios build platform	2016-02-16 19:32:32 +00:00
librm.S	[librm] Do not unconditionally preserve flags across virt_call()	2016-03-12 12:39:17 +00:00
librm_mgmt.c	[librm] Support ioremap() for addresses above 4GB in a 64-bit build	2016-02-26 15:34:28 +00:00
librm_test.c	[librm] Rename prot_call() to virt_call()	2016-02-22 00:50:32 +00:00