All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Scotty Bauer <sbauer@eng.utah.edu>,
	linux-kernel@vger.kernel.org,
	kernel-hardening@lists.openwall.com, x86@kernel.org,
	wmealing@redhat.com, ak@linux.intel.com, luto@amacapital.net,
	Abhiram Balasubramanian <abhiram@cs.utah.edu>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: [kernel-hardening] Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for signal cookies
Date: Thu, 10 Mar 2016 10:43:39 +0100	[thread overview]
Message-ID: <20160310094339.GA5105@gmail.com> (raw)
In-Reply-To: <20160309152212.07a9b83b@lwn.net>


* Jonathan Corbet <corbet@lwn.net> wrote:

> On Wed, 9 Mar 2016 15:07:07 -0700
> Scotty Bauer <sbauer@eng.utah.edu> wrote:
> 
> > On 03/09/2016 01:32 AM, Ingo Molnar wrote:
> > > 
> > > 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.
> > 
> > I'm going to submit v4 to fix some nits where I'll include the explanation
> > and a change log, I apologize for not doing that here. In the meantime if
> > you don't mind visiting a link I included a brief explanation on previous
> > versions of the patch set.
> > 
> > https://lkml.org/lkml/2016/2/6/166
> 
> The curious might also find background information in my article about this
> patch set:
> 
>       https://lwn.net/Articles/676803/

Scott, mind including a prominent link to the (excellent!) LWN.net article in the 
changelog/documentation as well?

Thanks,

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Scotty Bauer <sbauer@eng.utah.edu>,
	linux-kernel@vger.kernel.org,
	kernel-hardening@lists.openwall.com, x86@kernel.org,
	wmealing@redhat.com, ak@linux.intel.com, luto@amacapital.net,
	Abhiram Balasubramanian <abhiram@cs.utah.edu>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for signal cookies
Date: Thu, 10 Mar 2016 10:43:39 +0100	[thread overview]
Message-ID: <20160310094339.GA5105@gmail.com> (raw)
In-Reply-To: <20160309152212.07a9b83b@lwn.net>


* Jonathan Corbet <corbet@lwn.net> wrote:

> On Wed, 9 Mar 2016 15:07:07 -0700
> Scotty Bauer <sbauer@eng.utah.edu> wrote:
> 
> > On 03/09/2016 01:32 AM, Ingo Molnar wrote:
> > > 
> > > 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.
> > 
> > I'm going to submit v4 to fix some nits where I'll include the explanation
> > and a change log, I apologize for not doing that here. In the meantime if
> > you don't mind visiting a link I included a brief explanation on previous
> > versions of the patch set.
> > 
> > https://lkml.org/lkml/2016/2/6/166
> 
> The curious might also find background information in my article about this
> patch set:
> 
>       https://lwn.net/Articles/676803/

Scott, mind including a prominent link to the (excellent!) LWN.net article in the 
changelog/documentation as well?

Thanks,

	Ingo

  reply	other threads:[~2016-03-10  9:43 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-08 20:47 [kernel-hardening] [PATCH v3 1/3] SROP Mitigation: Architecture independent code for signal cookies Scott Bauer
2016-03-08 20:47 ` Scott Bauer
2016-03-08 20:47 ` [kernel-hardening] [PATCH v3 2/3] x86: SROP mitigation: implement " Scott Bauer
2016-03-08 20:47   ` Scott Bauer
2016-03-08 21:03   ` [kernel-hardening] " One Thousand Gnomes
2016-03-08 21:03     ` One Thousand Gnomes
2016-03-08 21:38     ` [kernel-hardening] " Scotty Bauer
2016-03-08 21:38       ` Scotty Bauer
2016-03-08 20:47 ` [kernel-hardening] [PATCH v3 3/3] SROP mitigation: Add sysctl to disable SROP protection Scott Bauer
2016-03-08 20:47   ` Scott Bauer
2016-03-08 21:00   ` [kernel-hardening] " One Thousand Gnomes
2016-03-08 21:00     ` One Thousand Gnomes
2016-03-10  6:36     ` [kernel-hardening] " Kees Cook
2016-03-10  6:46       ` Andy Lutomirski
2016-03-08 20:58 ` [kernel-hardening] Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for signal cookies Andy Lutomirski
2016-03-08 20:58   ` Andy Lutomirski
2016-03-08 21:49   ` [kernel-hardening] " Scotty Bauer
2016-03-08 21:49     ` Scotty Bauer
2016-03-08 21:57     ` [kernel-hardening] " Andy Lutomirski
2016-03-08 21:57       ` Andy Lutomirski
2016-03-08 22:06       ` [kernel-hardening] " Scotty Bauer
2016-03-08 22:06         ` Scotty Bauer
2016-03-09 22:02       ` [kernel-hardening] " Scotty Bauer
2016-03-09 22:02         ` Scotty Bauer
2016-03-08 21:04 ` [kernel-hardening] " kbuild test robot
2016-03-08 21:04   ` kbuild test robot
2016-03-09  8:32 ` [kernel-hardening] " Ingo Molnar
2016-03-09  8:32   ` Ingo Molnar
2016-03-09 22:07   ` [kernel-hardening] " Scotty Bauer
2016-03-09 22:07     ` Scotty Bauer
2016-03-09 22:22     ` [kernel-hardening] " Jonathan Corbet
2016-03-09 22:22       ` Jonathan Corbet
2016-03-10  9:43       ` Ingo Molnar [this message]
2016-03-10  9:43         ` Ingo Molnar

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=20160310094339.GA5105@gmail.com \
    --to=mingo@kernel.org \
    --cc=abhiram@cs.utah.edu \
    --cc=ak@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=sbauer@eng.utah.edu \
    --cc=torvalds@linux-foundation.org \
    --cc=wmealing@redhat.com \
    --cc=x86@kernel.org \
    /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.