[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c83b4d34-8447-03dd-1068-99aaa159e04b@intel.com>
Date: Mon, 19 Sep 2022 11:30:09 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
Cc: "peterz@...radead.org" <peterz@...radead.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"Lutomirski, Andy" <luto@...nel.org>,
"Liu, Yujie" <yujie.liu@...el.com>, "bp@...en8.de" <bp@...en8.de>
Subject: Re: [PATCH] x86/mm: Set NX bit when making pages present
On 9/19/22 11:14, Edgecombe, Rick P wrote:
> Clearly somehow it is though. The original report has this in the log:
> Notice: NX (Execute Disable) protection cannot be enabled: non-PAE
> kernel!
Ah, crud. Nice catch, btw.
So, the CPU has NX, making cpu_feature_enabled(X86_FEATURE_NX)==1, but
the page table mode does not have support.
I guess we can either clear X86_FEATURE_NX around the "protection cannot
be enabled" message, or do something like the attached patch and just do
the check at runtime.
I'm not sure we want to mess with X86_FEATURE_NX itself. It seems to
get used for a few different things, including on the KVM side.
0day folks, can you see if _this_ one (totally untested) helps the
situation? At least this is a real oddball case. It's not something
that folks are very likely to hit at all.
View attachment "nx.patch" of type "text/x-patch" (923 bytes)
Powered by blists - more mailing lists