On Wednesday 2020-04-01 23:55, Kaneda, Erik wrote: > >I've been reading the ACPI spec and there's nothing stated about what the >initial state of the lock should be... This patch is assuming that the lock should >be free when the FACS is being initialized and I don't think this is a safe >assumption to make. > >What if this is a legitimate acquisition by an SMI handler very early in OS boot? Before the OS has initialized ACPI (which, to me, is best recognized by what action the power button will cause - either instant-off or ACPI event), I would imagine that there are no SMI handlers that try to make use of ACPI features like the FACS lock. Furthermore, if the OS has taken the FACS lock and an SMI happens, what would the SMI do if it cannot obtain the lock? It certainly can't busywait for the OS, because that's interrupted.. >> > When the firmware ROM supplies a FACS table with garbage, and the >> > firmware code does not clear the global_lock field before booting to a >> > loader/OS, the garbage bytes in that field (like 0xffffffff) can >> > indicate that the lock is taken when it is not, thereby preventing >> > obtaining said lock even though it is otherwise perfectly usable if >> > the field were not prepopulated with garbage. > >How do we know that the lock is taken when it is not? We don't. ACPI does not make itself look good in this instance I am afraid.
