linux-kernel - Re: Spectre mitigation doesn't seem to work at all?!

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:   Mon, 4 Jun 2018 23:25:14 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andreas Hartmann <andihartmann@...19freenet.de>
cc:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: Spectre mitigation doesn't seem to work at all?!

On Mon, 4 Jun 2018, Andreas Hartmann wrote:
> Sorry for a ping - but I think the behavior shown below should really be
> investigated!

There is not much to investigate ...

> > I tested the spectre mitigation of different machines and kernels with
> > https://github.com/crozone/SpectrePoC
> > 
> > You can see the results below.
> > My question: Did I miss something?

Yes.

> > My expectation was, that on base of the output of
> > /sys/devices/system/cpu/vulnerabilities/spectre_v* as shown below the
> > problem should be gone away.
> > But the results seem to tell me something other ... .

> > CPU:    AMD Ryzen 7 1700X Eight-Core Processor
> > Bios:   BIOS 4011 04/19/2018 - ibpb is listed in /proc/cpuinfo
> > Kernel: 4.14.44-1.1-default
> > cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
> > Mitigation: Full AMD retpoline, IBPB
> > cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
> > Mitigation: __user pointer sanitization

Looks correct, but irrelevant.

> > 
> >  ./spectre.out
> > Using a cache hit threshold of 80.
> > Build: RDTSCP_SUPPORTED MFENCE_SUPPORTED CLFLUSH_SUPPORTED

This is the info you missed:

> > INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED

The whole POC is sniffing on itself and it allows you to compile with
different mitigation enabled or disabled. You disabled both. So it's
expected to succeed.

It does not matter at all which mitigations the kernel has enabled because
they do not affect the user space programm attacking itself. It's just a
demonstrator of the attack technology along with options to demonstrate the
effectiveness of mitigation strategies.

Thanks,

	tglx