[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL9bgJ942ekzyCrposr-xPeTNyh==d2JMO5LvvwuSOKQ38BgBw@mail.gmail.com>
Date: Sat, 6 Jan 2018 22:04:26 -0700
From: Kiernan Hager <kah.listaddress@...il.com>
To: linux-kernel@...r.kernel.org
Subject: Fwd: Avoid speculative indirect calls in kernel
On Thu, Jan 4, 2018 at 5:54 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Thu, 4 Jan 2018, Jon Masters wrote:
>> P.S. I've an internal document where I've been tracking "nice to haves"
>> for later, and one of them is whether it makes sense to tag binaries as
>> "trusted" (e.g. extended attribute, label, whatever). It was something I
>> wanted to bring up at some point as potentially worth considering.
>
> Scratch that. There is no such thing as a trusted binary.
>
I disagree. When there are patches that slow execution down up to 30%,
I want to be able to mark a binary as "trusted" so that I can run it
without those patches if it is important. This is a boon to
configurability and helps lessen the significant performance impact of
these patches. Besides, anything run as root can already not only
read, but also write kernel memory and other processes' memory, so
it's not like this particular ability for processes trusted by the
user is anything new. This flag should probably only be settable by
root though, for obvious reasons.
Powered by blists - more mailing lists