From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EFDEC43331 for ; Fri, 3 Apr 2020 14:35:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4FC1C20857 for ; Fri, 3 Apr 2020 14:35:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585924507; bh=l0EiIHchinDWyCf43w0lhXunhiG167jMxs4uH8nFBj4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=jmfwIkAvfP/sqXv28gxRA+VCTmRpUW46KhIl4+p9RejQIU/ocEp+vRJMwTSZsZBga Ro3i9J5rVILybMCGC3jdZH1SK4A7jMPakTRTG2ZpR2BAvRqgrcLtAHJ1bEq1OzBugQ /Wfgn13V54J7m74n7slU7rKMZ1O6lFl7Z60hsy8k= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2403853AbgDCOfG (ORCPT ); Fri, 3 Apr 2020 10:35:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:55264 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390784AbgDCOfG (ORCPT ); Fri, 3 Apr 2020 10:35:06 -0400 Received: from linux-8ccs (p3EE2C7AC.dip0.t-ipconnect.de [62.226.199.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 39BB72073B; Fri, 3 Apr 2020 14:35:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585924505; bh=l0EiIHchinDWyCf43w0lhXunhiG167jMxs4uH8nFBj4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=yt5CYCfaNNG0hTQtdc+FclL0cgpS2x3v05p14lXgVFdsM3ZGhhpIKU2WPLClo3GRQ LqLpVFyhPoXtzNQGl/X9dsg4kXFTPn+hKDqhZtYCelZa0eTaXajtavVptm/Q954UHW 30Q4UjZ2n5e8/iKwGBIqUXYQlTAD+LuLtC3CT+aw= Date: Fri, 3 Apr 2020 16:35:00 +0200 From: Jessica Yu To: Rasmus Villemoes Cc: Thomas Gleixner , LKML , x86@kernel.org, "Kenneth R. Crudup" , "Peter Zijlstra (Intel)" , Paolo Bonzini , Fenghua Yu , Xiaoyao Li , Nadav Amit , Thomas Hellstrom , Sean Christopherson , Tony Luck , Steven Rostedt Subject: Re: [patch 1/2] x86,module: Detect VMX modules and disable Split-Lock-Detect Message-ID: <20200403143459.GA30424@linux-8ccs> References: <20200402123258.895628824@linutronix.de> <20200402124205.242674296@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-OS: Linux linux-8ccs 4.12.14-lp150.12.61-default x86_64 User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +++ Rasmus Villemoes [03/04/20 01:42 +0200]: >On 02/04/2020 14.32, Thomas Gleixner wrote: >> From: Peter Zijlstra >> >> It turns out that with Split-Lock-Detect enabled (default) any VMX >> hypervisor needs at least a little modification in order to not blindly >> inject the #AC into the guest without the guest being ready for it. >> >> Since there is no telling which module implements a hypervisor, scan the >> module text and look for the VMLAUNCH instruction. If found, the module is >> assumed to be a hypervisor of some sort and SLD is disabled. > >How long does that scan take/add to module load time? Would it make >sense to exempt in-tree modules? > >Rasmus I second Rasmus's question. It seems rather unfortunate that we have to do this text scan for every module load on x86, when it doesn't apply to the majority of them, and only to a handful of out-of-tree hypervisor modules (assuming kvm is taken care of already). I wonder if it would make sense then to limit the text scans to just out-of-tree modules (i.e., missing the intree modinfo flag)? Jessica