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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d8fbee2d-305a-9fc0-356e-b8d4cbd59dbd@maya.org>
Date:   Mon, 4 Jun 2018 10:50:07 +0200
From:   Andreas Hartmann <andihartmann@...enet.de>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: Spectre mitigation doesn't seem to work at all?!

Hello Peter,

thanks for your answer! I appreciate it!

On 06/04/2018 at 10:15 AM Peter Zijlstra wrote:
> On Fri, Jun 01, 2018 at 02:19:38PM +0200, Andreas Hartmann wrote:
> 
>> 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.
> 
>> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED
>> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED
>> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED
> 
>                               ^^^^^^^^                         ^^^^^^^^
> 
> The POC is a v1 on itself. V1 needs to be fixed for every individual
> executable (worse, for every individual location in the code, and we're
> still finding them). The kernel mitigation status for v1 only indicates
> the kernel itself has mitigations (for some locations).
> 
> The POC is meant to test effectiveness of these mitigations, either the
> original LFENCE or the dependent instruction thing, but you have to
> enable one or the other.

Ok, this means every program running on the machine has to care itself
to be spectre v1 - safe.

A malicious program most probably won't care about that. Therefore, my
next question is: which memory regions can be exploited by a malicious
program? The complete physical memory or only the memory provided to the
malicious program? Should be the latter if this approach should have any
impact.


Thanks,
Andreas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ