[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160309083204.GA30365@gmail.com>
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.
