linux-kernel - Re: x86, possible bug in __memmove() alternatives patching

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: <6e8f0e63-5e21-3694-3e76-290e3fe58e9d@intel.com>
Date:   Wed, 30 Mar 2022 07:44:14 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Matthias Welwarsky <matthias.welwarsky@...go.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org, x86-ml <x86@...nel.org>
Subject: Re: x86, possible bug in __memmove() alternatives patching

On 3/30/22 06:56, Matthias Welwarsky wrote:
> 
> Here's the relevant bits:
> 
>         /* FSRM implies ERMS => no length checks, do the copy directly */
> .Lmemmove_begin_forward:
>         ALTERNATIVE "cmp $0x20, %rdx; jb 1f", "", X86_FEATURE_FSRM
>         ALTERNATIVE "", __stringify(movq %rdx, %rcx; rep movsb; RET), 
> X86_FEATURE_ERMS
> 
> If FSRM is there but ERMS isn't, the first ALTERNATIVE is activated but not 
> the second one. That means the length check (< 32) and subsequent "jb 1f" is 
> suppressed but the "movq %rdx, %rcx; rep movsb; RET" is also not there. 

Ahh, thanks for the explanation.  It would help if I wasn't reading the
code wrong.

> I'll send a patch. I think the same rationale applies to FSRM as to ERMS, 
> which gets manually cleared when IA32_MISC_ENABLE says that fast string ops 
> are not available. It will be a one liner added to the dependency table in 
> cpu-deps.c, making FSRM depend on ERMS so that it gets automatically cleared.

Sounds good.  Could you also add some of that explanation to a comment
__memmove and basically say that the code is broken if the dependency
isn't enforced?