Received: by 2002:a05:6a10:5594:0:0:0:0 with SMTP id ee20csp519491pxb; Mon, 25 Apr 2022 15:26:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwWp4hZMrNJDnlHE+q2X1dZsByJaXJ0EhK/skgSFZ+YTFCmaiAlD4XCaCHSK2DamPPUQILK X-Received: by 2002:a17:90a:a82:b0:1c9:ef95:486 with SMTP id 2-20020a17090a0a8200b001c9ef950486mr34021628pjw.93.1650925575086; Mon, 25 Apr 2022 15:26:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650925575; cv=none; d=google.com; s=arc-20160816; b=OWgKL+yjo2+lh/EZDR2OIVT9gyZw80P4Y2/aKcSe6zfyXX9wTeTHwlqLkgP+qOer2h e4j8k8RYSzUHaRdzcdr98taSR2N3VHM6PZfz4jUInOieKYSeD5rjti7EH5BgNKD3iDai W8SA+1O1TxGeaj7pvPKMLwZ1QmBdpzZNubAi4pllhd4yB18CiHRM+EtN9MRv+4Lcl0aK L+P94x/jKrW7L6IE1WtfBKGCDllXnc8Uk5M7Lr+xQ1Gjm6gKy/UWeVT0UptOi/MpHrCw 0RvnnnhC3MG1wlBEWUczzuWK4VSKjkt6TH4rmHME3xiw7Zs8OeNrYCaPZlwbrzVf2wCs n4gQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=/LM5ApeDrM+ZiQkhPKo2nD8z3VPb3CiZfRSSBlkwszA=; b=LBDRG8KIq/vqzKGyPdvYF4mC/3jZItxH3wIGTUG57/hM9xyVu+Ho7004LNERQV4u/S lUbHulldzU448oyT8S94NvFbFnzukvD3xUwwc2v9a64OBLOktlRDIovYj/IVY6mg45iT EYcloEWiuJF8/B/Evod+TcxX04tKFLV8Eyd9fFBcbJ7AvXRAMYk9vLzB4tbl0d/3w4yE CPEKSTsWKyOFnNHpKSDoGo9+9FAj/rgzk+w1t2kCheyqLiKuyzENtUjQCh7FLcSBSW10 VoCTyNFVLrd+hyBb9bYDciH12cA31WvXhI69ZzfLrP0z71Ri/csVA5Ysvu7oUF6yzj9K rSww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=BsY4pOkf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a8-20020a170902710800b00158cb2a835bsi16054498pll.438.2022.04.25.15.25.59; Mon, 25 Apr 2022 15:26:15 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=BsY4pOkf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244116AbiDYR4s (ORCPT + 99 others); Mon, 25 Apr 2022 13:56:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244109AbiDYR4q (ORCPT ); Mon, 25 Apr 2022 13:56:46 -0400 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C99810772F for ; Mon, 25 Apr 2022 10:53:42 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id w1so27559080lfa.4 for ; Mon, 25 Apr 2022 10:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/LM5ApeDrM+ZiQkhPKo2nD8z3VPb3CiZfRSSBlkwszA=; b=BsY4pOkfn3DG5B5zct/wRzU14afza6Td5Lww1u3ewMVuTqlUDLuuUSSqkL5GiYshCE Af5nvn4SN/67YfETMMEi2NtXlQOejoI+5yvUA5qfEs9uGHOdZvqJA8BxEijrFHNTDfUl aDeCEhneNkVbrDwdkHnVsK7wqLVmqL9Kk0+S8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/LM5ApeDrM+ZiQkhPKo2nD8z3VPb3CiZfRSSBlkwszA=; b=VoYDlhgmZM9+FcmJhSg3oQfsGoMKOjf4TExIBkj/du0VwrmfjAZjBpzPwTu/CumsTg uTlSEUkenzSCvWtIBuPnxMLrP/bRkStBgO7zIi5DLHDSVCrYqNzZhhodidAl0T6d8lrK 4XNzREzE5S50o7Roe0QhSHYVEGeKY8+bSd6EjrInAkE1FubaxyE+9O3/2VZdWKX7o4wv JJEMfqG9+LsCwHRsWEWIRWlAZt4Q3FscBUBjD+hEsyH7YzCg3PdGzqIV60w51VMoTh/s bsXUNI+qDXSOh0ZOb+tu127/sBn+cVsxOQQbZWXNYdRIiEFoln1A/ZAwH6Rz3XWTEtsU MB6Q== X-Gm-Message-State: AOAM531SfquPjDThu/u/PozsnlIcXENPKivLuoBaPHl8A/W59qzArPzQ ajjmWAY8xxpAHETzLHy8tYBssyXrBnkjJO6Z4/0= X-Received: by 2002:a19:4f56:0:b0:471:f883:7af0 with SMTP id a22-20020a194f56000000b00471f8837af0mr8720394lfk.284.1650909220194; Mon, 25 Apr 2022 10:53:40 -0700 (PDT) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com. [209.85.167.53]) by smtp.gmail.com with ESMTPSA id t5-20020a19dc05000000b004720e0fa073sm250221lfg.252.2022.04.25.10.53.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Apr 2022 10:53:39 -0700 (PDT) Received: by mail-lf1-f53.google.com with SMTP id bq30so27583345lfb.3 for ; Mon, 25 Apr 2022 10:53:39 -0700 (PDT) X-Received: by 2002:a05:6512:1193:b0:471:af88:2d74 with SMTP id g19-20020a056512119300b00471af882d74mr13719233lfr.531.1650909219017; Mon, 25 Apr 2022 10:53:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Mon, 25 Apr 2022 10:53:22 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] hex2bin: make the function hex_to_bin constant-time To: Mikulas Patocka Cc: Andy Shevchenko , device-mapper development , Linux Kernel Mailing List , Linux Crypto Mailing List , Herbert Xu , "David S. Miller" , Mike Snitzer , Mimi Zohar , Milan Broz Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 25, 2022 at 5:07 AM Mikulas Patocka wrote: > > We are subtracting values that are in the 0 ... 255 range. Well, except that's not what the original patch did. It was subtracting values that were in the -128 ... 255 range (where the exact range depended on the sign of 'char'). But yeah, I think bit8 was always safe. Probably. Particularly as the possible ranges across different architectures is bigger than the range within one _particular_ architecture (so you'll never see "255 - -128" even when the sign wasn't defined ;) > > Also, I do worry that this is *exactly* the kind of trick that a > > compiler could easily turn back into a conditional. Usually compilers > > tend to go the other way (ie turn conditionals into arithmetic if > > possible), but.. > > Some old version that I tried used "(ch - '0' + 1) * ((unsigned)(ch - '0') > <= 9)" - it worked with gcc, but clang was too smart and turned it into a > cmov when compiling for i686 and to a conditional branch when compiling > for i586. > > Another version used "-(c - '0' + 1) * (((unsigned)(c - '0') >= 10) - 1)" > - it almost worked, except that clang still turned it into a conditional > jump on sparc32 and powerpc32. > > So, I came up with this version that avoids comparison operators at all > and tested it with gcc and clang on all architectures that I could try. Yeah, the thing about those compiler heuristics is that they are often based on almost arbitrary patterns that just happen to be what somebody has found in some benchmark. Hopefully nobody ever uses something like this as a benchmark. Linus