{"push_id":1017789696,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"cc9f31ee0cfd4ef9cf05ef0621fc933814489b3d","before":"64acfd9ddd73bf38802f8c57e054d13a57b14198","commits":[{"sha":"cc9f31ee0cfd4ef9cf05ef0621fc933814489b3d","author":{"email":"67f92fe466c1cf7071cd98d44dd3637d867a9144@ipxe.org","name":"Michael Brown"},"message":"[librm] Do not unconditionally preserve flags across virt_call()\n\nCommit 196f0f2 (\"[librm] Convert prot_call() to a real-mode near\ncall\") introduced a regression in which any deliberate modification to\nthe low 16 bits of the CPU flags (in struct i386_all_regs) would be\noverwritten with the original flags value at the time of entry to\nprot_call().\n\nThe regression arose because the alignment requirements of the\nprotected-mode stack necessitated the insertion of two bytes of\npadding immediately below the prot_call() return address.  The\nsolution chosen was to extend the existing \"pushfl / popfl\" pair to\n\"pushfw;pushfl / popfl;popfw\".  The extra \"pushfw / popfw\" appears at\nfirst glance to be a no-op, but fails to take into account the fact\nthat the flags restored by popfl may have been deliberately modified\nby the protected-mode function.\n\nFix by replacing \"pushfw / popfw\" with \"pushw %ss / popw %ss\".  While\n%ss does appear within struct i386_all_regs, any modification to the\nstored value has always been ignored by prot_call() anyway.\n\nThe most visible symptom of this regression was that SAN booting would\nfail since every INT 13 call would be chained to the original INT 13\nvector.\n\nReported-by: Vishvananda Ishaya <vishvananda@gmail.com>\nReported-by: Jamie Thompson <forum.ipxe@jamie-thompson.co.uk>\nSigned-off-by: Michael Brown <mcb30@ipxe.org>","distinct":true,"url":"https://api.github.com/repos/ipxe/ipxe/commits/cc9f31ee0cfd4ef9cf05ef0621fc933814489b3d"}]}