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:   Fri, 12 Jan 2018 19:01:42 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Andi Kleen <andi@...stfloor.org>, tglx@...utronix.de
Cc:     torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
        gregkh@...uxfoundation.org, arjan.van.de.ven@...el.com,
        peterz@...radead.org, Andi Kleen <ak@...ux.intel.com>,
        jeyu@...nel.org
Subject: Re: [PATCH] retpoline/module: Taint kernel for missing retpoline
 in module

On Fri, 2018-01-12 at 09:55 -0800, Andi Kleen wrote:
> From: Andi Kleen <ak@...ux.intel.com>
> 
> There's a risk that a kernel that has full retpoline mitigations
> becomes vulnerable when a module gets loaded that hasn't been
> compiled with the right compiler or the right option.
> 
> We cannot fix it, but should at least warn the user when that
> happens.
> 
> Add a flag to each module if it has been compiled with RETPOLINE
> 
> When the a module hasn't been compiled with a retpoline
> aware compiler, print a warning and set a taint flag.
> 
> For modules it is checked at compile time, however it cannot
> check assembler or other non compiled objects used in the module link.
> 
> Due to lack of better letter it uses taint option 'Z'
> 
> We only set the taint flag for incorrectly compiled modules
> now, not for the main kernel, which already has other
> report mechanisms.
> 
> Also make sure to report vulnerable for spectre if such a module
> has been loaded.

Thanks for reviving this; it got dropped partly because it has
conflicts between the tip/x86/pti tree and Linus' 4.15-rc.

The other reason for dropping it was because I think we probably want
to revisit this whole thing once we have all the mitigations in place.

It doesn't make a lot of sense to have a taint flag for a *partial*
retpoline, but not in the case that we have *no* mitigation in place.

So maybe we should drop the taint part, and just make the kernel report
that it is (partially) vulnerable to Spectre V2, just as in the
CONFIG_RETPOLINE && !RETPOLINE case?

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ