[PATCH v4 0/2] ACPI: sysfs: Expose BDAT data region

[Jamie Nguyen <jamien@nvidia.com>]

The BIOS Data ACPI Table (BDAT) points to a firmware data structure that
carries memory training results and other boot-time data. Patch 2 exposes
that data as /sys/firmware/acpi/tables/data/BDAT, like the existing BERT
and CCEL data files.

Patch 1 fixes a leak in the existing data file code, where data_attr is
not freed if sysfs_create_bin_file() fails. It moves the file creation and
the cleanup into acpi_table_data_init(), and patch 2 builds on that.

Changes in v4:
- Patch 2: before mapping the BDATHEAD header, reject an address where
  the header would wrap around the end of the address space, as
  acpi_data_show() already does for the data region. Found by Sashiko
  on v3 [3].

Changes in v3:
- Rebased onto v7.4-rc1, which includes the two fixes posted during the
  v2 review [1][2]. No code changes.
- Dropped the "Assisted-by:" tag as per latest guidelines, though an
  LLM was used to write, review, and test this series.

Changes in v2:
- New patch 1, fixing the data_attr leak for BERT and CCEL as well.
- Patch 2: the BDAT callback only checks the table and sets the address
  and size of the data, and returns -ENOMEM if mapping the header fails.

v3: https://lore.kernel.org/r/20261109180945.2438349-1-jamien@nvidia.com
v2: https://lore.kernel.org/r/20261012230632.3574987-1-jamien@nvidia.com
v1: https://lore.kernel.org/r/20261009232955.866131-1-jamien@nvidia.com

[1]: https://lore.kernel.org/r/20261013180728.957618-1-jamien@nvidia.com
[2]: https://lore.kernel.org/r/20261013193900.1258808-1-jamien@nvidia.com
[3]: https://sashiko.dev/#/patchset/20261109180945.2438349-1-jamien%40nvidia.com

Tested on an arm64 server (64K pages), with v2:

- The file matches a /dev/mem dump of the data region taken in the same
  boot, byte for byte, and decodes with valid CRCs.
- With lockdown=integrity, /dev/mem is refused and the file still reads.
- Malformed BDAT tables loaded via initrd table upgrade (test-only change
  adding BDAT to table_sigs[]) are rejected without creating a file: no
  "BDATHEAD" signature, size below the header, non-memory address space,
  zero address, and a table shorter than struct acpi_table_bdat.
- With a test-only change that makes sysfs_create_bin_file() fail with
  -EEXIST for one BDAT table, kmemleak reports its data_attr as leaked
  without patch 1, and the data_attr is freed with patch 1 applied.

Tested in QEMU (x86_64), with the same test-only change:

- BDAT tables with address 0xffffffffffffffff or 0xffffffffffffffe0
  are rejected without creating a file. With v3, the first of them
  faults in memcpy_fromio() at boot.
- A BDAT table pointing at a valid BDATHEAD structure still gets a
  data file with the expected contents.

Jamie Nguyen (2):
  ACPI: sysfs: Fix data_attr leak when creating a data file fails
  ACPI: sysfs: Expose BDAT data region

 Documentation/ABI/testing/sysfs-firmware-acpi | 12 +++
 drivers/acpi/sysfs.c                          | 74 ++++++++++++++++---
 2 files changed, 76 insertions(+), 10 deletions(-)


base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
-- 
2.43.0