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;
Message-Id: <20200407110236.930134290@infradead.org>
User-Agent: quilt/0.65
Date:   Tue, 07 Apr 2020 13:02:36 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     tglx@linutronix.de, linux-kernel@vger.kernel.org
Cc:     hch@infradead.org, sean.j.christopherson@intel.com,
        mingo@redhat.com, bp@alien8.de, hpa@zytor.com, x86@kernel.org,
        kenny@panix.com, peterz@infradead.org, 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, rostedt@goodmis.org,
        gregkh@linuxfoundation.org, jannh@google.com,
        keescook@chromium.org, David.Laight@aculab.com,
        dcovelli@vmware.com, mhiramat@kernel.org
Subject: [PATCH 0/4] x86/module: Out-of-tree module decode and sanitize
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi all,

Driven by the SLD vs VMX interaction, here are some patches that provide means
to analyze the text of out-of-tree modules.

The first user of that is refusing to load modules on VMX-SLD conflicts, but it
also has a second patch that refulses to load any module that tries to modify
CRn/DRn.

I'm thinking people will quickly come up with more and more elaborate tests to
which to subject out-of-tree modules.