[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220221092456.GJ23216@worktop.programming.kicks-ass.net>
Date: Mon, 21 Feb 2022 10:24:56 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Kees Cook <keescook@...omium.org>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
"Poimboe, Josh" <jpoimboe@...hat.com>,
"hjl.tools@...il.com" <hjl.tools@...il.com>,
"x86@...nel.org" <x86@...nel.org>,
"joao@...rdrivepizza.com" <joao@...rdrivepizza.com>,
"Cooper, Andrew" <andrew.cooper3@...rix.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mark.rutland@....com" <mark.rutland@....com>,
"samitolvanen@...gle.com" <samitolvanen@...gle.com>,
"ndesaulniers@...gle.com" <ndesaulniers@...gle.com>,
"Milburn, Alyssa" <alyssa.milburn@...el.com>
Subject: Re: [PATCH 00/29] x86: Kernel IBT
On Mon, Feb 21, 2022 at 12:42:25AM -0800, Kees Cook wrote:
> >+void cet_disable(void)
> >+{
> >+ cr4_clear_bits(X86_CR4_CET);
>
> I'd rather keep the pinning...
Uff. is that still enforced at this point?
> >+ wrmsrl(MSR_IA32_S_CET, 0);
> >+}
>
> Eh, why not just require kexec to be IBT safe? That seems a reasonable
> exercise if we ever expect UEFI to enforce IBT when starting the
> kernel on a normal boot...
Well, it makes it impossible to kexec into an 'old' kernel. That might
not be very nice.
Powered by blists - more mailing lists