Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Sep 2024 10:14:36 -0500
From:      Kyle Evans <kevans@FreeBSD.org>
To:        Robert Clausecker <fuz@FreeBSD.org>, src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org
Subject:   Re: git: 76c2b331bcd9 - main - lib/libc/amd64/string: add timingsafe_bcmp(3) scalar, baseline implementations
Message-ID:  <46ddb4e7-2dfe-4f00-9210-1d482e03ef27@FreeBSD.org>
In-Reply-To: <202310151931.39FJVIpF088761@gitrepo.freebsd.org>
References:  <202310151931.39FJVIpF088761@gitrepo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46ddb4e7-2dfe-4f00-9210-1d482e03ef27>