[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFUG7CeFDq1rRAZRfqUc0dP=2bRH-OjPBw0-BHqiXSoJypGWGQ@mail.gmail.com>
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: 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
