Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 27 Oct 2022 14:40:14 +0200
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
To:     Mark Rutland <mark.rutland@arm.com>
Cc:     Ard Biesheuvel <ardb@kernel.org>, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
        Eric Biggers <ebiggers@kernel.org>,
        Kees Cook <keescook@chromium.org>,
        Suzuki K Poulose <suzuki.poulose@arm.com>,
        Adam Langley <agl@google.com>,
        James Morse <james.morse@arm.com>
Subject: Re: [RFC PATCH] arm64: Enable data independent timing (DIT) in the
 kernel
Message-ID: <Y1p8LjXoAjPkWdL+@zx2c4.com>
References: <20221027112741.1678057-1-ardb@kernel.org>
 <Y1p1oKCE+paB8JUK@FVFF77S0Q05N>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <Y1p1oKCE+paB8JUK@FVFF77S0Q05N>
Precedence: bulk

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