Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758541AbcC2XZ3 (ORCPT ); Tue, 29 Mar 2016 19:25:29 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:32873 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758510AbcC2XZ1 (ORCPT ); Tue, 29 Mar 2016 19:25:27 -0400 MIME-Version: 1.0 In-Reply-To: <56FB0B88.2020306@eng.utah.edu> References: <1459281207-24377-1-git-send-email-sbauer@eng.utah.edu> <56FB0B88.2020306@eng.utah.edu> Date: Tue, 29 Mar 2016 18:25:26 -0500 X-Google-Sender-Auth: xXOXYYsMoKlmEPvQ8AcbhrHt0Hk Message-ID: Subject: Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies From: Linus Torvalds To: Scotty Bauer 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1598 Lines: 34 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