linux-kernel - Re: [GIT pull] x86/asm for 5.1

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-next>] [day] [month] [year] [list]

Date:   Mon, 11 Mar 2019 13:36:40 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [GIT pull] x86/asm for 5.1

On Mon, Mar 11, 2019 at 12:23 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Mon, Mar 11, 2019, 12:14 Kees Cook <keescook@...omium.org> wrote:
>>
>> >
>> >         this_cpu_write(cpu_tlbstate.cr4, __read_cr4() | cr4_pin);
>> >
>> ..
>>
>> The protection needs to be around the actual "mov %rdi, %cr4" that
>> native_write_cr4() exposes,
>
>
> You misunderstand.
>
> The above is just the "initialise cr4 shadow cache" case.
>
> If you do the above, I think we may have cr4 values initialled early enough that all CPUs can then just use the "check that the pinned bits were set" unconditionally in the actual routine that changes cr4.

Oh! I see what you mean -- separate the or and test. Okay, I'll look
at that too.

-- 
Kees Cook