Date: Wed, 9 Mar 2016 09:32:05 +0100 From: Ingo Molnar <mingo@...nel.org> To: Scott Bauer <sbauer@....utah.edu> Cc: linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com, x86@...nel.org, wmealing@...hat.com, ak@...ux.intel.com, luto@...capital.net, Abhiram Balasubramanian <abhiram@...utah.edu>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for signal cookies * Scott Bauer <sbauer@....utah.edu> wrote: > This patch adds a per-process secret to the task struct which > will be used during signal delivery and during a sigreturn. > Also, logic is added in signal.c to generate, place, extract, > clear and verify the signal cookie. > /* > + * Canary value for signal frames placed on user stack. > + * This helps mitigate "Signal Return oriented program" > + * exploits in userland. > + */ > + unsigned long sig_cookie; Could you please add a high level description in Documentation that explains the attack and the way how this mitigation code prevents that kind of attack? Also, the first changelogs should contain more high level description as well. For example, what does the 'verification' of the signal cookie mean, and how does it prevent an SROP attempt? All of these patches seem to assume that people reading this code know what SROP is and how we defend against it - that is not so. Thanks, Ingo
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.