From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resdmta-h1p-028482.sys.comcast.net (resdmta-h1p-028482.sys.comcast.net [IPv6:2001:558:fd02:2446::c]) by sourceware.org (Postfix) with ESMTPS id 5B0243858C52 for ; Wed, 16 Aug 2023 13:07:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5B0243858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=comcast.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=comcast.net Received: from resomta-h1p-028515.sys.comcast.net ([96.102.179.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resdmta-h1p-028482.sys.comcast.net with ESMTP id WEEtq69CQKSvQWGF5qRCPu; Wed, 16 Aug 2023 13:07:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1692191239; bh=sLUmA3TWWe5nXsC1X3Pe70cZo1iScVKfIAo6nCVEpLA=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To:Xfinity-Spam-Result; b=GMsemBGY51vqcKy+PsNg5SReBfr9qpVFeNafAoVG2P2n/EmLHNx4grk9Fpw5JoKJL QPwJvv9Q6f2ehGMZ1wnCqP5l/ryvCuA2jcc+1SS/PYs4jxbt0irw4r+GMmfqFrobuG kugNUvNTTLR+oYC5GEGdg1AJd/kKqPQzNRVzvNhtDPrtexPBf3QopKOErxwRijG5jR nQ4NlDgsV6iJn5D1PJpLz0v/r+hRY/iQ21R3WkRQar6qYVuAZHMh/flCz3TNRcU+vL lyDqEuwE2PE6H+Kaab+DbPm/K8TT5om1y+2hMiH4DPAbzYmsLkIApLDAKz/K5pOrM/ /nx6yEZVbdAmw== Received: from smtpclient.apple ([73.60.223.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-h1p-028515.sys.comcast.net with ESMTPSA id WGEeq08nxP1dtWGEfqhWzW; Wed, 16 Aug 2023 13:06:57 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedviedruddtledgiedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptggguffhjgffvefgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpefrrghulhcumfhonhhinhhguceophgruhhlkhhonhhinhhgsegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeevkeegfeevuedtheeiieevtdfghfdtjeehgfdtgfevfeegkedvhfffueeghfdtkeenucffohhmrghinhepfihikhhiphgvughirgdrohhrghenucfkphepjeefrdeitddrvddvfedruddtudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehsmhhtphgtlhhivghnthdrrghpphhlvgdpihhnvghtpeejfedriedtrddvvdefrddutddupdhmrghilhhfrhhomhepphgruhhlkhhonhhinhhgsegtohhmtggrshhtrdhnvghtpdhnsggprhgtphhtthhopeeipdhrtghpthhtoheprghmohhnrghkohhvsehishhprhgrshdrrhhupdhrtghpthhtohepughjvgdrghgttgesghhmrghilhdrtghomhdprhgtphhtthhopehsihguughhvghshhesghhothhplhhtrdhorhhgpdhrtghpthhtohepghgttgdqphgrthgthhgvshesghgttgdrghhnuhdrohhrghdprhgtphhtthhopegtrghrlhhoshesrhgvughhrghtrdgtohhmpdhrtghpthhtoheprhhitghhrghrugdrshgrnhguihhfohhrugesrghrmhdrtghomh Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Subject: Re: [RFC] GCC Security policy From: Paul Koning In-Reply-To: <0bf27558-92d6-a9db-497a-f1cf37c21d12@ispras.ru> Date: Wed, 16 Aug 2023 09:06:52 -0400 Cc: David Edelsohn , Siddhesh Poyarekar , GCC Patches , Carlos O'Donell , richard.sandiford@arm.com Content-Transfer-Encoding: quoted-printable Message-Id: <3C575D02-26C7-4CF3-AE23-7351EAF16294@comcast.net> References: <97b01db2-d1bf-9859-f75e-452e677ffe63@gotplt.org> <5f0e849e-92bf-8b4d-caff-602e37a0b75e@gotplt.org> <94529934-59a1-84e6-b93e-cd3e3ad82707@ispras.ru> <141b257b-a45d-0afc-5391-acd9547d6806@gotplt.org> <7462498c-3d65-a7bd-012e-2d9b200b0b1f@ispras.ru> <4c041fac-c363-9415-72d5-90df74b44abc@gotplt.org> <509079b9-ead2-c5d6-c0b5-233354a1140a@ispras.ru> <742a157b-2301-6cee-b333-791a1e37d6aa@ispras.ru> <0bf27558-92d6-a9db-497a-f1cf37c21d12@ispras.ru> To: Alexander Monakov X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > On Aug 16, 2023, at 3:53 AM, Alexander Monakov = wrote: >=20 >> ... >> Is "timing-safety" a security property? Not the way I understand = that >> term. It sounds like another way to say that the code meets real = time >> constraints or requirements. >=20 > I meant in the sense of not admitting timing attacks: > https://en.wikipedia.org/wiki/Timing_attack >=20 >> No, compilers don't help with that (at least C doesn't -- Ada might = be >> better here but I don't know enough). For sufficiently strict >> requirements you'd have to examine both the generated machine code = and >> understand, in gruesome detail, what the timing behaviors of the = executing >> hardware are. Good luck if it's a modern billion-transistor machine. >=20 > Yes. On the other hand, the reality in the FOSS ecosystem is that > cryptographic libraries heavily lean on the ability to express > a constant-time algorithm in C and get machine code that is actually > constant-time. There's a bit of a conflict here between what we > can promise and what people might expect of GCC, and it seems > relevant when discussing what goes into the Security Policy. I agree. What should be said is that such techniques are erroneous. = The kind of code you're talking about inserts steps not strictly needed = for the calculation to make it constant time (or more nearly so). But = clearly that has to rely on an assumption that the optimizer isn't smart = enough to spot those unnecessary operations and delete them. Never mind = the fact that it relies on a notion that C statements have timing = properties in the first place, which the standard doesn't do. So I would argue that a serious attempt to cure timing attacks has to be = coded in assembly language. Even then, of course, optimizations in = modern machine pipelines may give you trouble, but at least in that case = you're writing explicitly for a specific ISA and are in a position to = take into account its timing properties, to the extent they are known = and defined. paul