From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: linux-efi <linux-efi@vger.kernel.org>,
Graeme Gregory <graeme.gregory@linaro.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Leif Lindholm <leif.lindholm@linaro.org>,
Al Stone <astone@redhat.com>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Peter Jones <pjones@redhat.com>,
"Hsiung, Harry L" <harry.l.hsiung@intel.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Len Brown <lenb@kernel.org>
Subject: Re: [PATCH] acpi: bgrt: parse BGRT to obtain BMP address before it gets clobbered
Date: Tue, 22 Jan 2019 19:07:30 +0100 [thread overview]
Message-ID: <CAKv+Gu9-tDRbmt+T3or9pMs78-pU-9BpKorhB60N_=Bxo78A1g@mail.gmail.com> (raw)
In-Reply-To: <20190122173222.GB11720@e107981-ln.cambridge.arm.com>
On Tue, 22 Jan 2019 at 18:32, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>
> On Tue, Jan 22, 2019 at 04:06:16PM +0100, Ard Biesheuvel wrote:
> > The bitmap left in the framebuffer by the firmware is described by an
> > ACPI table called "BGRT", which describes the size, pixel format and
> > the address of a BMP image in memory. While the BGRT ACPI table is
> > guaranteed to reside in a "ACPI reclaim" memory region, which is
> > never touched by Linux. The BMP image, however, typically resides
> > in EFI Boot Services Memory, which may have been overwritten by the
> > time the BGRT discovery routine runs.
> >
> > So instead, drop the handling from the ACPI init code, and call the
> > BGRT parsing code immediately after going over the EFI configuration
> > table array, at which time no memory has been touched yet except for
> > the .data/.bss regions covered by the static kernel image.
> >
> > Unfortunately, this involves a non-trivial amount of ACPI entry
> > point and root table parsing, but we cannot rely on the normal
> > ACPI infrastructure yet this early in the boot.
> >
> > Also note that we cannot take the 'acpi_disabled' global variable
> > into account, since it may not have assumed the correct value yet
> > (on arm64, the default value is '1' which is overridden to '0' if
> > no DT description has been made available by the firmware)
> >
> > Cc: Peter Jones <pjones@redhat.com>
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Technically this is a fix, right ?
>
I would argue that it is a hack to work around a deficiency in the
ACPI spec, i.e., that the BGRT table but not the image are passed in
ACPI reclaim memory.
> > ---
> > arch/arm64/kernel/acpi.c | 2 -
> > arch/x86/kernel/acpi/boot.c | 2 -
> > drivers/acpi/bgrt.c | 6 --
> > drivers/firmware/efi/efi-bgrt.c | 80 ++++++++++++++++++--
> > drivers/firmware/efi/efi.c | 13 ++++
> > include/linux/efi-bgrt.h | 4 +-
> > 6 files changed, 89 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > index 44e3c351e1ea..7429a811f76d 100644
> > --- a/arch/arm64/kernel/acpi.c
> > +++ b/arch/arm64/kernel/acpi.c
> > @@ -230,8 +230,6 @@ void __init acpi_boot_table_init(void)
> > early_init_dt_scan_chosen_stdout();
> > } else {
> > acpi_parse_spcr(earlycon_acpi_spcr_enable, true);
> > - if (IS_ENABLED(CONFIG_ACPI_BGRT))
> > - acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
> > }
> > }
> >
> > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> > index 2624de16cd7a..2d3535b62752 100644
> > --- a/arch/x86/kernel/acpi/boot.c
> > +++ b/arch/x86/kernel/acpi/boot.c
> > @@ -1633,8 +1633,6 @@ int __init acpi_boot_init(void)
> > acpi_process_madt();
> >
> > acpi_table_parse(ACPI_SIG_HPET, acpi_parse_hpet);
> > - if (IS_ENABLED(CONFIG_ACPI_BGRT))
> > - acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
> >
> > if (!acpi_noirq)
> > x86_init.pci.init = pci_acpi_init;
> > diff --git a/drivers/acpi/bgrt.c b/drivers/acpi/bgrt.c
> > index 75af78361ce5..048413e06898 100644
> > --- a/drivers/acpi/bgrt.c
> > +++ b/drivers/acpi/bgrt.c
> > @@ -81,12 +81,6 @@ static const struct attribute_group bgrt_attribute_group = {
> > .bin_attrs = bgrt_bin_attributes,
> > };
> >
> > -int __init acpi_parse_bgrt(struct acpi_table_header *table)
> > -{
> > - efi_bgrt_init(table);
> > - return 0;
> > -}
> > -
> > static int __init bgrt_init(void)
> > {
> > int ret;
> > diff --git a/drivers/firmware/efi/efi-bgrt.c b/drivers/firmware/efi/efi-bgrt.c
> > index b22ccfb0c991..8bd9b96942d2 100644
> > --- a/drivers/firmware/efi/efi-bgrt.c
> > +++ b/drivers/firmware/efi/efi-bgrt.c
> > @@ -27,24 +27,92 @@ struct bmp_header {
> > u32 size;
> > } __packed;
> >
> > -void __init efi_bgrt_init(struct acpi_table_header *table)
> > +void __init efi_bgrt_init(unsigned long rsdp_phys)
> > {
> > void *image;
> > struct bmp_header bmp_header;
> > struct acpi_table_bgrt *bgrt = &bgrt_tab;
> > + struct acpi_table_bgrt *table = NULL;
> > + struct acpi_table_rsdp *rsdp;
> > + struct acpi_table_header *hdr;
> > + u64 xsdt_phys;
> > + u32 rsdt_phys;
> > + unsigned int len;
> >
> > - if (acpi_disabled)
> > + if (!efi_enabled(EFI_MEMMAP))
> > return;
> >
> > - if (!efi_enabled(EFI_MEMMAP))
> > + /* map the root pointer table to find the xsdt/rsdt values */
> > + rsdp = early_memremap(rsdp_phys, sizeof(*rsdp));
> > + if (rsdp && ACPI_VALIDATE_RSDP_SIG(rsdp->signature)) {
> > + xsdt_phys = rsdp->xsdt_physical_address;
> > + rsdt_phys = rsdp->rsdt_physical_address;
> > + } else {
> > + WARN_ON(1);
>
> You may need to unmap rsdp.
>
Indeed.
> > + return;
> > + }
> > + early_memunmap(rsdp, sizeof(*rsdp));
> > +
> > + /* obtain the length of whichever table we will be using */
> > + hdr = early_memremap(xsdt_phys ?: rsdt_phys, sizeof(*hdr));
> > + if (WARN_ON(!hdr))
> > + return;
> > + len = hdr->length;
> > + early_memunmap(hdr, sizeof(*hdr));
> > +
> > + if (xsdt_phys) {
> > + struct acpi_table_xsdt *xsdt = early_memremap(xsdt_phys, len);
> > + int i;
> > +
> > + if (WARN_ON(!xsdt))
> > + return;
> > +
> > + for (i = 0; i < (len - sizeof(*hdr)) / sizeof(u64); i++) {
> > + table = early_memremap(xsdt->table_offset_entry[i],
> > + sizeof(*table));
> > + if (WARN_ON(!table))
> > + break;
> > +
> > + if (ACPI_COMPARE_NAME(table->header.signature,
> > + ACPI_SIG_BGRT))
> > + break;
> > + early_memunmap(table, sizeof(*table));
> > + table = NULL;
> > + }
> > + early_memunmap(xsdt, len);
> > + } else if (rsdt_phys) {
> > + struct acpi_table_rsdt *rsdt = early_memremap(rsdt_phys, len);
> > + int i;
> > +
> > + if (WARN_ON(!rsdt))
> > + return;
> > +
> > + for (i = 0; i < (len - sizeof(*hdr)) / sizeof(u32); i++) {
> > + table = early_memremap(rsdt->table_offset_entry[i],
> > + sizeof(*table));
> > + if (WARN_ON(!table))
> > + break;
> > +
> > + if (ACPI_COMPARE_NAME(table->header.signature,
> > + ACPI_SIG_BGRT))
> > + break;
> > + early_memunmap(table, sizeof(*table));
> > + table = NULL;
> > + }
> > + early_memunmap(rsdt, len);
> > + }
> > +
> > + if (!table)
> > return;
> >
> > - if (table->length < sizeof(bgrt_tab)) {
> > + if (table->header.length < sizeof(bgrt_tab)) {
> > pr_notice("Ignoring BGRT: invalid length %u (expected %zu)\n",
> > - table->length, sizeof(bgrt_tab));
> > + table->header.length, sizeof(bgrt_tab));
> > return;
>
> Likewise for the table pointer.
>
Yep.
> > }
> > - *bgrt = *(struct acpi_table_bgrt *)table;
> > + *bgrt = *table;
> > + early_memunmap(table, sizeof(*table));
> > +
> > if (bgrt->version != 1) {
> > pr_notice("Ignoring BGRT: invalid version %u (expected 1)\n",
> > bgrt->version);
>
> Side note (not related to this patch):
>
> I do not understand this check:
>
> if (bgrt->status & 0xfe) {
> pr_notice("Ignoring BGRT: reserved status bits are non-zero %u\n",
> bgrt->status);
> goto out;
> }
>
> Should not we check against 0xf8 (reserved bits are [7:3]) ? And what
> about status[0] (valid), should we check that as well ?
>
I will let Peter take that question ...
Thanks,
Ard.
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index 4c46ff6f2242..e5ef5c0eacc1 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -20,6 +20,7 @@
> > #include <linux/init.h>
> > #include <linux/device.h>
> > #include <linux/efi.h>
> > +#include <linux/efi-bgrt.h>
> > #include <linux/of.h>
> > #include <linux/of_fdt.h>
> > #include <linux/io.h>
> > @@ -592,6 +593,18 @@ int __init efi_config_parse_tables(void *config_tables, int count, int sz,
> >
> > early_memunmap(tbl, sizeof(*tbl));
> > }
> > +
> > + /*
> > + * We need to parse the BGRT table (which is an ACPI table not a UEFI
> > + * configuration table) by hand and figure out where the bitmap it
> > + * describes lives in memory so we can reserve it early on. Otherwise,
> > + * it may be clobbered by the time we get to it during the ordinary ACPI
> > + * table init sequence.
> > + */
> > + if (IS_ENABLED(CONFIG_ACPI_BGRT) &&
> > + efi.acpi20 != EFI_INVALID_TABLE_ADDR)
> > + efi_bgrt_init(efi.acpi20);
> > +
> > return 0;
> > }
> >
> > diff --git a/include/linux/efi-bgrt.h b/include/linux/efi-bgrt.h
> > index e6cd51005633..528ea62d99ec 100644
> > --- a/include/linux/efi-bgrt.h
> > +++ b/include/linux/efi-bgrt.h
> > @@ -6,7 +6,7 @@
> >
> > #ifdef CONFIG_ACPI_BGRT
> >
> > -void efi_bgrt_init(struct acpi_table_header *table);
> > +void efi_bgrt_init(unsigned long rsdp_phys);
> > int __init acpi_parse_bgrt(struct acpi_table_header *table);
> >
> > /* The BGRT data itself; only valid if bgrt_image != NULL. */
> > @@ -15,7 +15,7 @@ extern struct acpi_table_bgrt bgrt_tab;
> >
> > #else /* !CONFIG_ACPI_BGRT */
> >
> > -static inline void efi_bgrt_init(struct acpi_table_header *table) {}
> > +static inline void efi_bgrt_init(unsigned long rsdp_phys) {}
> > static inline int __init acpi_parse_bgrt(struct acpi_table_header *table)
> > {
> > return 0;
> > --
> > 2.20.1
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-01-22 18:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-22 15:06 [PATCH] acpi: bgrt: parse BGRT to obtain BMP address before it gets clobbered Ard Biesheuvel
2019-01-22 17:32 ` Lorenzo Pieralisi
2019-01-22 18:07 ` Ard Biesheuvel [this message]
2019-01-22 18:56 ` Lorenzo Pieralisi
2019-01-29 15:34 ` Peter Jones
2019-01-23 5:31 ` Dave Young
2019-01-23 9:44 ` Ard Biesheuvel
2019-01-29 16:11 ` Peter Jones
2019-02-09 13:41 ` Ard Biesheuvel
2019-01-29 14:36 ` Ard Biesheuvel
2019-01-29 15:09 ` Rafael J. Wysocki
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-all 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='CAKv+Gu9-tDRbmt+T3or9pMs78-pU-9BpKorhB60N_=Bxo78A1g@mail.gmail.com' \
--to=ard.biesheuvel@linaro.org \
--cc=astone@redhat.com \
--cc=graeme.gregory@linaro.org \
--cc=harry.l.hsiung@intel.com \
--cc=leif.lindholm@linaro.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=pjones@redhat.com \
--cc=rjw@rjwysocki.net \
/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;
as well as URLs for NNTP newsgroup(s).