[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160309152212.07a9b83b@lwn.net>
Date: Wed, 9 Mar 2016 15:22:12 -0700
From: Jonathan Corbet <corbet@....net>
To: Scotty Bauer <sbauer@....utah.edu>
Cc: Ingo Molnar <mingo@...nel.org>, 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
On Wed, 9 Mar 2016 15:07:07 -0700
Scotty Bauer <sbauer@....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/
(The information still belongs with the patch posting, of course...)
jon
Powered by blists - more mailing lists