linux-kernel - Re: [PATCH 0/2] PCI/AER: Consistently use

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]

Date:   Tue, 20 Nov 2018 21:46:13 +0000
From:   <Alex_Gagniuc@...lteam.com>
To:     <okaya@...nel.org>, <mr.nuke.me@...il.com>, <keith.busch@...el.com>
Cc:     <baicar.tyler@...il.com>, <Austin.Bolen@...l.com>,
        <Shyam.Iyer@...l.com>, <lukas@...ner.de>, <bhelgaas@...gle.com>,
        <rjw@...ysocki.net>, <lenb@...nel.org>, <ruscur@...sell.cc>,
        <sbobroff@...ux.ibm.com>, <oohall@...il.com>,
        <linux-pci@...r.kernel.org>, <linux-acpi@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns
 AER

On 11/20/2018 03:02 PM, Sinan Kaya wrote:
> On 11/20/2018 3:44 PM, Alex_Gagniuc@...lteam.com wrote:
>> I'd prefer "sure" instead of "think". "I think it breaks some system I'm
>> not telling you about" doesn't help much in figuring out how not to
>> break said system(s).:)
> 
> Sorry, I thought I mentioned why it would break but let me repeat.

Why, yes, but bets are still being placed on the systems allegedly 
suffering from this.

> The systems I have seen rely on the HEST table presence as an indicator
> to the OS that firmware first is enabled. If you go look at the _OSC bits
> on such systems, it still says OS owns the AER service.
> 
> The assumption here is that HEST table has precedence over the _OSC bits.
> That's what needs to be clarified in the UEFI forum.
> 
> If this code is to go in and ignore the HEST table presence, then firmware
> will think that it owns AER service and OS will think that it owns AER
> service too.

So this seems like exactly the scenario we were hypothesizing.

  * System boots up with FFS enabled. Everything is fine so far.
  * OSPM requests control of AER (set bit 3 in _OSC)
  * FW grants OS control of AER (set bit 3 in _OSC reply)

That's how things are designed to work.

Now, let's assume, for the sake of argument, that the firmware on those 
system's is broken, and it didn't intend to give the OS control of AER. 
OSPM checking HEST instead of _OSC is still wrong, according to the 
spec. Two wrongs don't make a right, they just don't crash.

I think the correct way is to identify those broken systems, and add 
quirks for them. Continuing to have inconsistent and over-complicated 
logic that is not spec compliant is not any better.

Alex