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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D54E9C433EF for ; Mon, 25 Apr 2022 13:33:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242139AbiDYNgy (ORCPT ); Mon, 25 Apr 2022 09:36:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242137AbiDYNgw (ORCPT ); Mon, 25 Apr 2022 09:36:52 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 18AB263B3 for ; Mon, 25 Apr 2022 06:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1650893626; 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=UqJWCWFq0Pii1oTW8QXvQWCpib7W/X1OWwkM6+ni6Dk=; b=ei5Q8dQJZxUc0hRXnFyZtNQA+gUidROEK6CB2kdbYUxG15uaG2KdPo5Llya1xdTLFnUrgh F+h6xJodKhEn3pS2hokgxErG3Mx9EzTrT98djbsUISK60LMZIa6ZUqkA+5d5hxLYdZMdhY 5eMI5NeemVBolsd83JLj6l83APeL+gk= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-369-pStr-jH9N5qRAaDNAazn6Q-1; Mon, 25 Apr 2022 09:33:38 -0400 X-MC-Unique: pStr-jH9N5qRAaDNAazn6Q-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5079B3834C16; Mon, 25 Apr 2022 13:33:38 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (file01.intranet.prod.int.rdu2.redhat.com [10.11.5.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 07E0654C75A; Mon, 25 Apr 2022 13:33:38 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (localhost [127.0.0.1]) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id 23PDXbKt006460; Mon, 25 Apr 2022 09:33:37 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id 23PDXaJZ006456; Mon, 25 Apr 2022 09:33:37 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Mon, 25 Apr 2022 09:33:36 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: David Laight cc: "'Linus Torvalds'" , Andy Shevchenko , device-mapper development , Linux Kernel Mailing List , Linux Crypto Mailing List , Herbert Xu , "David S. Miller" , Mike Snitzer , Mimi Zohar , Milan Broz Subject: RE: [PATCH] hex2bin: make the function hex_to_bin constant-time In-Reply-To: Message-ID: References: <789f0463ce974e90a93f4dbf8c471156@AcuMS.aculab.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, 25 Apr 2022, David Laight wrote: > From: Mikulas Patocka > > Sent: 25 April 2022 12:04 > > > > On Mon, 25 Apr 2022, David Laight wrote: > > > > > From: Linus Torvalds > > > > Sent: 24 April 2022 22:42 > > > > > > > > On Sun, Apr 24, 2022 at 2:37 PM Linus Torvalds > > > > wrote: > > > > > > > > > > Finally, for the same reason - please don't use ">> 8". Because I do > > > > > not believe that bit 8 is well-defined in your arithmetic. The *sign* > > > > > bit will be, but I'm not convinced bit 8 is. > > > > > > > > Hmm.. I think it's ok. It can indeed overflow in 'char' and change the > > > > sign in bit #7, but I suspect bit #8 is always fine. > > > > > > > > Still, If you want to just extend the sign bit, ">> 31" _is_ the > > > > obvious thing to use (yeah, yeah, properly "sizeof(int)*8-1" or > > > > whatever, you get my drift). > > > > > > Except that right shifts of signed values are UB. > > > In particular it has always been valid to do an unsigned > > > shift right on a 2's compliment negative number. > > > > > > David > > > > Yes. All the standard versions (C89, C99, C11, C2X) say that right shift > > of a negative value is implementation-defined. > > > > So, we should cast it to "unsigned" before shifting it. > > Except that the intent appears to be to replicate the sign bit. > > If it is 'implementation defined' (rather than suddenly being UB) The standard says "If E1 has a signed type and a negative value, the resulting value is implementation-defined." So, it's not undefined behavior. > it might be that the linux kernel requires sign propagating > right shifts of negative values. It may be that some code in the Linux kernel already assumes that right shifts keep the sign. It's hard to say if such code exists. BTW. ubsan warns about left shift of negative values, but it doesn't warn about right shift of negative values. > This is typically what happens on 2's compliment systems. > But not all small cpu have the required shift instruction. > OTOH all the ones bit enough to run Linux probably do. > (And gcc doesn't support '1's compliment' or 'sign overpunch' cpus.) > > The problem is that the compiler writers seem to be entering > a mindset where they are optimising code based on UB behaviour. > So given: > void foo(int x) > { > if (x >> 1 < 0) > return; > do_something(); > } > they decide the test is UB, so can always be assumed to be true > and thus do_something() is compiled away. > > David If it's implementation-defined (rather than undefined), the compiler shouldn't do such optimization. The linux kernel uses "-fno-strict-overflow" which disables some of these UB optimizations. Mikulas