On 11/19/2018 07:54 PM, Sinan Kaya wrote: > On 11/19/2018 6:49 PM, Alex_Gagniuc@xxxxxxxxxxxx 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
