Hi Andrew,

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 PUSHn.

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 optional parameter...

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 individual PUSHes)...



edk2-devel mailing list

Reply via email to