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

On Thu, Sep 12, 2024 at 10:14:36AM -0500, Kyle Evans wrote:
> 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.

Is such audit/ensurance is even possible at all for C implementation?
It can be only done against specific version of C compiler, and cannot
be extended to other compilers, at least with the current state of C
definition.

While CPU vendors do provide time-invariant guarantees for ISA.
For instance, Intel published a guidance
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html

that makes the property part of ISA.

I.e. for me it seems that only an assembler version can be timingsafe ATM.