13:30 <arnd> ardb: I finally managed to try out the idea I had for a long time to make the thread stack size in the kernel a runtime configurable number by hooking into the CONFIG_RANDOMIZE_KSTACK_OFFSET logic. It took me about half an hour to get a working kernel patch and then three days to figure out how to run syzkaller for testing it out

13:32 <arnd> This part seems to work great, but I may need some help from you fro the next step: I have another patch that calls set_memory_valid(..., false) on the top stack pages in order to trigger a page fault but still be able to set it back to valid in the fault handler and continue running after a report

13:33 <arnd> The problem I have is getting __bad_stack() to return to an uncorrupted task stack from the overflow stack, which of course is something your original code never expected to happen

13:34 <ardb> interesting

13:34 <arnd> fwiw, this is the longest stack trace I've seen so far, running a non-KASAN kernel https://www.irccloud.com/pastebin/LW7EIPup/

13:35 <ardb> so demand paging for the stack?

13:36 <arnd> kind of, yes, just without allocating more memory: my current code just does the vmalloc() as before and then marks some of the pages as invalid

13:37 <arnd> actual deman paging might be another option -- in theory we could keep a small pool of preallocated pages and then use that to back the stack when a fault happens

13:38 <ardb> indeed - that doesn't sound too hard

13:39 <ardb> afair we don't corrupt any state before calling handle_bad_stack() so it should be a matter of handling the return

13:41 <ardb> and the original SP should be valid at that point

13:41 <arnd> there is this bit in kernel_ventry: /* Either we've just detected an overflow, or we've taken an exception while on the overflow stack. Either way, we won't return to userspace, and can clobber EL0 registers to free up GPRs. */

13:42 <arnd> followed by some code I don't really understand

13:43 <ardb> ah this is arm64

13:45 <ardb> that is a bit trickier