Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754172AbcC2XeK (ORCPT ); Tue, 29 Mar 2016 19:34:10 -0400 Received: from mailhub.eng.utah.edu ([155.98.110.27]:17489 "EHLO mailhub.eng.utah.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750915AbcC2XeI (ORCPT ); Tue, 29 Mar 2016 19:34:08 -0400 Subject: Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies To: Linus Torvalds References: <1459281207-24377-1-git-send-email-sbauer@eng.utah.edu> <56FB0B88.2020306@eng.utah.edu> Cc: Linux Kernel Mailing List , "kernel-hardening@lists.openwall.com" , the arch/x86 maintainers , Andi Kleen , Andy Lutomirski , Ingo Molnar , Thomas Gleixner , wmealing@redhat.com From: Scotty Bauer Message-ID: <56FB10E8.1060504@eng.utah.edu> Date: Tue, 29 Mar 2016 17:34:00 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 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 Content-Length: 1831 Lines: 45 On 03/29/2016 05:25 PM, Linus Torvalds wrote: > On Tue, Mar 29, 2016 at 6:11 PM, Scotty Bauer wrote: >> >> Yeah I had toyed with using hashes, I used hash_64 not md5 which is like 14 >> extra instructions or something. > > That sounds fine. Anything that requires enough code to undo that it > kind of defeats the purpose of a SROP should be enough. It's not about > encryption, I'd just think that if you can force the buffer overflow > while already in a signal handler, you'd want something that is at > least *slightly* harder to defeat than a single "xor" instruction. > >> It's not hard to implement So I can try it. When you say an extra hardening >> mode do you mean hide it behind a sysctl or some sort of compile time CONFIG? > > Since there already is a sysctl, I'd just assume that. > > The important part is that the *default* value for that sysctl can't > break real applications. I don't really count CRIU as a real app, if > only because once you start doing checkpoint-restore you are going to > do some amount of system maintenance anyway, so somebody doing CRIU is > kind of expected to have a certain amount of system expertise, I would > say. > > But dosemu - or Wine - is very much something that "normal people" run > - people who we do *not* expect to have to know about new sysctl's > etc. They already have one (mmap at zero), but that is very directly > related to what vm86 mode and Wine does, and people have had time to > learn about it. Let's not add another. > > So testing dosemu and wine would be good. I wonder what else has shown > issues with signal stack layout changes. Debuggers and some JIT > engines, I suspect. > > Linus > Alright I'll test Wine/Mono, Dosemu, some random languages/debuggers see if there is anything that breaks. Thanks.