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 20:44:46 +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/19/2018 07:54 PM, Sinan Kaya wrote:
> On 11/19/2018 6:49 PM, Alex_Gagniuc@...lteam.com wrote:
>> On 11/19/2018 02:33 PM, Sinan Kaya wrote:
>>> However; table assumes governance about for which entities firmware first
>>> should be enabled. There is no cross reference to _OSC or permission
>>> negotiation like _OST.
>>
>> Well, from an OSPM perspective, is FFS something that can be enabled or
>> disabled? FFS seems to be static to OSPM, which would change the sort of
>> assumptions we can reasonably make here.
> 
> IMO, it can be enabled/disabled in BIOS. I have seen this implementation before.
> If the trigger is the presence of a statically compiled ACPI HEST table (as the
> current code does); presence of FFS would be static from OSPM perspective.
> BIOS could patch this table or hide it during boot.
> 
> If FFS were to be negotiated via _OSC as indirectly implied in this series, then
> same BIOS could patch the ACPI table to return different values for the _OSC
> return.

It is theoretically possible to have proprietary BIOS settings to 
disable FFS. The platform vendors that I've spoken to do not offer this 
option. Though even if, hypothetically, BIOS clears the FFS bit in HEST, 
it won't stop it from commandeering the CPU and doing whatever it wants.

Although, I'm not quite sure why we'd want to negotiate FFS itself. FFS 
is too big of a can of worms (goes far beyond AER error reporting), when 
what we really care about is if OS can use a specific feature or not.
>> Cool. While the UEFI Secret Society debates, can we figure out if/how
>> [patch 1/2] breaks those systems, or is it only [patch 2/2] of this
>> series that we suspect?
> 
> I went back and looked at both patches. Both of them are removing references to
> HEST table. I think both patches are impacted by this discussion.

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). :)

Alex