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:   Thu, 11 Jul 2019 08:08:57 -0700
From:   Kees Cook <keescook@chromium.org>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Nadav Amit <namit@vmware.com>, Jiri Kosina <jikos@kernel.org>,
        Xi Ruoyao <xry111@mengyan1223.wang>,
        Thomas Gleixner <tglx@linutronix.de>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Ingo Molnar <mingo@kernel.org>,
        Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
        Borislav Petkov <bp@alien8.de>, Len Brown <lenb@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
        Tony Luck <tony.luck@intel.com>,
        Bob Moore <robert.moore@intel.com>,
        Erik Schmauss <erik.schmauss@intel.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Daniel Bristot de Oliveira <bristot@redhat.com>
Subject: Re: [GIT PULL] x86/topology changes for v5.3
Message-ID: <201907110806.9C79329@keescook>
References: <201907091727.91CC6C72D8@keescook>
 <1ad2de95e694a29909801d022fe2d556df9a4bd5.camel@mengyan1223.wang>
 <cb6d381ed7cd0bf732ae9d8f30c806b849b0f94b.camel@mengyan1223.wang>
 <alpine.DEB.2.21.1907101404570.1758@nanos.tec.linutronix.de>
 <nycvar.YFH.7.76.1907101425290.5899@cbobk.fhfr.pm>
 <768463eb26a2feb0fcc374fd7f9cc28b96976917.camel@mengyan1223.wang>
 <20190710134433.GN3402@hirez.programming.kicks-ass.net>
 <nycvar.YFH.7.76.1907101621050.5899@cbobk.fhfr.pm>
 <89EBC357-BEAC-4252-915F-E183C2D350C4@vmware.com>
 <20190711080134.GT3402@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190711080134.GT3402@hirez.programming.kicks-ass.net>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jul 11, 2019 at 10:01:34AM +0200, Peter Zijlstra wrote:
> On Thu, Jul 11, 2019 at 07:11:19AM +0000, Nadav Amit wrote:
> > > On Jul 10, 2019, at 7:22 AM, Jiri Kosina <jikos@kernel.org> wrote:
> > > 
> > > On Wed, 10 Jul 2019, Peter Zijlstra wrote:
> > > 
> > >> If we mark the key as RO after init, and then try and modify the key to
> > >> link module usage sites, things might go bang as described.
> > >> 
> > >> Thanks!
> > >> 
> > >> 
> > >> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> > >> index 27d7864e7252..5bf7a8354da2 100644
> > >> --- a/arch/x86/kernel/cpu/common.c
> > >> +++ b/arch/x86/kernel/cpu/common.c
> > >> @@ -366,7 +366,7 @@ static __always_inline void setup_umip(struct cpuinfo_x86 *c)
> > >> 	cr4_clear_bits(X86_CR4_UMIP);
> > >> }
> > >> 
> > >> -DEFINE_STATIC_KEY_FALSE_RO(cr_pinning);
> > >> +DEFINE_STATIC_KEY_FALSE(cr_pinning);
> > > 
> > > Good catch, I guess that is going to fix it.
> > > 
> > > At the same time though, it sort of destroys the original intent of Kees' 
> > > patch, right? The exploits will just have to call static_key_disable() 
> > > prior to calling native_write_cr4() again, and the protection is gone.
> > 
> > Even with DEFINE_STATIC_KEY_FALSE_RO(), I presume you can just call
> > set_memory_rw(), make the page that holds the key writable, and then call
> > static_key_disable(), followed by a call to native_write_cr4().
> 
> Or call text_poke_bp() with the right set of arguments.

Right -- the point is to make it defended against an arbitrary write,
not arbitrary execution. Nothing is safe from arbitrary exec, but we can
do our due diligence on making things read-only.

-- 
Kees Cook