From: Peter Newman <peternewman@google.com>
To: Reinette Chatre <reinette.chatre@intel.com>
Cc: fenghua.yu@intel.com, bp@alien8.de, derkling@google.com,
eranian@google.com, hpa@zytor.com, james.morse@arm.com,
jannh@google.com, kpsingh@google.com,
linux-kernel@vger.kernel.org, mingo@redhat.com,
tglx@linutronix.de, x86@kernel.org
Subject: Re: [PATCH v5 1/1] x86/resctrl: Fix task CLOSID/RMID update race
Date: Mon, 19 Dec 2022 11:22:01 +0100 [thread overview]
Message-ID: <CALPaoCi8hcFzNN9O9fS9Etri_KMdU32UU1tJsfeO1OxR-i1j7g@mail.gmail.com> (raw)
In-Reply-To: <87a9df72-f15a-0cf6-566c-dd7522d40c4e@intel.com>
Hi Reinette,
On Fri, Dec 16, 2022 at 8:36 PM Reinette Chatre
<reinette.chatre@intel.com> wrote:
> On 12/16/2022 2:26 AM, Peter Newman wrote:
> > However I can make a case that it's exploitable:
> >
> > "In a memory bandwidth-metered compute host, malicious jobs could
> > exploit this race to remain in a previous CLOSID or RMID in order to
> > dodge a class-of-service downgrade imposed by an admin or steal
> > bandwidth."
> >
>
> I am not comfortable with such high level speculation. For this
> exploit to work the malicious jobs needs to control scheduler decisions
> as well as time the exploit with the admin's decision to move the target task.
I imagined if the malicious job maintained a large pool of threads in
short sleep-loops, after it sees a drop in bandwidth, it can cue the
threads to measure their memory bandwidth to see if any got past the
CLOSID change.
I don't know whether having fast, unmetered bandwidth until the next
context switch is enough of a payoff to bother with this, though. Our
workloads have too many context switches for this to be worth very much,
so I'm fine with letting others decide how important this fix is to
them.
-Peter
prev parent reply other threads:[~2022-12-19 10:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 11:44 [PATCH v5 0/1] Subject: x86/resctrl: Fix task CLOSID update race Peter Newman
2022-12-14 11:44 ` [PATCH v5 1/1] x86/resctrl: Fix task CLOSID/RMID " Peter Newman
2022-12-15 23:51 ` Reinette Chatre
2022-12-16 10:26 ` Peter Newman
2022-12-16 19:36 ` Reinette Chatre
2022-12-19 10:22 ` Peter Newman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALPaoCi8hcFzNN9O9fS9Etri_KMdU32UU1tJsfeO1OxR-i1j7g@mail.gmail.com \
--to=peternewman@google.com \
--cc=bp@alien8.de \
--cc=derkling@google.com \
--cc=eranian@google.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=jannh@google.com \
--cc=kpsingh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=reinette.chatre@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).