linux-kernel - Re: [PATCH v2 1/6] x86/bugs: Add asm helpers for executing VERW

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DD2F34A0-4F2F-4C8C-A634-7DBEF31C40F0@zytor.com>
Date:   Tue, 24 Oct 2023 11:27:36 -0700
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Sean Christopherson <seanjc@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>, tony.luck@...el.com,
        ak@...ux.intel.com, tim.c.chen@...ux.intel.com,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        kvm@...r.kernel.org,
        Alyssa Milburn <alyssa.milburn@...ux.intel.com>,
        Daniel Sneddon <daniel.sneddon@...ux.intel.com>,
        antonio.gomez.iglesias@...ux.intel.com,
        Alyssa Milburn <alyssa.milburn@...el.com>
Subject: Re: [PATCH  v2 1/6] x86/bugs: Add asm helpers for executing VERW

On October 24, 2023 10:02:48 AM PDT, Peter Zijlstra <peterz@...radead.org> wrote:
>On Tue, Oct 24, 2023 at 09:45:20AM -0700, Pawan Gupta wrote:
>
>> > > modules being within 4GB of kernel.
>
>FWIW, it's 2G, it's a s32 displacement, the highest most address can
>jump 2g down, while the lowest most address can jump 2g up. Leaving a 2G
>directly addressable range.
>
>And yeah, we ensure kernel text and modules are inside that 2G range.

To be specific, we don't require that it is located at any particular *physical* addresses, but all modules including the root module are remapped into the [-2GiB,0) range. If we didn't do that, modules would have to be compiled with the pic memory model rather than the kernel memory model which is what they currently are. This would add substantial overhead due to the need for a GOT (the PLT is optional if all symbols are resolved at load time.)

The kernel is different from user space objects since it is always fully loaded into physical memory and is never paged or shared. Therefore, inline relocations, which break sharing and create dirty pages in user space, have zero execution cost in the kernel; the only overhead to modules other than load time (including the runtime linking) is that modules can't realistically be mapped using large page entries.