Messages in this thread | | | Date | Thu, 13 Dec 2018 12:07:28 +0000 | From | Dave Martin <> | Subject | Re: [PATCH 0/6] add system vulnerability sysfs entries |
| |
On Thu, Dec 06, 2018 at 05:44:02PM -0600, Jeremy Linton wrote: > Part of this series was originally by Mian Yousaf Kaukab. > > Arm64 machines should be displaying a human readable > vulnerability status to speculative execution attacks in > /sys/devices/system/cpu/vulnerabilities
Is there any agreement on the strings that will be returned in there?
A quick search didn't find anything obvious upstream. There is documentation proposed in [1], but I don't know what happened to it and it doesn't define the mitigation strings at all. (I didn't follow the discussion, so there is likely background here I'm not aware of.)
If the mitigation strings are meaningful at all, they really ought to be documented somewhere since this is ABI.
> This series enables that behavior by providing the expected > functions. Those functions expose the cpu errata and feature > states, as well as whether firmware is responding appropriately > to display the overall machine status. This means that in a > heterogeneous machine we will only claim the machine is mitigated > or safe if we are confident all booted cores are safe or > mitigated. Otherwise, we will display unknown or unsafe > depending on how much of the machine configuration can > be assured.
Can the vulnerability status change once we enter userspace?
I see no locking or other concurrency protections, and various global variables that could be __ro_after_init if nothing will change them after boot.
If they can change after boot, userspace has no way to be notified,
(I haven't grokked the patches fully, so the answer to this question may be reasonably straightforward...)
Cheers ---Dave
[1] https://lkml.org/lkml/2018/1/8/145
| |