From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752981AbdJLBYi (ORCPT ); Wed, 11 Oct 2017 21:24:38 -0400 Received: from mga06.intel.com ([134.134.136.31]:40113 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751827AbdJLBYh (ORCPT ); Wed, 11 Oct 2017 21:24:37 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,363,1503385200"; d="scan'208";a="137634076" Message-ID: <1507771443.17492.42.camel@linux.intel.com> Subject: Re: [PATCH v9 15/29] x86/insn-eval: Add utility functions to get segment descriptor base address and limit 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 , "Ravi V. Shankar" , Shuah Khan , linux-kernel@vger.kernel.org, x86@kernel.org, Adam Buchbinder , Colin Ian King , Lorenzo Stoakes , Qiaowei Ren , Arnaldo Carvalho de Melo , Adrian Hunter , Kees Cook , Thomas Garnier , Dmitry Vyukov Date: Wed, 11 Oct 2017 18:24:03 -0700 In-Reply-To: <20171011201630.q4jmp7roupqz32hy@pd.tnic> References: <1507089272-32733-1-git-send-email-ricardo.neri-calderon@linux.intel.com> <1507089272-32733-16-git-send-email-ricardo.neri-calderon@linux.intel.com> <20171011151518.i2euii23o7vmdiuo@pd.tnic> <1507751821.17492.28.camel@linux.intel.com> <20171011201630.q4jmp7roupqz32hy@pd.tnic> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2017-10-11 at 22:16 +0200, Borislav Petkov wrote: > On Wed, Oct 11, 2017 at 12:57:01PM -0700, Ricardo Neri wrote: > > > > This is meant to be an error case. In long mode, > > only INAT_SEG_REG_IGNORE/FS/GS > > are valid. All other indices are invalid. > > > > Perhaps we could return -EINVAL instead? > So, my question is, when are you ever going to have that case? What > constellation of events would ever hit this else branch for long mode? > Because it looks impossible to me. What I can imagine only is something > like this: > >                 else if (seg_reg != INAT_SEG_REG_IGNORE) > WARN_ONCE(1, "This should never happen!\n"); > > assertion. To clarify, I think you mean seg_reg_idx. Yes, it would be impossible to hit this else branch provided that callers don't attempt to use an invalid seg_reg_idx while in long mode. Probably this is not critical as this is a static function and as such we control who can call it and make sure seg_reg_idx is always valid (i.e., INAT_SEG_REG_IGNORE/FS/GS in long mode). > But you don't really need that - you can simply ignore seg_reg in that > case: > >         if (user_64bit_mode(regs)) { >                 /* >                  * Only FS or GS will have a base address, the rest of >                  * the segments' bases are forced to 0. >                  */ >                 unsigned long base; > >                 if (seg_reg == INAT_SEG_REG_FS) >                         rdmsrl(MSR_FS_BASE, base); >                 else if (seg_reg == INAT_SEG_REG_GS) >                         /* >                          * swapgs was called at the kernel entry point. Thus, >                          * MSR_KERNEL_GS_BASE will have the user-space GS > base. >                          */ >                         rdmsrl(MSR_KERNEL_GS_BASE, base); >                 else >                         base = 0; > >                 return base; >         } > > Or am I missing something? My intention is to let the caller know about the invalid seg_reg_idx instead of silently correcting the caller's input by ignoring seg_reg_idx. On the other hand, in long mode, hardware ignore all segment registers except FS and GS. Hence, I guess I can remove the check in question. Thanks and BR, Ricardo