linux-kernel - Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for signal cookies

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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