linux-kernel - Re: [kernel-hardening] Re: [PATCH v2] cpu: do not leak vulnerabilities to unprivileged users

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, 26 Jan 2018 12:23:15 -0500
From:   Boris Lukashev <blukashev@...pervictus.com>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        kernel-hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: [kernel-hardening] Re: [PATCH v2] cpu: do not leak
 vulnerabilities to unprivileged users

This sort of seems like painting a plate carrier onto a tshirt.
Attackers will know, one way or another, as we have illegitimate and
legitimate vectors for gaining information. Good ecosystem inhabitants
however will be in the dark because this proposes to obfuscate their
legitimate interfaces used to determine execution context.
This might be a better option for namespaces - run an NS with
"hardware spectre mitigation masking" when the consumers in it can
handle that, but leave the rest of the userspace only as broken as it
was before. Without additional protections, bad guys can still glean
the info via leaks and functional testing, but it should provide a
small hurdle without sacrificing JIT ops in the primary NS.

-Boris

On Fri, Jan 26, 2018 at 11:43 AM, Alan Cox <gnomes@...rguk.ukuu.org.uk> wrote:
> On Fri, 26 Jan 2018 13:31:58 +0100
> "Jason A. Donenfeld" <Jason@...c4.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
>
> As I replied to you last time you posted this
>
> a) The info is already trivially accessible via /proc/cpuinfo or by
> measurement to an attacker
> b) Some JIT and other environments need to know
>
> Alan

-- 
Boris Lukashev
Systems Architect
Semper Victus