On 10/16/22 17:33, Rémi Bernon (@rbernon) wrote:
On Sun Oct 16 22:04:22 2022 +0000, **** wrote:
Zebediah Figura replied on the mailing list:
Regarding "[PATCH 08/13] ntdll: Allocate a truly separate stack for the kernel stack.": Why do we need to do this? Specifically, do we know why this is broken in Valgrind? I ask because I would guess a priori that this should be fixed on the valgrind side. Valgrind should have all of the information regarding our stacks, so I wouldn't expect it to need to resort to heuristics.Valgrind keeps track of the stack pointer changes (some of them at least), to update the memory attributes below it and figure invalid and uninitialized memory accesses. It detects shrinking and growing stacks when the stack pointer stays within the registered "stack" region, and in our case this currently includes both the user and the kernel stack.
Our syscalls are updating the stack pointer from a lower, user stack, address to a higher, kernel stack, address, effectively shrinking the stack by a large amount, then accessing the syscall parameters from the lower address to copy them to the kernel stack. Valgrind doesn't like that, and even complains that we're likely switching stacks.
Having two separately allocated stacks is 1) much cleaner anyway, and 2) allows Valgrind to correctly track the two separate stack pointers (though it still complains in some cases about cross-stack accesses).
Ah right, I remember this detail. IIRC the solution should be to register the stack in two pieces, though.
When I tried that I still got errors, but it's not clear to me that's not a (fixable) Valgrind bug.