From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751277AbdFFGHB (ORCPT ); Tue, 6 Jun 2017 02:07:01 -0400 Received: from mga01.intel.com ([192.55.52.88]:63333 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750933AbdFFGG7 (ORCPT ); Tue, 6 Jun 2017 02:06:59 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,304,1493708400"; d="scan'208";a="111362138" Message-ID: <1496729218.24288.82.camel@ranerica-desktop> Subject: Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type From: Ricardo Neri To: Borislav Petkov Cc: Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Andrew Morton , Brian Gerst , Chris Metcalf , Dave Hansen , Paolo Bonzini , Masami Hiramatsu , Huang Rui , Jiri Slaby , Jonathan Corbet , "Michael S. Tsirkin" , Paul Gortmaker , Vlastimil Babka , Chen Yucong , Alexandre Julliard , Stas Sergeev , Fenghua Yu , "Ravi V. Shankar" , Shuah Khan , linux-kernel@vger.kernel.org, x86@kernel.org, linux-msdos@vger.kernel.org, wine-devel@winehq.org, Adam Buchbinder , Colin Ian King , Lorenzo Stoakes , Qiaowei Ren , Arnaldo Carvalho de Melo , Adrian Hunter , Kees Cook , Thomas Garnier , Dmitry Vyukov Date: Mon, 05 Jun 2017 23:06:58 -0700 In-Reply-To: <20170529163748.bmihhr4j3hznbhcn@pd.tnic> References: <20170505181724.55000-1-ricardo.neri-calderon@linux.intel.com> <20170505181724.55000-8-ricardo.neri-calderon@linux.intel.com> <20170529163748.bmihhr4j3hznbhcn@pd.tnic> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2017-05-29 at 18:37 +0200, Borislav Petkov wrote: > On Fri, May 05, 2017 at 11:17:05AM -0700, Ricardo Neri wrote: > > We are not in a critical failure path. The invalid register type is caused > > when trying to decode invalid instruction bytes from a user-space program. > > Thus, simply print an error message. To prevent this warning from being > > abused from user space programs, use the rate-limited variant of printk. > > > > Cc: Borislav Petkov > > Cc: Andy Lutomirski > > Cc: Dave Hansen > > Cc: Adam Buchbinder > > Cc: Colin Ian King > > Cc: Lorenzo Stoakes > > Cc: Qiaowei Ren > > Cc: Arnaldo Carvalho de Melo > > Cc: Masami Hiramatsu > > Cc: Adrian Hunter > > Cc: Kees Cook > > Cc: Thomas Garnier > > Cc: Peter Zijlstra > > Cc: Dmitry Vyukov > > Cc: Ravi V. Shankar > > Cc: x86@kernel.org > > Signed-off-by: Ricardo Neri > > --- > > arch/x86/lib/insn-eval.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c > > index e746a6f..182e2ae 100644 > > --- a/arch/x86/lib/insn-eval.c > > +++ b/arch/x86/lib/insn-eval.c > > @@ -5,6 +5,7 @@ > > */ > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -85,9 +86,8 @@ static int get_reg_offset(struct insn *insn, struct pt_regs *regs, > > break; > > > > default: > > - pr_err("invalid register type"); > > - BUG(); > > - break; > > + printk_ratelimited(KERN_ERR "insn-eval: x86: invalid register type"); > > You can use pr_err_ratelimited() and define "insn-eval" with pr_fmt. > Look for examples in the tree. Will do. I have looked at the examples. > > Btw, "insn-eval" is perhaps not the right name - since we're building > an instruction decoder, maybe it should be called "insn-dec" or so. I'm > looking at those other arch/x86/lib/insn.c, arch/x86/include/asm/inat.h > things and how they're starting to morph into one decoding facility, > AFAICT. I agree that insn-eval reads somewhat funny. I did not want to go with insn-dec.c as insn.c, in my opinion, already decodes the instruction (i.e., it finds prefixes, opcodes, ModRM, SIB and displacement bytes). In insn-eval.c I simply take those decoded parameters and evaluate them to obtain the values they contain (e.g., a specific memory location). Perhaps, insn-resolve.c could be a better name? Or maybe isnn-operands? Thanks and BR, Ricardo