Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4454743ybb; Tue, 7 Apr 2020 07:50:23 -0700 (PDT) X-Google-Smtp-Source: APiQypJxtob4eyXnlN/Ev5Cex0d42sAXkhJ5TMM+x+xbfZMXVoQSmSHMC6d/yQOwAh3wYUUrUxrm X-Received: by 2002:aca:5354:: with SMTP id h81mr1962860oib.164.1586271022899; Tue, 07 Apr 2020 07:50:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586271022; cv=none; d=google.com; s=arc-20160816; b=D9STOXd/6C1GXcz8fa7hESZVyMKmwqm5qlbf+UB5o8QjPlkzxnIYyOTEm/DFIWpr02 9/PU30pX7YRv6at1PTsC7SB+Ox6Ej1a8Y1fCHR8n1G3ev2kpdqNk2hxAotp3oNUoQhwC bYQwonfjYtkECpNZv4AxrnFoaHjDXCVYoa4pmzHx2cO2bLLC2XnhHMbr5NUiyMOGRynK QHWy4UGAJoMzGZayyta1Uuv9v0ZN/ukFYEQsOKUvK2jWUX+0U0M+1h280zijulUn7Go3 X7azBCs8SLiJFm8UE9LBszk5b3nq/gd6ylkWnGSYGFMDuhurRNeLNjTPh1UEOmRToVQ5 Hllg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=Lwbi6zItJFKQTdcGhxJy/pEmdHPcqXSqOTxLND8KlD8=; b=dJ4W9P1kjDyV/ONP7WBPKr4AP4oBDmp7Q6Co45os8DKgKqvLbFASvi02auek+K0nD0 WxMkDspdrelARjE4FBmGPW/fc+kwqSHBvyDBpUN4FylylUVNYqapoKJfekVmPz9n2TM4 wYCqcrfjIulQVDbTj9zj/yD2L3A8SBHhOj1TjHuwEZ7M3a9RU58spwROfO4VIZbs18RL 13lBp077kQ8VIqwGj1AeeC12UTGVrX0KyLoq5YsfLzb/jZpMTh/8IwF5r+mfOaIM+t91 IyRG7LLp2BZaABwA7HcjLLJdk3kqjB8ZM/ghjhuVkxEKrp4e6A/gz5EyE/InFWsyX4sF FViQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l65si703058oig.156.2020.04.07.07.50.11; Tue, 07 Apr 2020 07:50:22 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729290AbgDGOtd (ORCPT + 99 others); Tue, 7 Apr 2020 10:49:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:58514 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729197AbgDGOtd (ORCPT ); Tue, 7 Apr 2020 10:49:33 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (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 5B16A206F7; Tue, 7 Apr 2020 14:49:30 +0000 (UTC) Date: Tue, 7 Apr 2020 10:49:28 -0400 From: Steven Rostedt To: Greg KH Cc: Peter Zijlstra , tglx@linutronix.de, linux-kernel@vger.kernel.org, hch@infradead.org, sean.j.christopherson@intel.com, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, x86@kernel.org, kenny@panix.com, jeyu@kernel.org, rasmus.villemoes@prevas.dk, pbonzini@redhat.com, fenghua.yu@intel.com, xiaoyao.li@intel.com, nadav.amit@gmail.com, thellstrom@vmware.com, tony.luck@intel.com, jannh@google.com, keescook@chromium.org, David.Laight@aculab.com, dcovelli@vmware.com, mhiramat@kernel.org Subject: Re: [PATCH 3/4] x86,module: Detect VMX vs SLD conflicts Message-ID: <20200407104928.566db3f8@gandalf.local.home> In-Reply-To: <20200407143543.GB876345@kroah.com> References: <20200407110236.930134290@infradead.org> <20200407111007.352324393@infradead.org> <20200407143543.GB876345@kroah.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 7 Apr 2020 16:35:43 +0200 Greg KH wrote: > > Hypervisors, which have been modified and are known to work correctly, > > can add: > > > > MODULE_INFO(sld_safe, "Y"); > > > > to explicitly tell the module loader they're good. > > What's to keep any out-of-tree module from adding this same module info > "flag" and just lie about it? Isn't that what you are trying to catch > here, or is it a case of, "if you lie, your code will break" as well? Keeping with the analogy to module kabi breakage, that would basically be the same as an out of tree module fixing the api but not using it properly. It will break. All this is doing is to make sure VM modules that haven't been updated to handle split lock detection, wont be loaded if split lock detection is enabled. Saying you can handle SLD and not handling it is just broken code and we can't really protect against that. -- Steve