> I'm not taking that stuff without proper documentation.
Ok can you just revert Jiri's code then instead?
This is after all mainly an emergency fixup patch for that disaster,
which got fast tracked without any of these considerations
which now suddenly appear. Requiring new documentation for old
On 11/19/2018 04:30 PM, Thomas Gleixner wrote:
>
> What has spectre_v2=on to do with spectre_v2_app2app=on?
>
> Exactly nothing. You can have 'on' for both. The only side effect of
> spectre_v2=on is that it also forces spectre_v2_app2app to 'on'
> irrespective of what eventually was added for sp
On Mon, 19 Nov 2018, Tim Chen wrote:
> On 11/19/2018 05:32 AM, Thomas Gleixner wrote:
> > On Fri, 16 Nov 2018, Tim Chen wrote:
> >> The protection mode can be specified by the spectre_v2_app2app
> >> boot parameter with the following semantics:
> >>
> >> spectre_v2_app2app=
> >>off- Turn of
On 11/19/2018 04:00 PM, Thomas Gleixner wrote:
> On Tue, 20 Nov 2018, Jiri Kosina wrote:
>
>> On Tue, 20 Nov 2018, Thomas Gleixner wrote:
>>
>>> What? IBPB makes tons of sense even without STIBP.
>>
>> On non-SMT, yes. But this patchset ties those two the other (sensible) way
>> around AFAICS ("S
On Mon, 19 Nov 2018, Andrea Arcangeli wrote:
> On Mon, Nov 19, 2018 at 01:33:08PM -0800, Dave Hansen wrote:
> > Here's the current description:
> >
> > > Setting ... STIBP ... on a logical processor prevents the predicted
> > > targets of indirect branches on any logical processor of that core
>
On 11/19/2018 05:32 AM, Thomas Gleixner wrote:
> Tim,
>
> On Fri, 16 Nov 2018, Tim Chen wrote:
>
>> Add new protection modes for Spectre v2 mitigations against
>> Spectre v2 attacks on user processes. There are three modes:
>>
>> strict mode:
>> In this mode, IBPB and STIBP are deploye
On Tue, 20 Nov 2018, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Dave Hansen wrote:
>
> > > What? IBPB makes tons of sense even without STIBP.
> >
> > I'm lost. :)
> >
> > I don't think anyone is talking about using STIBP *everywhere* that IBPB
> > is in-use.
> >
> > We're just guessing that, if
On Tue, 20 Nov 2018, Jiri Kosina wrote:
> On Tue, 20 Nov 2018, Thomas Gleixner wrote:
>
> > What? IBPB makes tons of sense even without STIBP.
>
> On non-SMT, yes. But this patchset ties those two the other (sensible) way
> around AFAICS ("STIBP iff (IBPB && SMT)").
Errm. No.
The patches disa
On Mon, 19 Nov 2018, Dave Hansen wrote:
> > What? IBPB makes tons of sense even without STIBP.
>
> I'm lost. :)
>
> I don't think anyone is talking about using STIBP *everywhere* that IBPB
> is in-use.
>
> We're just guessing that, if anybody is paranoid enough to ask for IBPB,
> *and* they hav
On Mon, Nov 19, 2018 at 03:25:41PM -0800, Dave Hansen wrote:
> On 11/19/18 3:16 PM, Andrea Arcangeli wrote:
> > So you may want to ask why it wasn't written as your "any" vs "any" email:
>
> Presumably because the authors really and truly meant what they said. I
> was not being as careful in my w
On 11/19/18 3:01 PM, Thomas Gleixner wrote:
>> Yes, it wouldn't make sense for having just one of those if a task
>> is worried about attack from user space.
>>
>> I'll document it.
> What? IBPB makes tons of sense even without STIBP.
I'm lost. :)
I don't think anyone is talking about using STIBP
On 11/19/18 3:16 PM, Andrea Arcangeli wrote:
> So you may want to ask why it wasn't written as your "any" vs "any" email:
Presumably because the authors really and truly meant what they said. I
was not being as careful in my wording as they were. :)
There is nothing in the spec that says that S
On Tue, 20 Nov 2018, Thomas Gleixner wrote:
> What? IBPB makes tons of sense even without STIBP.
On non-SMT, yes. But this patchset ties those two the other (sensible) way
around AFAICS ("STIBP iff (IBPB && SMT)").
--
Jiri Kosina
SUSE Labs
On Mon, Nov 19, 2018 at 01:33:08PM -0800, Dave Hansen wrote:
> On 11/19/18 11:32 AM, Andrea Arcangeli wrote:
> > The specs don't say if by making it immune from BTB mistraining, it
> > also could prevent to mistrain the BTB in order to attack what's
> > outside the SECCOMP jail. Probably it won't a
On Mon, 19 Nov 2018, Tim Chen wrote:
> On 11/19/2018 12:55 PM, Jiri Kosina wrote:
> > On Mon, 19 Nov 2018, Thomas Gleixner wrote:
> >
> >>
> >> So before that change IBPB was usable without STIBP, now not longer. What's
> >> the rationale?
> >>
> >> This patch changes a gazillion things at once an
On 11/19/2018 12:55 PM, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Thomas Gleixner wrote:
>
>>
>> So before that change IBPB was usable without STIBP, now not longer. What's
>> the rationale?
>>
>> This patch changes a gazillion things at once and is completely
>> unreviewable.
>
> The patchset ac
On 11/19/2018 12:21 PM, Thomas Gleixner wrote:
> On Fri, 16 Nov 2018, Tim Chen wrote:
>> +static enum spectre_v2_app2app_mitigation_cmd __init
>> +spectre_v2_parse_app2app_cmdline(enum spectre_v2_mitigation_cmd
>> v2_cmd)
>> +{
>> +enum spectre_v2_app2app_mitigation_cmd cmd;
>> +ch
On Mon, Nov 19, 2018 at 08:39:41PM +0100, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Andrea Arcangeli wrote:
>
> > Generally speaking the untrusted code that would try to use spectrev2
> > to attack the other processes is more likely to run inside SECCOMP
> > jail than outside, so if SECCOMP should
On 11/19/18 11:32 AM, Andrea Arcangeli wrote:
> The specs don't say if by making it immune from BTB mistraining, it
> also could prevent to mistrain the BTB in order to attack what's
> outside the SECCOMP jail. Probably it won't and I doubt we can rely on
> it even if some implementation could do t
On Mon, 19 Nov 2018, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Thomas Gleixner wrote:
>
> > > @@ -452,12 +542,6 @@ static void __init spectre_v2_select_mitigation(void)
> > > setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> > > pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context
On Mon, 19 Nov 2018, Thomas Gleixner wrote:
> > @@ -452,12 +542,6 @@ static void __init spectre_v2_select_mitigation(void)
> > setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> > pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context
> > switch\n");
> >
> > - /* Initialize In
On Fri, 16 Nov 2018, Tim Chen wrote:
> +static const struct {
> + const char *option;
> + enum spectre_v2_app2app_mitigation_cmd cmd;
> + bool secure;
> +} app2app_options[] = {
> + { "off",SPECTRE_V2_APP2APP_CMD_NONE, false },
> + { "lite", SPECTRE_V2_APP2APP_CM
On Fri, 16 Nov 2018, Tim Chen wrote:
> +static enum spectre_v2_app2app_mitigation_cmd __init
> + spectre_v2_parse_app2app_cmdline(enum spectre_v2_mitigation_cmd
> v2_cmd)
> +{
> + enum spectre_v2_app2app_mitigation_cmd cmd;
> + char arg[20];
> + int ret, i;
> +
> + if (v2_c
On Mon, 19 Nov 2018, Andrea Arcangeli wrote:
> Generally speaking the untrusted code that would try to use spectrev2
> to attack the other processes is more likely to run inside SECCOMP
> jail than outside, so if SECCOMP should be used as a best effort
> heuristic to decide when to enable STIBP, i
Hello everyone,
On Mon, Nov 19, 2018 at 02:49:36PM +0100, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Thomas Gleixner wrote:
>
> > > On Sat, 17 Nov 2018, Jiri Kosina wrote:
> >
> > > Subject: [PATCH] x86/speculation: enforce STIBP for SECCOMP tasks in lite
> > > mode
> > >
> > > If 'lite' mode o
On 11/19/2018 06:00 AM, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Thomas Gleixner wrote:
>
>>> Yeah. IBPB implementation used to check the dumpability of tasks during
>>> rescheduling, but that went away later.
>>>
>>> I still think that ideally that 'app2app' setting would toggle how IBPB is
>>
On Mon, 19 Nov 2018, Tim Chen wrote:
> >> +DEFINE_STATIC_KEY_FALSE(spectre_v2_app_lite);
> >> +EXPORT_SYMBOL_GPL(spectre_v2_app_lite);
> >
> > Why would this be exported? The only usage site outside of this code is in
> > tlb.c which is hardly modular.
>
> That was my initial thought too. Ingo
On 11/19/2018 07:00 AM, Thomas Gleixner wrote:
> On Fri, 16 Nov 2018, Tim Chen wrote:
>> +DEFINE_STATIC_KEY_FALSE(spectre_v2_app_lite);
>> +EXPORT_SYMBOL_GPL(spectre_v2_app_lite);
>
> Why would this be exported? The only usage site outside of this code is in
> tlb.c which is hardly modular.
That
On Fri, 16 Nov 2018, Tim Chen wrote:
> +DEFINE_STATIC_KEY_FALSE(spectre_v2_app_lite);
> +EXPORT_SYMBOL_GPL(spectre_v2_app_lite);
Why would this be exported? The only usage site outside of this code is in
tlb.c which is hardly modular.
> @@ -328,14 +411,19 @@ static bool stibp_needed(void)
>
On Mon, 19 Nov 2018, Thomas Gleixner wrote:
> > Yeah. IBPB implementation used to check the dumpability of tasks during
> > rescheduling, but that went away later.
> >
> > I still think that ideally that 'app2app' setting would toggle how IBPB is
> > being used as well, something along the line
On Mon, 19 Nov 2018, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Thomas Gleixner wrote:
>
> > > On Sat, 17 Nov 2018, Jiri Kosina wrote:
> >
> > > Subject: [PATCH] x86/speculation: enforce STIBP for SECCOMP tasks in lite
> > > mode
> > >
> > > If 'lite' mode of app2app protection from spectre_v2 i
On Mon, 19 Nov 2018, Thomas Gleixner wrote:
> > On Sat, 17 Nov 2018, Jiri Kosina wrote:
>
> > Subject: [PATCH] x86/speculation: enforce STIBP for SECCOMP tasks in lite
> > mode
> >
> > If 'lite' mode of app2app protection from spectre_v2 is selected on
> > kernel command-line, we are currently
On Sun, 18 Nov 2018, Jiri Kosina wrote:
> On Sat, 17 Nov 2018, Jiri Kosina wrote:
> Subject: [PATCH] x86/speculation: enforce STIBP for SECCOMP tasks in lite mode
>
> If 'lite' mode of app2app protection from spectre_v2 is selected on
> kernel command-line, we are currently applying STIBP protect
Tim,
On Fri, 16 Nov 2018, Tim Chen wrote:
> Add new protection modes for Spectre v2 mitigations against
> Spectre v2 attacks on user processes. There are three modes:
>
> strict mode:
> In this mode, IBPB and STIBP are deployed full
> time to protect all processes.
>
>
On Sat, 17 Nov 2018, Jiri Kosina wrote:
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > b/Documentation/admin-guide/kernel-parameters.txt
> > index 81d1d5a..9c306e3 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-par
On Fri, 16 Nov 2018, Tim Chen wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 81d1d5a..9c306e3 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
>
Add new protection modes for Spectre v2 mitigations against
Spectre v2 attacks on user processes. There are three modes:
strict mode:
In this mode, IBPB and STIBP are deployed full
time to protect all processes.
lite mode:
In this mode, IBPB and STIBP are
37 matches
Mail list logo
