From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 251AEFA3740 for ; Thu, 27 Oct 2022 12:41:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=9e1LFBXiCNzhOotRf6BvYE00jt68WQDVnM2TmajRh2A=; b=iMXvAZkEiXWSBV JkqNOPPqYaEIxiaFbO849SRE1GL96bYCkJIauDmG20eDp+9x52NoKozvh27xkLykhHX5brmGtLCWl Sv2HDnscyYpc2wdHOX3whfFOeVPsvUEntbdPONusvbIysJGOw6CZzcckF+gipUTgGUbDom8IruK+K 6t0uglfFopNMPNdMCapjsoG+8H5lN6EtpvRymkLLod0OJTBHGjpd17qHoKUjpDK+kRUDVZRnCPHCh NasUUEYdbThwpwEHeJjpXCE8UsHOIJRWimFQgotEL7zDAthczCfXdQ94twLLwwrcNySWDLo5GD50X lz9RX5b5+hToovddavnA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oo2Bh-00DCeo-Mo; Thu, 27 Oct 2022 12:40:45 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oo2Be-00DCe4-CY for linux-arm-kernel@lists.infradead.org; Thu, 27 Oct 2022 12:40:44 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 65928B825E6; Thu, 27 Oct 2022 12:40:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1C13C433C1; Thu, 27 Oct 2022 12:40:37 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="LkTirsK8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1666874436; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pj9a76Gy5EIhvCgh1tn+VtUpUQsCC06v3G1EotgJVMo=; b=LkTirsK8nmkzFwQL0kKsg47ZKNB1kGianxNTTV0XlcMhv3oFXN4E9GwBAO5Z/MviCdXvVh J1bpLikrl1KoUR86EsLopow+WagD0UVWMMYmpZAXpgzlvu5v8igNbCtkeML1nCtpvAogGC WzLLRTcssPa6c/TnUdoggNsU8VAMl1A= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 51af9fd4 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 27 Oct 2022 12:40:35 +0000 (UTC) Date: Thu, 27 Oct 2022 14:40:14 +0200 From: "Jason A. Donenfeld" To: Mark Rutland Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Marc Zyngier , Eric Biggers , Kees Cook , Suzuki K Poulose , Adam Langley , James Morse Subject: Re: [RFC PATCH] arm64: Enable data independent timing (DIT) in the kernel Message-ID: References: <20221027112741.1678057-1-ardb@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221027_054042_977945_EEE27D2D X-CRM114-Status: GOOD ( 28.57 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Oct 27, 2022 at 01:12:16PM +0100, Mark Rutland wrote: > I appreciate this is a simple way to rule out issues of that sort, but I think > the "may" in that sentence is doing a lot of work, since: > > * IIUC, we don't have a specific case in mind that we're concerned about. I can > believe that we think all the crypto code we intend to be constant time is > theoretically affected. > > * IIUC we haven't gone an audited all constant-time code to check it doesn't > happen to use instructions with data-dependent-timing. So there might be more > work to do atop this to ensure theoretical correctness. > > * AFAIK there are no contemporary implementations where the DIT is both > implemented and it being clear results in data-dependent-timing. i.e. we have > nothing to actually test on. > > I have a slight fear that (as above) if there are future CPUs which do consider > DIT, there's presumably a noticeable performance difference (or the CPU would > just provide data-independent-timing regardless), but I'm not sure if that's > just something we have to live with or could punt on until we notice such > cases. You're heading on a road to disaster reasoning like that. You wrote, "we don't have a specific case in mind that we're concerned about", but actually, all you can say here is that you're not personally aware of a specific case in mind to be concerned about. As somebody who actually works on this code, I do have specific cases I'm worried about, and I know there are certain assumptions I've made about various coding patterns being CT, resulting in various instructions that I assume to be CT, which is something I tend to check by hand, while others have entire frameworks to automatically verify this kind of thing. In other words, one man's theory is another man's practice. Then you write that there aren't any contemporary instructions where this matters, but you fear they could come up in the future. Okay, good, that's a perspective we can both share. The logical thing to do about that would be Ard's patch here. However, you then conclude something vague about performance and suggest punting this down the road. I guess this makes sense to you because you don't think timing attacks are real anyway. You're entitled to your opinion, of course, but I don't think it's a popular one, and it certainly is contrary to that of most implementers of the concerned code. On the contrary, we should be proactive in ensuring the kernel remains a suitable environment for CT code, preventing the problem *before* it happens, rather than having to deal with vulnerability response down the road, "punt[ing]" it, as you said. And perhaps if we handle this now, CPU designers also won't feel like they can get away with silly performance gains at the cost of CT instructions. Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel