From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id B1054D800D7 for ; Fri, 12 Jan 2024 18:50:37 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=r2kJuKNSvNrECUouwIO6D4V29VR+hAA3bMhfK4mMlWE=; c=relaxed/simple; d=groups.io; h=MIME-version:Subject:From:In-reply-to:Date:Cc:Message-id:References:To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-type:Content-transfer-encoding; s=20140610; t=1705085436; v=1; b=vPH9QYEgXW8QxNvSfSM/110MuyFA5exurdPzAtoYqluB2a99Qa8pt2myuytDmSUxMuZtQ/v3 ejeu+gL55u8PDKG0lFXOB64ZlnLNBTTSqBfZddqwVuNdehWrTZwYIbQPzER1DIhVeVmz7USE55p Kax10lE5+Ck6YhN1a0xN4wmw= X-Received: by 127.0.0.2 with SMTP id 7f97YY7687511xbcauZLMgrJ; Fri, 12 Jan 2024 10:50:36 -0800 X-Received: from rn-mailsvcp-mx-lapp03.apple.com (rn-mailsvcp-mx-lapp03.apple.com [17.179.253.24]) by mx.groups.io with SMTP id smtpd.web10.254.1705085435564384762 for ; Fri, 12 Jan 2024 10:50:35 -0800 X-Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-mx-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S7500AOTWC88S00@rn-mailsvcp-mx-lapp03.rno.apple.com> for devel@edk2.groups.io; Fri, 12 Jan 2024 10:50:35 -0800 (PST) X-Proofpoint-ORIG-GUID: wF9vQfiu-L0yKdjkuBkAA9uyeTAe9myq X-Proofpoint-GUID: wF9vQfiu-L0yKdjkuBkAA9uyeTAe9myq X-Received: from rn-mailsvcp-policy-lapp01.rno.apple.com (rn-mailsvcp-policy-lapp01.rno.apple.com [17.179.253.18]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S7500X8BWC948B0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Fri, 12 Jan 2024 10:50:33 -0800 (PST) X-Received: from process_milters-daemon.rn-mailsvcp-policy-lapp01.rno.apple.com by rn-mailsvcp-policy-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.22.20230228 64bit (built Feb 28 2023)) id <0S7500300W4JB300@rn-mailsvcp-policy-lapp01.rno.apple.com>; Fri, 12 Jan 2024 10:50:33 -0800 (PST) X-Va-A: X-Va-T-CD: d54305ca0bb385d5345904a18454ef56 X-Va-E-CD: d38c7c8a8a09a1683f7c6688ae4723e1 X-Va-R-CD: 610f65e57ba77b9f82334b7102a66226 X-Va-ID: d1fbc58c-3289-42ef-971b-6cb1f00b9246 X-Va-CD: 0 X-V-A: X-V-T-CD: d54305ca0bb385d5345904a18454ef56 X-V-E-CD: d38c7c8a8a09a1683f7c6688ae4723e1 X-V-R-CD: 610f65e57ba77b9f82334b7102a66226 X-V-ID: 8bcb2bdd-2392-46ba-bc1b-a03216b819af X-V-CD: 0 X-Received: from smtpclient.apple (unknown [17.234.110.227]) by rn-mailsvcp-policy-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.22.20230228 64bit (built Feb 28 2023)) with ESMTPSA id <0S750035LWC8UE00@rn-mailsvcp-policy-lapp01.rno.apple.com>; Fri, 12 Jan 2024 10:50:33 -0800 (PST) MIME-version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: [edk2-devel] Memory Attribute for depex section From: "Andrew Fish via groups.io" In-reply-to: Date: Fri, 12 Jan 2024 10:50:22 -0800 Cc: Laszlo Ersek , edk2-devel-groups-io , nhi@os.amperecomputing.com, "ardb+tianocore@kernel.org" Message-id: <36CD245F-C2CD-474E-9401-155F56F52C3B@apple.com> References: <44ca139f-4d78-4322-b5b6-8e9788bb7486@os.amperecomputing.com> <2ad16043-754e-3bb9-3a4a-702d9a50bf63@redhat.com> <45b95719-f1fc-dbc6-a4cc-a022d691844c@redhat.com> <30901646-905c-798c-d088-255498028fff@redhat.com> <7659165f-a73b-b628-59fe-c29e67beb850@redhat.com> To: Pedro Falcato 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,afish@apple.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: G0xdfKNtUuMv7WgEYYe6ZwYJx7686176AA= Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=vPH9QYEg; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=none > On Jan 12, 2024, at 6:46=E2=80=AFAM, Pedro Falcato wrote: >=20 > On Fri, Jan 12, 2024 at 9:35=E2=80=AFAM Laszlo Ersek = wrote: >>=20 >> On 1/12/24 03:10, Pedro Falcato wrote: >>> My idea was to make each handle an index - like a file descriptor - >>> AFAIK there's no reason why it *needs* to be an actual pointer. >>> We'd allocate indices when creating a handle, and return that (casted t= o VOID*). >>=20 >> Huh, sneaky. >>=20 >> I see two potential problems with this. >>=20 >> First, per C std, these "pointers" would be invalid (they wouldn't >> actually point to valid memory), so even just evaluating them (not >> dereferencing them!) would invoke undefined behavior. May or may not >> matter in practice. With compilers getting smarter about optimization >> (and stricter about std conformance), there could be issues, perhaps. >=20 > This is true. Stashing random integers in pointers is > implementation-defined. But it's also super common. Win32 HANDLEs are > exactly this, just integers (stashed in VOID*). The Linux kernel world > also has a bunch of fun tricks with stashing flags in a pointer's > bottom bits, magic pointer values, etc. I severely doubt we can run > into issues with this. EDK2 will not exactly run on the C standard's > abstract machine anyway ;) >=20 I=E2=80=99d point out that CPUs we support do magic things with bits of poi= nters. ARMv8.3 defines pointer authentication and on a Mac arm64e is an ABI= with pointer authentication enabled.=20 Given call return rules are different and you have to initialize signed poi= nters it is a different ABI, but never say never that a signed pointer ABI = could get added to UEFI. Thanks, Andrew Fish >>=20 >> The other concern is a bit contrived, but I *guess* there could be code >> out there that actually dereferences EFI_HANDLEs. That code would crash. >> May or may not matter, because such code is arguably already >> semantically invalid. (It would not necessarily be invalid at the >> language level -- cf. my previous paragraph --, because passing an >> otherwise valid EFI_HANDLE to CopyMem, for copying just 1 byte out of >> the underlying opaque data structure, would not violate the language.) >=20 > This is a feature, not a bug! :P >=20 > Seriously though, IHANDLE is not even exposed in semi-public headers, > so any code that's derefing an EFI_HANDLE will need to do something > like >=20 > typedef struct { > /* ... */ > } IHANDLE; >=20 > EFI_HANDLE Handle =3D /* ... */; >=20 > IHANDLE *HandleImpl =3D (IHANDLE *) Handle; >=20 > and I'm a strong believer in "play stupid games, win stupid prizes". > You can definitely make an argument for "this should definitely crash" > instead of just "maybe crashing" (for instance, platforms that still > map the NULL page (like OVMF!), or handles > 4096), so I'm inclined to > think that if we indeed go this route, we should set one or two upper > bits (on 64-bit platforms!) to make handles non-canonical addresses > and therefore necessarily crash on dereference. >=20 >>=20 >>> I should note that I find it super hard to get a concrete idea on >>> performance for EFI firmware without adequate tooling - I meant to >>> write a standalone flamegraph tool a few weeks back (even posted in >>> edk2-devel), but, as far as I could tell, the architectural timer >>> protocol couldn't get me the interrupt frame[1]. Until then, whether >>> any of this radix tree vs RB tree vs flat array stuff really >>> matters... I find it hard to say. >>>=20 >>> [1] x86 has 3 timers (PIT, LAPIC timer, HPET) and performance >>> monitoring interrupts, and I couldn't freely use any of them :^) >>=20 >> Edk2 has some form of profiling already (see >> "MdePkg/Include/Library/PerformanceLib.h"). Usually one sees core code >> peppered with PERF_CODE_BEGIN and PERF_CODE_END macros. I *think* there >> is something like a "display performance" (dp) shell application too, >> that can show the collected stats. But I've never used these facilities. >>=20 >> The wiki seems to have two related articles: >>=20 >> https://github.com/tianocore/tianocore.github.io/wiki/Edk2-Performance-I= nfrastructure >>=20 >> https://github.com/tianocore/tianocore.github.io/wiki/PerformancePkg >>=20 >> The former looks quite comprehensive, at a quick skim. >=20 > /me nods > I've seen those macros around, but I've never used them. > In any case, this problem has piqued my interest, I'll see if I can > find some free time this weekend to hack on a test benchmark and a PoC > :) >=20 > --=20 > Pedro -=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 (#113753): https://edk2.groups.io/g/devel/message/113753 Mute This Topic: https://groups.io/mt/103594587/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-