linux-kernel - Re: [PATCH] ACPI/PPTT: fix off-by-one error

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: <CAJZ5v0ixm4MYCxkMo0wiRP=W7TD3cwQtj0Fwb3H24yY+MGoLUQ@mail.gmail.com>
Date: Wed, 7 May 2025 14:35:25 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Sudeep Holla <sudeep.holla@....com>
Cc: "Heyne, Maximilian" <mheyne@...zon.de>, "stable@...r.kernel.org" <stable@...r.kernel.org>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>, Ard Biesheuvel <ardb@...nel.org>, 
	Jeremy Linton <jeremy.linton@....com>, Catalin Marinas <catalin.marinas@....com>, 
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ACPI/PPTT: fix off-by-one error

On Wed, May 7, 2025 at 2:31 PM Sudeep Holla <sudeep.holla@....com> wrote:
>
> On Wed, May 07, 2025 at 11:56:48AM +0000, Heyne, Maximilian wrote:
> > On Wed, May 07, 2025 at 12:52:18PM +0100, Sudeep Holla wrote:
> > >
> > > Just to understand, this node is absolutely processor node with no
> > > private resources ? I find it hard to trust this as most of the CPUs
> > > do have L1 I&D caches. If they were present the table can't abruptly end
> > > like this.
> >
> > Yes looks like it. In our case the ACPI subtable has length 0x14 which is
> > exactly sizeof(acpi_pptt_processor).
> >
>
> OK, this seem like it is emulated platform with no private resources as
> it is specified in the other similar patch clearly(QEMU/VM). So this
> doesn't match real platforms. Your PPTT is wrong if it is real hardware
> platform as you must have private resources.
>
> Anyways if we allow emulation to present CPUs without private resources
> we may have to consider allowing this as the computed pointer will match
> the table end.
>
> Rafael,
>
> If it is OK for QEMU to present cacheless CPUs, then we need to allow
> this logic. What do you think ?

I don't see why QEMU would be disallowed to do so.