Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 3 Apr 2020 16:33:44 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     David Laight <David.Laight@ACULAB.COM>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>,
        "x86@kernel.org" <x86@kernel.org>,
        "Kenneth R. Crudup" <kenny@panix.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Jessica Yu <jeyu@kernel.org>,
        Fenghua Yu <fenghua.yu@intel.com>,
        Xiaoyao Li <xiaoyao.li@intel.com>,
        Nadav Amit <namit@vmware.com>,
        Thomas Hellstrom <thellstrom@vmware.com>,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        Tony Luck <tony.luck@intel.com>,
        Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [patch v2 1/2] x86,module: Detect VMX modules and disable
 Split-Lock-Detect
Message-ID: <20200403143344.GP20730@hirez.programming.kicks-ass.net>
References: <20200402123258.895628824@linutronix.de>
 <20200402124205.242674296@linutronix.de>
 <20200402152340.GL20713@hirez.programming.kicks-ass.net>
 <9b95fe9e81c14370859e19f081cc23e4@AcuMS.aculab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9b95fe9e81c14370859e19f081cc23e4@AcuMS.aculab.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Apr 03, 2020 at 08:09:03AM +0000, David Laight wrote:
> From: Peter Zijlstra
> > Sent: 02 April 2020 16:24
> > 
> > I picked VMXOFF (which also appears in vmmon.ko) instead of VMXON
> > because that latter takes an argument is therefore more difficult to
> > decode.
> ...
> > +	while (text < text_end) {
> > +		kernel_insn_init(&insn, text, text_end - text);
> > +		insn_get_length(&insn);
> > +
> > +		if (WARN_ON_ONCE(!insn_complete(&insn)))
> > +			break;
> > +
> > +		if (insn.length == 3 &&
> > +		    (!memcmp(text, vmlaunch, sizeof(vmlaunch)) ||
> > +		     !memcmp(text, vmxoff, sizeof(vmxoff))))
> > +				goto bad_module;
> > +
> > +		text += insn.length;
> > +	}
> 
> How long is that going to take on a module with (say) 400k of text?

It's module load, why would you care? I suspect it's really fast, but
even if it wasn't I couldn't be arsed.