From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com Date: Tue, 9 Feb 2016 12:45:54 -0800 From: Andi Kleen Message-ID: <20160209204554.GD4875@tassilo.jf.intel.com> References: <1454801964-50385-1-git-send-email-sbauer@eng.utah.edu> <1454801964-50385-3-git-send-email-sbauer@eng.utah.edu> <56B6E5C6.4090209@nextfour.com> <56B6FBE0.9060202@eng.utah.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [kernel-hardening] Re: [PATCHv2 2/2] x86: SROP mitigation: implement signal cookies To: Andy Lutomirski Cc: Scotty Bauer , Mika =?iso-8859-1?Q?Penttil=E4?= , "linux-kernel@vger.kernel.org" , "kernel-hardening@lists.openwall.com" , X86 ML , Ingo Molnar , Thomas Gleixner , Abhiram Balasubramanian List-ID: > Is this compatible with existing userspace? CRIU and DOSEMU seem like > things that are likely to blow up to me. It should at least make it a sysctl. > > We may need to make this type of mitigation be opt-in. I'm already > vaguely planning an opt-in mitigation framework for vsyscall runtime > disablement, and this could use the same opt-in mechanism. Generally asking people to rely on frame works that don't exist is not good review feedback. -Andi -- ak@linux.intel.com -- Speaking for myself only From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932542AbcBIUp4 (ORCPT ); Tue, 9 Feb 2016 15:45:56 -0500 Received: from mga03.intel.com ([134.134.136.65]:26492 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751802AbcBIUpz (ORCPT ); Tue, 9 Feb 2016 15:45:55 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,422,1449561600"; d="scan'208";a="908805633" Date: Tue, 9 Feb 2016 12:45:54 -0800 From: Andi Kleen To: Andy Lutomirski Cc: Scotty Bauer , Mika =?iso-8859-1?Q?Penttil=E4?= , "linux-kernel@vger.kernel.org" , "kernel-hardening@lists.openwall.com" , X86 ML , Ingo Molnar , Thomas Gleixner , Abhiram Balasubramanian Subject: Re: [PATCHv2 2/2] x86: SROP mitigation: implement signal cookies Message-ID: <20160209204554.GD4875@tassilo.jf.intel.com> References: <1454801964-50385-1-git-send-email-sbauer@eng.utah.edu> <1454801964-50385-3-git-send-email-sbauer@eng.utah.edu> <56B6E5C6.4090209@nextfour.com> <56B6FBE0.9060202@eng.utah.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Is this compatible with existing userspace? CRIU and DOSEMU seem like > things that are likely to blow up to me. It should at least make it a sysctl. > > We may need to make this type of mitigation be opt-in. I'm already > vaguely planning an opt-in mitigation framework for vsyscall runtime > disablement, and this could use the same opt-in mechanism. Generally asking people to rely on frame works that don't exist is not good review feedback. -Andi -- ak@linux.intel.com -- Speaking for myself only