On Fri May 2 11:47:42 2025 +0000, Jinoh Kang wrote:
Probably doesn't matter short term, just curious if I was getting it right, since !283 would make clear-NT-at-iret redundant if my hypothesis is correct and possibly closer to native even. In any case, thanks for your work!
'iret' path hit in wine_syscall_dispatcher in the game is due to instrumentation callback (at least the case it was initially failing, not sure if it does that with NtSetContextThread or not somewhere later, I suppose it is better and not too hard to have all those paths fixed at once).
Probably doesn't matter short term, just curious if I was getting it right, since !283 would make clear-NT-at-iret redundant if my hypothesis is correct and possibly closer to native even.
I don't think this is the case. NT flag in the context is totally irrelevant for this MR (I realized that setting it in test in ctx.EFlags is misleading for this MR and only complicates the test without a reason, so I removed it in v2). Having NT flag set for the machine frame iret restores to is fine in terms that it doesn't fault now (your test shows that). The problem concerned here is when MR is set if eflags on syscall entry, then, iret will fault regardless of whether the flag is set or not in the machine frame.
As for native, I am guessing more likely real OS should necessarily sanitize the flags for its own execution on syscall entry while storing the original. Then, whether it returns with sysret (which is meant for basic syscall return but we can't use it because it is privileged) or maybe also iret for special cases (Linux does so), it will restore the original flags of course. We could in theory just do the same (sanitize on entry after saving original), but mind 'popf' before 'iret' (introduced by 50481d06d2763b02793f8d5362b512015987011f and required for proper single step exception address) which requires clearing NT flag before 'popf' anyway.