From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933000AbcCIWH3 (ORCPT ); Wed, 9 Mar 2016 17:07:29 -0500 Received: from mailhub.eng.utah.edu ([155.98.110.27]:41562 "EHLO mailhub.eng.utah.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932445AbcCIWHV (ORCPT ); Wed, 9 Mar 2016 17:07:21 -0500 Subject: Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for signal cookies To: Ingo Molnar References: <1457470075-4586-1-git-send-email-sbauer@eng.utah.edu> <20160309083204.GA30365@gmail.com> Cc: 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 , Linus Torvalds From: Scotty Bauer Message-ID: <56E09E8B.1010909@eng.utah.edu> Date: Wed, 9 Mar 2016 15:07:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160309083204.GA30365@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-UCE-Score: -1.9 (-) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/09/2016 01:32 AM, Ingo Molnar wrote: > > * Scott Bauer 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 > 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 Thanks From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com References: <1457470075-4586-1-git-send-email-sbauer@eng.utah.edu> <20160309083204.GA30365@gmail.com> From: Scotty Bauer Message-ID: <56E09E8B.1010909@eng.utah.edu> Date: Wed, 9 Mar 2016 15:07:07 -0700 MIME-Version: 1.0 In-Reply-To: <20160309083204.GA30365@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: [kernel-hardening] Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for signal cookies To: Ingo Molnar Cc: 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 , Linus Torvalds List-ID: On 03/09/2016 01:32 AM, Ingo Molnar wrote: > > * Scott Bauer 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 > 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 Thanks