Date: Mon, 16 Sep 2024 14:51:24 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Kyle Evans <kevans@freebsd.org> Cc: 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: <ZugbvJObL5XApNhC@kib.kiev.ua> In-Reply-To: <46ddb4e7-2dfe-4f00-9210-1d482e03ef27@FreeBSD.org> References: <202310151931.39FJVIpF088761@gitrepo.freebsd.org> <46ddb4e7-2dfe-4f00-9210-1d482e03ef27@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZugbvJObL5XApNhC>