| Message ID | 20180125120401.30596-1-Jason@zx2c4.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, 25 Jan 2018 13:04:01 +0100 "Jason A. Donenfeld" <Jason@zx2c4.com> wrote: > While it's public information if the CPU in general has spectre/meltdown > bugs, it probably shouldn't be as globally obvious to all unprivileged > users whether or not the kernel is doing something to mitigate There are plenty of cases where it is useful for an application such as a JIT to know what level of protection it needs to be providing. For example if you look across the ecosystem (notably ARM) a lot of common slower processors are not vulnerable. For those a JIT would want to generate code without the overhead of any protections. As you observe any attacker can already trivially ascertain whether protection is on, so there is no point pretending file permissions magically stop that. In fact the information is already in cpuinfo. IMHO given it's trivially available info and useful for JITs it make sense for the data to be exposed. Alan
On Thu, Jan 25, 2018 at 2:34 PM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote: > As you observe any attacker can already trivially ascertain whether > protection is on, so there is no point pretending file permissions > magically stop that. In fact the information is already in cpuinfo. Actually the other place it leaks is in dmesg, which would need to be patched too. My understanding about cpuinfo was that it showed whether or not the processor family is generally vulnerable to it, independent of whether or not the kernel has been patched. What this patch does relates to whether or not the kernel has been patched.
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c index d99038487a0d..a3a8e008f957 100644 --- a/drivers/base/cpu.c +++ b/drivers/base/cpu.c @@ -531,9 +531,9 @@ ssize_t __weak cpu_show_spectre_v2(struct device *dev, return sprintf(buf, "Not affected\n"); } -static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL); -static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL); -static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL); +static DEVICE_ATTR(meltdown, 0400, cpu_show_meltdown, NULL); +static DEVICE_ATTR(spectre_v1, 0400, cpu_show_spectre_v1, NULL); +static DEVICE_ATTR(spectre_v2, 0400, cpu_show_spectre_v2, NULL); static struct attribute *cpu_root_vulnerabilities_attrs[] = { &dev_attr_meltdown.attr,
While it's public information if the CPU in general has spectre/meltdown bugs, it probably shouldn't be as globally obvious to all unprivileged users whether or not the kernel is doing something to mitigate those bugs. While an attacker can obviously probe and try, there frequently is a trade-off attackers make of how much probing around they're willing to do versus the certainty of an attack working, in order to reduce detection. By making it loud and clear that the kernel _is_ vulnerable, we're simply aiding the trade-off calculations attackers have to make when choosing which vectors to target. So, this patch changes the permissions to 0400 to make the attacker's job slightly less easy. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> --- drivers/base/cpu.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)