linux-kernel - Re: Missing watchdog after ACPI watchdog creation failure

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: <1823310.fcPFLxI5kD@aspire.rjw.lan>
Date:   Thu, 18 Jan 2018 20:35:25 +0100
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:     Takashi Iwai <tiwai@...e.de>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        linux-kernel@...r.kernel.org
Subject: Re: Missing watchdog after ACPI watchdog creation failure

On Thursday, January 18, 2018 12:26:37 PM CET Mika Westerberg wrote:
> On Thu, Jan 18, 2018 at 12:20:32PM +0200, Mika Westerberg wrote:
> > On Wed, Jan 17, 2018 at 12:53:41PM +0100, Takashi Iwai wrote:
> > > Unfortunately we couldn't get approval yet, since it's a prototype
> > > machine.
> > 
> > In that case, I think the system itself and its ACPI tables should be
> > fixed if possible. Windows relies on that table as well so unless there
> > is something terribly wrong in how we allocate resources in Linux,
> > Windows should fail the same way. There is good reason why the WDAT
> > table is there in the first place so using iTCO to poke the hardware
> > directly might cause some other problems. Windows does not have iTCO
> > driver at all.
> > 
> > > Meanwhile, the reporter tested the patch below and confirmed to work.
> > > (It might be racy for acpi_has_watchdog() call during the probe, but
> > >  you see the idea.)
> > 
> > I would rather not to add any kinds of quirks for systems that are still
> > in development phase and the BIOS can be fixed. Basic idea is that if
> > the WDAT table is there we expect it to be correct and at least the
> > systems I'm aware of that's the case.
> > 
> > Of course if it turns out to be a problem in a real production system we
> > need to find out what the actual problem is (i.e why the resource
> > allocation fails in the first place) and fix it there.
> > 
> > That said, if Rafael says we should still add the check, I'll make a
> > patch that does it (based on yours) and send it upstream :)
> 
> However, we can still check if the WDAT is actually enabled and prevent
> creation of the device in that case. It may be that the BIOS always
> exposes the table but the device itself is disabled.

Adding quirks for systems under development that may be subject to changes is
rather pointless IMO, but of course general sanity checks that make sense
should be done (and possibly complain about inconsistencies if any).

Thanks,
Rafael