Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list] 
Date: Tue, 29 Mar 2016 18:04:22 -0500
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Scott Bauer <sbauer@....utah.edu>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, 
	"the arch/x86 maintainers" <x86@...nel.org>, Andi Kleen <ak@...ux.intel.com>, 
	Andy Lutomirski <luto@...capital.net>, Ingo Molnar <mingo@...hat.com>, 
	Thomas Gleixner <tglx@...utronix.de>, wmealing@...hat.com, 
	Abhiram Balasubramanian <abhiram@...utah.edu>, Scott Bauer <sbauer@...donthack.me>
Subject: Re: [PATCH v4 1/4] SROP Mitigation: Architecture independent code for
 signal cookies

On Tue, Mar 29, 2016 at 2:53 PM, Scott Bauer <sbauer@....utah.edu> wrote:
> @@ -1231,6 +1232,8 @@ void setup_new_exec(struct linux_binprm * bprm)
>         /* This is the point of no return */
>         current->sas_ss_sp = current->sas_ss_size = 0;
>
> +       get_random_bytes(&current->sig_cookie, sizeof(current->sig_cookie));
> +

This should probably just be

     current->sig_cookie = get_random_long();

instead. That will use hardware random numbers if available, and be
*much* faster.

I realize that some people don't like the hardware random number
generators because they don't trust them, but quite frankly, for
something like this it's fine. If the attacker is in collusion with
the hardware manufacturer, you have way bigger problems than a SROP
attack.

                 Linus

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.