|
Message-ID: <586ee584-df0d-3c82-a254-16ac1573255a@linux.com> Date: Mon, 30 Oct 2017 21:06:30 +0300 From: Alexander Popov <alex.popov@...ux.com> To: Peter Zijlstra <peterz@...radead.org> Cc: kernel-hardening@...ts.openwall.com, keescook@...omium.org, pageexec@...email.hu, spender@...ecurity.net, Ingo Molnar <mingo@...nel.org>, Andy Lutomirski <luto@...nel.org>, tycho@...ker.com, Laura Abbott <labbott@...hat.com>, Mark Rutland <mark.rutland@....com>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, Borislav Petkov <bp@...en8.de>, Thomas Gleixner <tglx@...utronix.de>, "H . Peter Anvin" <hpa@...or.com>, x86@...nel.org Subject: Re: [PATCH RFC v5 2/5] gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack Hello Peter, Thanks for your reply. On 30.10.2017 20:32, Peter Zijlstra wrote: > On Mon, Oct 30, 2017 at 07:51:33PM +0300, Alexander Popov wrote: >> When the thread stack is exhausted, this BUG() is hit. But do_error_trap(), >> which handles the exception, calls track_stack() itself again (since it is >> instrumented by the gcc plugin). So this recursion proceeds with exhausting the >> thread stack. > > Add a __attribute__((nostacktrack)) on it? Yes, I already tried some blacklisting in the plugin, but it didn't really help, because: 1. there are other (more than 5) instrumented functions, that are called during BUG() handling too; 2. decreasing CONFIG_STACKLEAK_TRACK_MIN_SIZE would add more instrumented functions, which should be manually blacklisted (not good). I guess handling BUG() in another stack would be a solution. For example, Andy Lutomirski calls handle_stack_overflow in the DOUBLEFAULT_STACK (arch/x86/mm/fault.c). Should I do something similar? Thanks! Best regards, Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.