linux-kernel - Re: [PATCH v2 1/2] ACPI: PRM: Add PRM handler direct call support

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: <CAMj1kXF534YBft=a9X=RwBthEuPb4j7usQ+F-j2PHCjFhmeZxg@mail.gmail.com>
Date: Tue, 2 Jul 2024 16:54:17 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: John Allen <john.allen@....com>, linux-efi <linux-efi@...r.kernel.org>, rafael@...nel.org, 
	lenb@...nel.org, yazen.ghannam@....com, linux-acpi@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-edac@...r.kernel.org
Subject: Re: [PATCH v2 1/2] ACPI: PRM: Add PRM handler direct call support

On Thu, 27 Jun 2024 at 10:08, Borislav Petkov <bp@...en8.de> wrote:
>
> On Mon, May 06, 2024 at 05:47:20PM +0000, John Allen wrote:
> > Platform Runtime Mechanism (PRM) handlers can be invoked from either the
> > AML interpreter or directly by an OS driver. Implement the direct call
> > method.
> >
> > Export the symbol as this will be used by modules such as the AMD
> > Address Translation Library and likely others in the future.
> >
> > Signed-off-by: John Allen <john.allen@....com>
> > Reviewed-by: Yazen Ghannam <yazen.ghannam@....com>
> > ---
> > v2:
> >   - Align statements setting fields in context buffer on '='
> > ---
> >  drivers/acpi/prmt.c  | 24 ++++++++++++++++++++++++
> >  include/linux/prmt.h |  5 +++++
> >  2 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/acpi/prmt.c b/drivers/acpi/prmt.c
> > index c78453c74ef5..1cfaa5957ac4 100644
> > --- a/drivers/acpi/prmt.c
> > +++ b/drivers/acpi/prmt.c
> > @@ -214,6 +214,30 @@ static struct prm_handler_info *find_prm_handler(const guid_t *guid)
> >  #define UPDATE_LOCK_ALREADY_HELD     4
> >  #define UPDATE_UNLOCK_WITHOUT_LOCK   5
> >
> > +int acpi_call_prm_handler(guid_t handler_guid, void *param_buffer)
> > +{
> > +     struct prm_handler_info *handler = find_prm_handler(&handler_guid);
> > +     struct prm_module_info *module = find_prm_module(&handler_guid);
> > +     struct prm_context_buffer context;
> > +     efi_status_t status;
> > +
> > +     if (!module || !handler)
> > +             return -ENODEV;
> > +
> > +     memset(&context, 0, sizeof(context));
> > +     ACPI_COPY_NAMESEG(context.signature, "PRMC");
> > +     context.identifier         = handler->guid;
> > +     context.static_data_buffer = handler->static_data_buffer_addr;
> > +     context.mmio_ranges        = module->mmio_info;
> > +
> > +     status = efi_call_acpi_prm_handler(handler->handler_addr,
> > +                                        (u64)param_buffer,
> > +                                        &context);
> > +
> > +     return efi_status_to_err(status);
> > +}
>
> + linux-efi as Rafael wanted to make sure the environment is created properly
> for the EFI runtime services call...
>

This looks fine to me.

Reviewed-by: Ard Biesheuvel <ardb@...nel.org>