From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S969156AbdDTMII (ORCPT ); Thu, 20 Apr 2017 08:08:08 -0400 Received: from mx2.suse.de ([195.135.220.15]:57660 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S967889AbdDTMIF (ORCPT ); Thu, 20 Apr 2017 08:08:05 -0400 Date: Thu, 20 Apr 2017 14:08:01 +0200 From: Joerg Roedel To: Dave Hansen Cc: Joerg Roedel , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/mpx: Correctly report do_mpx_bt_fault() failures to user-space Message-ID: <20170420120801.GH5077@suse.de> References: <1491488362-27198-1-git-send-email-joro@8bytes.org> <0d387d7f-208e-75aa-55ea-0157412aa4d4@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0d387d7f-208e-75aa-55ea-0157412aa4d4@linux.intel.com> 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 Hi Dave, On Mon, Apr 17, 2017 at 08:38:03AM -0700, Dave Hansen wrote: > Just to be clear, the thing you're calling "correct" is this do_trap(), > right? > > do_trap(X86_TRAP_BR, SIGSEGV, "bounds", regs, error_code, NULL); Yes, because it signals the right trap_nr and error_code to user-space. > do_mpx_bt_fault() can fail for a bunch of reasons: > * unexpected or invalid value in BNDCSR > * out of memory (physical or virtual) > * unresolvable fault walking/filling bounds tables > * !valid and non-empty bad entry in the bounds tables > > This will end up sending a signal that *looks* like a X86_TRAP_BR for > all of those, including those that are not really bounds-related, like > unresolvable faults. We also don't populate enough information in the > siginfo that gets delivered for userspace to resolve the fault. > > I'm not sure this patch is the right thing. The problem is, without this patch the trap_nr reported to user-space is 0, which maps to divide-by-zero. I think this is wrong, and since all failure cases from do_mpx_bt_fault() can only happen in the #BR exception handler, I think that reporting X86_TRAP_BR for all failure cases is the right thing to do. I don't know whether user-space (with this patch) already gets enough information from do_trap() to handle all of the above cases, but it is a step in the right direction. Joerg