linux-kernel - Re: [PATCH 0/5] Detect hwmon and i2c bus drivers interfering with ACPI Operation Region resources

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: <200710250906.23003.bjorn.helgaas@hp.com>
Date:	Thu, 25 Oct 2007 09:06:22 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	trenn@...e.de
Cc:	linux-acpi <linux-acpi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Len Brown <lenb@...nel.org>, Andrew Morton <akpm@...l.org>,
	Jean Delvare <khali@...ux-fr.org>
Subject: Re: [PATCH 0/5] Detect hwmon and i2c bus drivers interfering with ACPI Operation Region resources

On Wednesday 24 October 2007 08:31:59 am Thomas Renninger wrote:
> In ACPI, AML can define accesses to IO ports and System Memory by
> Operation Regions. Those are not registered as done by PNPACPI using
> resource templates (and _CRS/_SRS methods).
> The IO ports and System Memory regions may get accessed by arbitrary AML
> code. When native drivers are accessing the same resources bad things
> can happen (e.g. a critical shutdown temperature of 3000 C every 2
> months or so).

> It is not really possible to register the operation regions via
> request_resource, as they often overlap with pnp or other resources
> (e.g. statically setup IO resources below 0x100).

But we really *should* reserve things used by opregions, shouldn't
we?  After all, the whole point of resource reservation is to prevent
conflicts.

If these opregion resources aren't reserved, but are only put in the
ACPI resource_list, we will only find conflicts with drivers that use
acpi_check_resource_conflict().  Any driver unmodified by your changeset
could still have a conflict, and we'd never find it.

Isn't the real problem that we have a bunch of drivers that use some of
the same resources, and if ACPI reserved all the right resources, all
those drivers would break?

I think it would be better to:

  - Make ACPI reserve resources used by opregions unless
    acpi_enforce_resources == no.

  - Change the drivers so if their request_region() fails, they
    check acpi_enforce_resources and either fail (in strict mode)
    or print the warning and continue (in lax mode).

Admittedly, this is harder for the drivers that use the shiny new
platform device stuff.

> This approach stores all Operation Region declarations (IO and System
> Memory only) at ACPI table parse time. It offers a similar functionality
> like request_region and let drivers which are known to possibly use the
> same IO ports and Memory which are also often used by ACPI (hwmon and
> i2c) check for ACPI interference.
> 
> A boot parameter acpi_enforce_resources=strict/lax/no is provided, which
> is default set to lax:
>   - strict: let conflicting drivers fail to load with an error message
>   - lax:    let conflicting driver work normal with a warning message
>   - no:     no functional change at all
> Depending on the feedback and the kind of interferences we see, this
> should be set to strict at later time.
> 
> Goal of this patch set is:
>   - Identify ACPI interferences in bug reports (very hard to reproduce
>     and to identify)
>   - Find BIOSes for that an ACPI driver should exist for specific HW
>     instead of a native one.
>   - stability in general
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/