[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <nycvar.YFH.7.76.1809052029160.15880@cbobk.fhfr.pm>
Date: Wed, 5 Sep 2018 20:35:19 +0200 (CEST)
From: Jiri Kosina <jikos@...nel.org>
To: Andi Kleen <ak@...ux.intel.com>
cc: Tim Chen <tim.c.chen@...ux.intel.com>,
"Schaufler, Casey" <casey.schaufler@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Andrea Arcangeli <aarcange@...hat.com>,
"Woodhouse, David" <dwmw@...zon.co.uk>,
Oleg Nesterov <oleg@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can
be applied on arbitrary tasks
On Wed, 5 Sep 2018, Andi Kleen wrote:
> Please if you repost include plenty of performance numbers for multi
> threaded workloads. It's ridiculous to even discuss this without them.
Talking about ridiculous ... I find it a bit sad that Intel has let this
be unfixed for 3/4 years in linux; that doesn't really signal deep
dedication to customer safety. Have any STIBP patches been even submitted?
This is not the same situation as IBRS which was mostly ignored -- there
we have retpolines to protect the kernel, and it's debatable whether it's
exploitable on SKL at all.
Ignoring IBPB and STIBP is keeping the system plain vulnerable to
user-user attacks, and us not providing users with possibiliy to easily
mitigate, is a bit embarassing in my eyes.
Thanks,
--
Jiri Kosina
SUSE Labs
Powered by blists - more mailing lists