Re: git: 76c2b331bcd9 - main - lib/libc/amd64/string: add timingsafe_bcmp(3) scalar, baseline implementations

On 10/15/23 14:31, Robert Clausecker wrote:
> The branch main has been updated by fuz:
> 
> URL: https://cgit.FreeBSD.org/src/commit/?id=76c2b331bcd9f73c5c8c43a06e328fa0c7b8c39a
> 
> commit 76c2b331bcd9f73c5c8c43a06e328fa0c7b8c39a
> Author:     Robert Clausecker <fuz@FreeBSD.org>
> AuthorDate: 2023-08-30 15:37:26 +0000
> Commit:     Robert Clausecker <fuz@FreeBSD.org>
> CommitDate: 2023-10-15 19:19:04 +0000
> 
>      lib/libc/amd64/string: add timingsafe_bcmp(3) scalar, baseline implementations
>      
>      Very straightforward and similar to memcmp(3). The code has
>      been written to use only instructions specified as having
>      data operand independent timing by Intel.
>      
>      Sponsored by:   The FreeBSD Foundation
>      Approved by:    security (cperciva)
>      Differential Revision:  https://reviews.freebsd.org/D41673

Hi Robert,

I only just noticed this, but I have to admit that I'm pretty 
uncomfortable with the idea of rolling our own timingsafe assembly 
implementations in general.

My main concern is that, e.g., auditing timingsafe_bcmp.S will clearly 
take a lot longer than auditing the C counterpart, but also the audit 
requirements have gone up for every architecture you want to support 
that might be using this from a single simple C implementation to C + 
however many architectures end up rolling their own implementation in 
assembly after this.

Are these really used in enough perf-critical context to justify the 
additional complexity?  Did anyone *actually* verify the constant-time 
properties of these implementations?  I didn't really find any written 
confirmation of that, which I was really hoping for- we should have a 
much higher bar for changes like this.

Thanks,

Kyle Evans