From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759704AbdACQmG (ORCPT ); Tue, 3 Jan 2017 11:42:06 -0500 Received: from mga05.intel.com ([192.55.52.43]:21874 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759484AbdACQlw (ORCPT ); Tue, 3 Jan 2017 11:41:52 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,455,1477983600"; d="scan'208";a="918493683" Subject: Re: [v2 2/7] x86/mpx: Fail when implicit zero-displacement is used along with R/EBP To: Ricardo Neri , Andy Lutomirski References: <20161224013745.108716-1-ricardo.neri-calderon@linux.intel.com> <20161224013745.108716-3-ricardo.neri-calderon@linux.intel.com> <1482878000.106950.10.camel@ranerica-desktop> Cc: Ingo Molnar , Thomas Gleixner , Borislav Petkov , Andy Lutomirski , Peter Zijlstra , "linux-kernel@vger.kernel.org" , X86 ML , linux-msdos@vger.kernel.org, wine-devel@winehq.org, Adam Buchbinder , Colin Ian King , Lorenzo Stoakes , Qiaowei Ren , "Ravi V . Shankar" From: Dave Hansen Message-ID: <2ef4ec41-b8f7-d775-aaff-02656b79a5dd@linux.intel.com> Date: Tue, 3 Jan 2017 08:41:50 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1482878000.106950.10.camel@ranerica-desktop> 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 On 12/27/2016 02:33 PM, Ricardo Neri wrote: >>> diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c >>> index 6a75a75..71681d0 100644 >>> --- a/arch/x86/mm/mpx.c >>> +++ b/arch/x86/mm/mpx.c >>> @@ -120,6 +120,13 @@ static int get_reg_offset(struct insn *insn, struct pt_regs *regs, >>> >>> case REG_TYPE_BASE: >>> regno = X86_SIB_BASE(insn->sib.value); >>> + if (regno == 5 && X86_MODRM_RM(insn->modrm.value) == 0) { >>> + WARN_ONCE(1, "An explicit displacement is required when %sBP used as SIB base.", >>> + (IS_ENABLED(CONFIG_X86_64) && insn->x86_64) ? >>> + "R13 or R" : "E"); >>> + return -EINVAL; >>> + } >>> + >> Now that I've read the cover letter, I see what's going on. This >> should not warn -- user code can easily trigger this deliberately. > OK, I'll remove it. Are you concerned about the warning printing the > calltrace, even only once? Yes. We don't let userspace spam the kernel, even once. If we have a couple thousand "only once" places, then userspace can overwhelm the kernel log. Also, this needs a much better description of what's going on in the code. Could you add a comment explaining what's going on, and why regno==5, etc...?