From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: kernel-hardening@lists.openwall.com
Cc: abhiram@cs.utah.edu, Scott Bauer <sbauer@eng.utah.edu>
Subject: [kernel-hardening] Re: [RFC PATCH 1/2] SROP Mitigation: Architecture independent code for signal cookies
Date: Mon, 01 Feb 2016 23:42:01 +0100 [thread overview]
Message-ID: <87twlsaw92.fsf@rasmusvillemoes.dk> (raw)
In-Reply-To: <1453622354-50686-2-git-send-email-sbauer@eng.utah.edu> (Scott Bauer's message of "Sun, 24 Jan 2016 00:59:13 -0700")
On Sun, Jan 24 2016, Scott Bauer <sbauer@eng.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.
>
>
> +static unsigned long gen_sigcookie(unsigned long __user *location)
> +{
> +
> + unsigned long sig_cookie;
> +
> + sig_cookie = (unsigned long) location ^ current->sig_cookie;
> +
> + sig_cookie = hash_long(sig_cookie, sizeof(sig_cookie) * BITS_PER_BYTE);
> +
> + return sig_cookie;
> +}
Is current->sig_cookie supposed to be secret, as in unknown to
userspace? If so, this won't work, as hash_long (with BIT_PER_LONG as
nbits parameter) is invertible (since we've just multiplied by an odd
number and right-shifted by 0). Maybe xoring with some global secret
afterwards would fix this, though I'm not sure.
Rasmus
next prev parent reply other threads:[~2016-02-01 22:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1453622354-50686-1-git-send-email-sbauer@eng.utah.edu>
2016-01-24 7:59 ` [kernel-hardening] [RFC PATCH 1/2] SROP Mitigation: Architecture independent code for signal cookies Scott Bauer
2016-01-28 23:25 ` Kees Cook
2016-01-29 21:26 ` Scotty Bauer
2016-02-01 22:42 ` Rasmus Villemoes [this message]
2016-02-01 23:19 ` [kernel-hardening] " Scotty Bauer
2016-02-02 9:15 ` Daniel Micay
2016-01-24 7:59 ` [kernel-hardening] [RFC PATCH 2/2] x86: SROP mitigation: implement " Scott Bauer
2016-01-28 23:31 ` Kees Cook
2016-01-30 14:34 ` Jann Horn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87twlsaw92.fsf@rasmusvillemoes.dk \
--to=linux@rasmusvillemoes.dk \
--cc=abhiram@cs.utah.edu \
--cc=kernel-hardening@lists.openwall.com \
--cc=sbauer@eng.utah.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.