On 2016.09.22 21:27, Andrew Fish wrote:
It seems like tracking the PUSHes would work?
First of all, as got pointed out by Ard, I need to mention that much of
my earlier analysis results, which you quoted, were due to a misread of
the specs, as it does mandates pushing 32 bit parameters as native.
So the output I gave for AARCH64 and X64 was erroneous, since it was a
result of using PUSH32, and the problematic output disappears when using
The only issue therefore, is with 32 bit ARM.
We could update the spec to require this behavior.
If the idea is to add the tracking when processing POP/PUSH on Arm
(which is how I originally saw it), please note that we may also have to
track stack manipulation with MOV against R0, the EBC stack pointer, if
someone issues something like 'MOV R0, R0(-1,0)' (equivalent to PUSHn)
or 'MOV R0, R0(0,-8)' (equivalent to PUSH64) for some 32 or 64 bit
However, this brings us back to our original issue if there exists a
succession of optional 32 and 64 bit parameters, which the application
doesn't care about filling, and that may be handled with a single 'MOV
R0, R0(-1,-8)' in the assembly. If we are faced with this in our
tracking, then we still have no way of knowing which of the 32 or 64 bit
parameter comes first.
So, notwithstanding other issues, we'd have to mandate something very
specific against doing this in the UEFI/EBC specs (such as only using
edk2-devel mailing list