public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lpieralisi@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Hanjun Guo <guohanjun@huawei.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Marc Zyngier <maz@kernel.org>,
	Zheng Zengkai <zhengzengkai@huawei.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH] ACPI: GTDT: Relax sanity checking on Platform Timers array count
Date: Thu, 30 Jan 2025 18:37:00 +0100	[thread overview]
Message-ID: <Z5u4vCwVCIhiE72I@lpieralisi> (raw)
In-Reply-To: <Z5lBMBY7XoFJmpGM@linux.dev>

On Tue, Jan 28, 2025 at 12:42:24PM -0800, Oliver Upton wrote:
> Hi Lorenzo,
> 
> On Tue, Jan 28, 2025 at 11:50:55AM +0100, Lorenzo Pieralisi wrote:
> > > @@ -188,13 +188,17 @@ int __init acpi_gtdt_init(struct acpi_table_header *table,
> > >  		cnt++;
> > >  
> > >  	if (cnt != gtdt->platform_timer_count) {
> > > +		cnt = min(cnt, gtdt->platform_timer_count);
> > 
> > Thank you for reporting this.
> > 
> > There is something I need to understand.
> > 
> > What's wrong cnt (because platform_timer_valid() fails for some
> > reason on some entries whereas before the commit we
> > are fixing was applied we *were* parsing those entries) or
> > gtdt->platform_timer_count ?
> > 
> > I *guess* the issue is the following:
> > 
> > gtdt->platform_timer_count reports the number of GT blocks in the
> > GTDT not including Arm generic watchdogs, whereas cnt counts both
> > structure types (and that's what gtdt->platform_timer_count should
> > report too if it was correct).
> 
> I've seen two different issues so far:
> 
>  - In one case, the offset of the platform timer array is entirely
>    beyond the GTDT

And we were parsing it before the commit you are fixing was applied
because we weren't validating the first entry ?

That's how the loop was working before:

#define for_each_platform_timer(_g)
	for (_g = acpi_gtdt_desc.platform_timer; _g;
		_g = next_platform_timer(_g))

We were parsing the first entry and now we don't anymore (rightly so),
even with this fix applied, correct ?

>  - In another, the GTDT has a timer array of length 2, but only the
>    first structure falls within the length of the overall GTDT

Right.

> Since cnt is the result of doing a bounds-checked walk of the platform
> timer array, both of these issues cause the sanity check to fail.

Yep.

> > >  	if (platform_timer_count)
> > > -		*platform_timer_count = gtdt->platform_timer_count;
> > > +		*platform_timer_count = cnt;
> > 
> > I think this should be fine as things stand (but see above).
> > 
> > It is used in:
> > 
> > gtdt_sbsa_gwdt_init() - just to check if there are platform timers entries
> > 
> > arch_timer_mem_acpi_init() - to create a temporary array to init arch mem timer
> > 			     entries (the array is oversized because it
> > 			     includes watchdog entries in the count)
> > 
> > In both cases taking the
> > 
> > min(cnt, gtdt->platform_timer_count);
> > 
> > should work AFAICS
> 
> It was probably worth noting in the changelog that I did this to
> gracefully handle the reverse of this issue where we could dereference
> platform timer entries that are within the bounds of the GTDT but exceed
> gtdt->platform_timer_count.

Yes, that's strike three, where platform_timer_count is borked,
I understand you have not hit this one though but it seems
right to fix it the way you did.

I am just trying to understand given that we are sending the fix to
stable whether this fix can affect other broken GTDTs (or better, whether
other borked FW can affect this change) but I hope not, it should not.

> > (hard to grok though, we - as in ACPI maintainers -
> > need to clean this up).
> 
> Heh, thought this smelled a little ripe ;-) Went for the minimal fix
> first.

I am sorry you have to deal with this, the kernel is not there to
validate the firmware but on the other hand when it doesn't that's the
outcome. Apologies.

Lorenzo

  reply	other threads:[~2025-01-30 17:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-28  0:17 [PATCH] ACPI: GTDT: Relax sanity checking on Platform Timers array count Oliver Upton
2025-01-28  8:46 ` Marc Zyngier
2025-01-28 10:50 ` Lorenzo Pieralisi
2025-01-28 20:42   ` Oliver Upton
2025-01-30 17:37     ` Lorenzo Pieralisi [this message]
2025-02-13 13:59 ` Will Deacon

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=Z5u4vCwVCIhiE72I@lpieralisi \
    --to=lpieralisi@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=guohanjun@huawei.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=will@kernel.org \
    --cc=zhengzengkai@huawei.com \
    /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