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]
Message-ID: <alpine.DEB.2.21.1806042318570.1583@nanos.tec.linutronix.de>
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




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ