netdev - Re: [PATCH v3 00/16] Introduce and use generic parity16/32/64 helper

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <EF4335E0-F8EB-4642-BD09-B16BCCF23F95@zytor.com>
Date: Sun, 09 Mar 2025 09:00:58 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Kuan-Wei Chiu <visitorckw@...il.com>
CC: David Laight <david.laight.linux@...il.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        Laurent.pinchart@...asonboard.com, airlied@...il.com,
        akpm@...ux-foundation.org, alistair@...ple.id.au,
        andrew+netdev@...n.ch, andrzej.hajda@...el.com,
        arend.vanspriel@...adcom.com, awalls@...metrocast.net, bp@...en8.de,
        bpf@...r.kernel.org, brcm80211-dev-list.pdl@...adcom.com,
        brcm80211@...ts.linux.dev, dave.hansen@...ux.intel.com,
        davem@...emloft.net, dmitry.torokhov@...il.com,
        dri-devel@...ts.freedesktop.org, eajames@...ux.ibm.com,
        edumazet@...gle.com, eleanor15x@...il.com, gregkh@...uxfoundation.org,
        hverkuil@...all.nl, jernej.skrabec@...il.com, jirislaby@...nel.org,
        jk@...abs.org, joel@....id.au, johannes@...solutions.net,
        jonas@...boo.se, jserv@...s.ncku.edu.tw, kuba@...nel.org,
        linux-fsi@...ts.ozlabs.org, linux-input@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
        linux-mtd@...ts.infradead.org, linux-serial@...r.kernel.org,
        linux-wireless@...r.kernel.org, linux@...musvillemoes.dk,
        louis.peens@...igine.com, maarten.lankhorst@...ux.intel.com,
        mchehab@...nel.org, mingo@...hat.com, miquel.raynal@...tlin.com,
        mripard@...nel.org, neil.armstrong@...aro.org, netdev@...r.kernel.org,
        oss-drivers@...igine.com, pabeni@...hat.com,
        parthiban.veerasooran@...rochip.com, rfoss@...nel.org, richard@....at,
        simona@...ll.ch, tglx@...utronix.de, tzimmermann@...e.de,
        vigneshr@...com, x86@...nel.org, yury.norov@...il.com
Subject: Re: [PATCH v3 00/16] Introduce and use generic parity16/32/64 helper

On March 9, 2025 8:48:26 AM PDT, Kuan-Wei Chiu <visitorckw@...il.com> wrote:
>On Fri, Mar 07, 2025 at 12:07:02PM -0800, H. Peter Anvin wrote:
>> On March 7, 2025 11:53:10 AM PST, David Laight <david.laight.linux@...il.com> wrote:
>> >On Fri, 07 Mar 2025 11:30:35 -0800
>> >"H. Peter Anvin" <hpa@...or.com> wrote:
>> >
>> >> On March 7, 2025 10:49:56 AM PST, Andrew Cooper <andrew.cooper3@...rix.com> wrote:
>> >> >> (int)true most definitely is guaranteed to be 1.  
>> >> >
>> >> >That's not technically correct any more.
>> >> >
>> >> >GCC has introduced hardened bools that intentionally have bit patterns
>> >> >other than 0 and 1.
>> >> >
>> >> >https://gcc.gnu.org/gcc-14/changes.html
>> >> >
>> >> >~Andrew  
>> >> 
>> >> Bit patterns in memory maybe (not that I can see the Linux kernel using them) but
>> >> for compiler-generated conversations that's still a given, or the manager isn't C
>> >> or anything even remotely like it.
>> >> 
>> >
>> >The whole idea of 'bool' is pretty much broken by design.
>> >The underlying problem is that values other than 'true' and 'false' can
>> >always get into 'bool' variables.
>> >
>> >Once that has happened it is all fubar.
>> >
>> >Trying to sanitise a value with (say):
>> >int f(bool v)
>> >{
>> >	return (int)v & 1;
>> >}    
>> >just doesn't work (see https://www.godbolt.org/z/MEndP3q9j)
>> >
>> >I really don't see how using (say) 0xaa and 0x55 helps.
>> >What happens if the value is wrong? a trap or exception?, good luck recovering
>> >from that.
>> >
>> >	David
>> 
>> Did you just discover GIGO?
>
>Thanks for all the suggestions.
>
>I don't have a strong opinion on the naming or return type. I'm still a
>bit confused about whether I can assume that casting bool to int always
>results in 0 or 1.
>
>If that's the case, since most people prefer bool over int as the
>return type and some are against introducing u1, my current plan is to
>use the following in the next version:
>
>bool parity_odd(u64 val);
>
>This keeps the bool return type, renames the function for better
>clarity, and avoids extra maintenance burden by having just one
>function.
>
>If I can't assume that casting bool to int always results in 0 or 1,
>would it be acceptable to keep the return type as int?
>
>Would this work for everyone?
>
>Regards,
>Kuan-Wei

You *CAN* safely assume that bool is an integer type which always has the value 0 or 1.