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 <[email protected]>
AuthorDate: 2023-08-30 15:37:26 +0000
Commit: Robert Clausecker <[email protected]>
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
