From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932715AbbCCX2L (ORCPT ); Tue, 3 Mar 2015 18:28:11 -0500 Received: from mga03.intel.com ([134.134.136.65]:57993 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932252AbbCCX1T (ORCPT ); Tue, 3 Mar 2015 18:27:19 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,684,1418112000"; d="scan'208";a="693547923" Message-ID: <54F64355.3090808@intel.com> Date: Tue, 03 Mar 2015 15:27:17 -0800 From: Dave Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "H. Peter Anvin" , Thomas Gleixner , LKML Subject: x86: MPX and signal handlers Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In handle_signal(), while we are setting up to call a signal handler, we do: /* * Ensure the signal handler starts with the new fpustate. */ if (used_math()) drop_init_fpu(current); Where drop_init_fpu() actually restores us to the 'init' FPU state where, of course, MPX will be turned off. I guess userspace can still just re-enable MPX first thing in its signal handlers if it really cares, but that definitely breaks the idea that MPX support can be added with a simple recompilation. The alternative would be to jam the original configuration register value (BNDCFGU) in to the signal handler's FPU state from inside the kernel before calling out to the signal handler. I _think_ we can just leave it alone and document that you don't get MPX protections by default in signal handlers. Does anybody disagree?