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>tags/v1.20.1
|
||
940 | 940 |
|
941 | 941 |
|
942 | 942 |
|
943 |
|
|
943 |
|
|
944 | 944 |
|
945 | 945 |
|
946 | 946 |
|
|
||
1030 | 1030 |
|
1031 | 1031 |
|
1032 | 1032 |
|
1033 |
|
|
1033 |
|
|
1034 | 1034 |
|
1035 | 1035 |
|
1036 | 1036 |
|