Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Feb 2019 11:09:25 -0800
From: Nadav Amit <>
To: Borislav Petkov <>
Cc: Rick Edgecombe <>,
 Andy Lutomirski <>,
 Ingo Molnar <>,
 LKML <>,
 X86 ML <>,
 "H. Peter Anvin" <>,
 Thomas Gleixner <>,
 Dave Hansen <>,
 Peter Zijlstra <>,
 Damian Tometzki <>,
 linux-integrity <>,
 LSM List <>,
 Andrew Morton <>,
 Kernel Hardening <>,
 Linux-MM <>,
 Will Deacon <>,
 Ard Biesheuvel <>,
 Kristen Carlson Accardi <>,
 "Dock, Deneen T" <>,
 Kees Cook <>,
 Dave Hansen <>,
 Masami Hiramatsu <>
Subject: Re: [PATCH v2 10/20] x86: avoid W^X being broken during modules

> On Feb 11, 2019, at 11:01 AM, Borislav Petkov <> wrote:
> On Mon, Feb 11, 2019 at 10:45:26AM -0800, Nadav Amit wrote:
>> Are you sure about that? This path is still used when modules are loaded.
> Yes, I'm sure. Loading a module does a gazillion things so saving a
> couple of insns - yes, boot_cpu_has() is usually a RIP-relative MOV and a
> TEST - doesn't show even as a blip on any radar.

I fully agree, if that is the standard.

It is just that I find the use of static_cpu_has()/boot_cpu_has() to be very
inconsistent. I doubt that show_cpuinfo_misc(), copy_fpstate_to_sigframe(),
or i915_memcpy_init_early() that use static_cpu_has() are any hotter than

Anyhow, I’ll use boot_cpu_has() as you said.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.