From: "Michael D Kinney" <michael.d.kinney@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
"dionnaglaze@google.com" <dionnaglaze@google.com>,
"ayushdevel1325@gmail.com" <ayushdevel1325@gmail.com>,
"Kinney, Michael D" <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] Can NULL pointer be a valid event?
Date: Mon, 3 Oct 2022 17:54:37 +0000 [thread overview]
Message-ID: <CO1PR11MB4929774B24E1A8FE2DBEBA50D25B9@CO1PR11MB4929.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CAAH4kHadWZFuCv3O9hbR_KPS-A-8WKD5+Laafg3dykKGoOHXVw@mail.gmail.com>
Hi Ayush,
Quick answer is that the UEFI Spec may not explicitly disallow NULLL, but in practice,
it will never return NULL.
===================================
EFI_EVENT is same as VOID*.
typedef VOID *EFI_EVENT
CreateEvent() returns a pointer to an Event, so it is really a double pointer.
CreateEvent() returns EFI_INVALID_PARAMETER if Event (pointer to EFI_EVENT structure) is NULL.
But CreateEvent/Ex() do not explicitly state that the pointer to the EFI_EVENT structure
returned cannot be address 0.
Internally to the EDK II, EFI_EVENT is a structure so it must be a valid pointer. Though I
would point out that even this is an implementation choice. An implementation could treat the
pointer to the EFI_EVENT as a handle number and could internally convert a handle number to a
structure pointer to further hide details of the event structure and prevent the reuse of the
same pointer value for different events across allocates/frees. The EDK II implementation
choice to use pointers instead of handles is for the smallest/fastest implementation.
It is possible to have a pointer to a structure at address 0. However, the EDK II implementations
of the UEFI services do not allow the use of memory at 0 for normal memory allocations. I am aware
of one use case of memory at 0 for an x86 IDT structure for 16-bit code. So it is not possible
for the EDK II implementation of an UEFI service that returns pointers to structures to return a
pointer value of 0. In fact, there are guard page features in EDK II that check if there is any
access to the first page of memory in the address range 0x0..0xFFF. So the real restriction EDK II
imposes is to never allocate a data structure in the first page of memory (0x0..0xFFF).
Given it would be possible to implement many UEFI services using handle numbers instead of
pointers. I would recommend those implementations do not use a handle value of 0. And instead
start at a handle value of at least 1.
Best regards,
Mike
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Dionna Glaze via groups.io
> Sent: Monday, October 3, 2022 10:16 AM
> To: devel@edk2.groups.io; ayushdevel1325@gmail.com
> Subject: Re: [edk2-devel] Can NULL pointer be a valid event?
>
> CreateEvent returns an EFI_STATUS. It expects the OUT parameter, a
> pointer to an EFI_EVENT, to be non-NULL. A null pointer results in
> EFI_INVALID_PARAMETER. If the CreateEvent is successful, then `event`
> points to the newly created event. It's the caller's responsibility to
> pass a pointer to valid writable memory.
>
> On Mon, Oct 3, 2022 at 8:08 AM Ayush Singh <ayushdevel1325@gmail.com> wrote:
> >
> > Hello everyone,
> >
> > I wanted to ask if a NULL pointer can be returned as a valid event from `EFI_BOOT_SERVICES.CreateEvent()` or
> `EFI_BOOT_SERVICES.CreateEventEx()`? Or does the specification state that a valid event pointer has to be non-NULL?
> >
> > Yours Sincerely,
> > Ayush Singh
> >
>
>
>
> --
> -Dionna Glaze, PhD (she/her)
>
>
>
>
prev parent reply other threads:[~2022-10-03 18:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-03 15:07 Can NULL pointer be a valid event? Ayush Singh
2022-10-03 17:16 ` [edk2-devel] " Dionna Glaze
2022-10-03 17:54 ` Michael D Kinney [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CO1PR11MB4929774B24E1A8FE2DBEBA50D25B9@CO1PR11MB4929.namprd11.prod.outlook.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox