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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZugbvJObL5XApNhC>