From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fb.mail.gandi.net (spool7.mail.gandi.net [217.70.178.216]) by nmboxes7-ms7.sd4.0x35.net (Postfix) with ESMTPS id D139961930 for ; Tue, 16 Jan 2024 07:25:30 +0000 (UTC) Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by fb.mail.gandi.net (Postfix) with ESMTPS id 561F16035D for ; Tue, 16 Jan 2024 07:25:30 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=LF0lBaiWxGzDclF0baK/9dZuQH05VzdneAryBPTy2Js=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1705389929; v=1; b=DBKy123f8RJpo5zZ1qUqKYV3rFXDEJftDf1l3h224RX700AaSFQeLgx1jaMmPNcocFjXxhTb I4As7wu6V5gfq2WPdwYVI1Tmi6TsL9Xa1xeTYym/eD522GrDfsWVxkU9c2JesnUROnTTK08VPlM RaXipns02RquxA2zfiu7ThEQ= X-Received: by 127.0.0.2 with SMTP id 5zY8YY7687511x4deZrV5zGz; Mon, 15 Jan 2024 23:25:29 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.78130.1705322328464434704 for ; Mon, 15 Jan 2024 04:38:48 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-498-Xi5L2OjSMSGc5zaLcArusg-1; Mon, 15 Jan 2024 07:38:44 -0500 X-MC-Unique: Xi5L2OjSMSGc5zaLcArusg-1 X-Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EF339833944; Mon, 15 Jan 2024 12:38:43 +0000 (UTC) X-Received: from [10.39.193.170] (unknown [10.39.193.170]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 204E6492BFA; Mon, 15 Jan 2024 12:38:42 +0000 (UTC) Message-ID: <3487014c-3a2b-4a4d-955e-ef4fa5fd81b8@redhat.com> Date: Mon, 15 Jan 2024 13:38:42 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH 0/4] OvmfPkg/VirtNorFlashDxe: fix corruption + misc small improvements From: "Laszlo Ersek" To: devel@edk2.groups.io, kraxel@redhat.com Cc: Ard Biesheuvel , Jiewen Yao , oliver@redhat.com References: <20240112113754.14710-1-kraxel@redhat.com> <01ac5fab-2710-4231-a7cd-1c550fa6319f@redhat.com> In-Reply-To: <01ac5fab-2710-4231-a7cd-1c550fa6319f@redhat.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: TlmUcuPjHjMPMbb2g3sx0vHLx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: fb.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=DBKy123f; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (fb.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 1/15/24 11:21, Laszlo Ersek wrote: > - please only ever apply the bit-neg operator on values that are UINT32, > UINTN, or UINT64. Otherwise we get sign bit flipping, and that's > terrible. (Most people are not even aware of it happening.) Doing this is BTW not as obvious as it might seem, at first sight. It's good to remember some points about integer constants: - assuming a naked constant (no 0x or 0 prefix, and no suffix such as l, or u), the types considered are int, long, long long, in this order, by the compiler, for the value (whichever fits first). That is: a "naked" integer constant will *always* be signed. - assuming an octal or hex prefix (0 or 0x), the candidate type list is only *extended*; in other words, these prefixes don't *force* the type to be unsigned, only *permit* it. The list becomes int, unsigned, long, unsigned long, long long, unsigned long long. This is why 0x7F is just "int", for example. However, 0x8000_0000 is not "int" anymore, but "unsigned" (the value doesn't fit in "int", and the 0x prefix "permits" "unsigned int"). - The suffixes do restrict the candidate type list. The "u" (and U) suffixes remove the signed types, and add in the unsigned types. The list becomes unsigned, unsigned long, unsigned long long. Furthermore, the "l" and "ll" suffixes force (restrict) the type selection along a different axis: they set the minimum integer "conversion rank", so to say. The head of the list is trimmed so that the first candidate have the specified rank. So with just an "l" suffix, the normal candidate type list "int, long, long long" gets trimmed to "long, long long". Assuming an "u" suffix in place already, adding the "l" suffix trims the candidate type list "unsigned, unsigned long, unsigned long long" to "unsigned long, unsigned long long". Assuming a 0x prefix and no "u" suffix to begin with, appending the "l" suffix trims the type list "int, unsigned, long, unsigned long, long long, unsigned long long" to "long, unsigned long, long long, unsigned long long". The "shorthand" to remember is: "prefixes permit, suffixes force". Why I'm posting this wall of text: if we have a macro BOUNDARY_OF_32_WORDS #defined as 0x7F, or a macro BIT1 #defined as 0x00000002, those are *signed int* values. And applying the bit-neg operator ~ to them directly will flip the sign bit, and the resultant value will be *implementation-dependent*. Given that we use two's complement representation, the resultant value will always be signed int with a negative value. (In a sign-and-magnitude representation e.g., where there is +0 and -0, we'd have to think further.) And then, for example in: Offset & ~BOUNDARY_OF_32_WORDS the negative value of the RHS is converted to the (unsigned) type of the LHS [*], due to the default arithmetic conversions that are specified for the & operator (too). This is done with the usual modular addition / reduction. So, when most people think that the above expression is simple bit-fiddling, there are actually *two steps* that they miss: first, the creation of a negative value of type "signed int" (using two's complement representation), and then the reduction of that negative "signed int" value to the (possibly wider) unsigned value range that the other type is capable of representing [*]. [*] I'm taking some shortcuts here. The actual result type of the usual arithmetic conversions (the "common real type for the operands and result") is more complicated, but I won't describe all that here. It can be read in the C std (drafts). This is why I insist on one of two things in all such cases: - either writing the expression as Offset & ~(UINTN)BOUNDARY_OF_32_WORDS where UINTN is supposed to match the type of Offset precisely, - or #defining BOUNDARY_OF_32_WORDS already as an unsigned type -- either with an explicit cast ((UINTN)0x7F), or with a suitable suffix (0x7Fllu). Laszlo -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#113820): https://edk2.groups.io/g/devel/message/113820 Mute This Topic: https://groups.io/mt/103680930/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-