linux-kernel - [PATCH 0/3] xen: ACPI processor related fixes

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-next>] [day] [month] [year] [list]

Date:   Mon, 21 Nov 2022 11:21:09 +0100
From:   Roger Pau Monne <roger.pau@...rix.com>
To:     linux-kernel@...r.kernel.org
Cc:     xen-devel@...ts.xenproject.org, jgross@...e.com,
        Roger Pau Monne <roger.pau@...rix.com>
Subject: [PATCH 0/3] xen: ACPI processor related fixes

Hello,

This series aims to fix some shortcomings with the handling of ACPI
Processors objects when running as a Xen dom0.

First two patches fix the execution of the _PDC methods for all CPUs on
the system and not just the ones available to dom0, while also making
sure that the _PDC capabilities reported to ACPI match what the
perfrmance and power drivers in Xen can handle.

Final patch fixes the Xen ACPI Processor driver to also work when used
in a PVH dom0, that has a custom build ACPI MADT table and mismatched
Processor UIDs between the MADT and the Processor objects in the dynamic
AML.

I don't really like the current implementation of the Xen ACPI Processor
driver, it IMO relies too much on data being fetched by generic kernel
code.  For one the generic fetcher functions can take CPUID data into
account in order to sanitize what's found in ACPI, but capabilities
reported to dom0 can be different from the native ones.  Also the Xen
ACPI Processor code relies on cloning the data from CPUs in order to fill
for the pCPUs > vCPUs, but this is wrong when running on heterogeneous
systems.

Last patch introduces some helpers to Xen ACPI Processor that should
allow fetching all the required data, for each ACPI Processor object on
the dynamic tables.  It might be helpful to explore disabling any
Processor object handling done by generic drivers and just fetch all the
data from the Xen Processor driver itself for every Processor object on
the namespace.  Likewise it might be better to just execute _PDC from
that same Xen ACPI Processor driver instead of polluting the generic
ACPI Processor driver.

The series should be taken as a RFC partially, due to my own doubts
about whether the current implementation is indeed the right one moving
forward.

Thanks, Roger.

Roger Pau Monne (3):
  acpi/processor: fix evaluating _PDC method when running as Xen dom0
  acpi/processor: sanitize _PDC buffer bits when running as Xen dom0
  xen/acpi: upload power and performance related data from a PVH dom0

 arch/x86/include/asm/xen/hypervisor.h |  12 ++
 arch/x86/xen/enlighten.c              |  44 +++++
 drivers/acpi/processor_pdc.c          |  19 +++
 drivers/xen/xen-acpi-processor.c      | 225 ++++++++++++++++++++++++--
 4 files changed, 284 insertions(+), 16 deletions(-)

-- 
2.37.3