On 11/20/2018 11:27 PM, Jiri Kosina wrote:
On Mon, 19 Nov 2018, Arjan van de Ven wrote:
In the documentation, AMD officially recommends against this by default,
and I can speak for Intel that our position is that as well: this really
must not be on by default.
Thanks for pointing to the AMD
On 11/20/2018 11:27 PM, Jiri Kosina wrote:
On Mon, 19 Nov 2018, Arjan van de Ven wrote:
In the documentation, AMD officially recommends against this by default,
and I can speak for Intel that our position is that as well: this really
must not be on by default.
Thanks for pointing to the AMD
On Mon, 19 Nov 2018, Arjan van de Ven wrote:
> In the documentation, AMD officially recommends against this by default,
> and I can speak for Intel that our position is that as well: this really
> must not be on by default.
Thanks for pointing to the AMD doc, it's indeed clearly stated there.
On Mon, 19 Nov 2018, Arjan van de Ven wrote:
> In the documentation, AMD officially recommends against this by default,
> and I can speak for Intel that our position is that as well: this really
> must not be on by default.
Thanks for pointing to the AMD doc, it's indeed clearly stated there.
On Sun, 18 Nov 2018, Linus Torvalds wrote:
> This was marked for stable, and honestly, nowhere in the discussion
> did I see any mention of just *how* bad the performance impact of this
> was.
>
> When performance goes down by 50% on some loads, people need to start
> asking themselves whether
On Sun, 18 Nov 2018, Linus Torvalds wrote:
> This was marked for stable, and honestly, nowhere in the discussion
> did I see any mention of just *how* bad the performance impact of this
> was.
>
> When performance goes down by 50% on some loads, people need to start
> asking themselves whether
On Sun, 18 Nov 2018, Tim Chen wrote:
> On 11/18/2018 02:17 PM, Jiri Kosina wrote:
> > On Sun, 18 Nov 2018, Linus Torvalds wrote:
> >
> >>> So, I think it's as theoretical as any other spectrev2 (only with the
> >>> extra "HT" condition added on top).
> >>
> >> What? No.
> >>
> >> It's *way* more
On Sun, 18 Nov 2018, Tim Chen wrote:
> On 11/18/2018 02:17 PM, Jiri Kosina wrote:
> > On Sun, 18 Nov 2018, Linus Torvalds wrote:
> >
> >>> So, I think it's as theoretical as any other spectrev2 (only with the
> >>> extra "HT" condition added on top).
> >>
> >> What? No.
> >>
> >> It's *way* more
On Mon, 19 Nov 2018, Ingo Molnar wrote:
> > This was marked for stable, and honestly, nowhere in the discussion
> > did I see any mention of just *how* bad the performance impact of this
> > was.
>
> Yeah. This was an oversight - we'll fix it!
>
> > When performance goes down by 50% on some
On Mon, 19 Nov 2018, Ingo Molnar wrote:
> > This was marked for stable, and honestly, nowhere in the discussion
> > did I see any mention of just *how* bad the performance impact of this
> > was.
>
> Yeah. This was an oversight - we'll fix it!
>
> > When performance goes down by 50% on some
* Linus Torvalds wrote:
> This was marked for stable, and honestly, nowhere in the discussion
> did I see any mention of just *how* bad the performance impact of this
> was.
Yeah. This was an oversight - we'll fix it!
> When performance goes down by 50% on some loads, people need to start
>
* Linus Torvalds wrote:
> This was marked for stable, and honestly, nowhere in the discussion
> did I see any mention of just *how* bad the performance impact of this
> was.
Yeah. This was an oversight - we'll fix it!
> When performance goes down by 50% on some loads, people need to start
>
On Sun, Nov 18, 2018 at 02:40:28PM -0800, Tim Chen wrote:
> Tasks that want extra security will enable that via prctl interface or
> making themselves non-dumpable.
Well, you need to be careful regarding the last part of your option
above, because a number of network daemons become non-dumpable
On Sun, Nov 18, 2018 at 02:40:28PM -0800, Tim Chen wrote:
> Tasks that want extra security will enable that via prctl interface or
> making themselves non-dumpable.
Well, you need to be careful regarding the last part of your option
above, because a number of network daemons become non-dumpable
> So my patchset and Jiri's patchset should probably be merged together, so the
> users have a choice of the behavior.
... or delay Jiri's patchkit until the scheduler can actually check
properly for the cases when it is really needed.
-Andi
> So my patchset and Jiri's patchset should probably be merged together, so the
> users have a choice of the behavior.
... or delay Jiri's patchkit until the scheduler can actually check
properly for the cases when it is really needed.
-Andi
Linus Torvalds writes:
> On Sun, Nov 18, 2018 at 2:17 PM Jiri Kosina wrote:
>> Which gets us back to Tim's fixup patch. Do you still prefer the revert,
>> given the existence of that?
>
> I don't think the code needs to be reverted, but the *behavior* of
> just unconditionally enabling STIBP
Linus Torvalds writes:
> On Sun, Nov 18, 2018 at 2:17 PM Jiri Kosina wrote:
>> Which gets us back to Tim's fixup patch. Do you still prefer the revert,
>> given the existence of that?
>
> I don't think the code needs to be reverted, but the *behavior* of
> just unconditionally enabling STIBP
On 11/19/2018 6:00 AM, Linus Torvalds wrote:
On Sun, Nov 18, 2018 at 1:49 PM Jiri Kosina wrote:
So why do that STIBP slow-down by default when the people who *really*
care already disabled SMT?
BTW for them, there is no impact at all.
Right. People who really care about security and are
On 11/19/2018 6:00 AM, Linus Torvalds wrote:
On Sun, Nov 18, 2018 at 1:49 PM Jiri Kosina wrote:
So why do that STIBP slow-down by default when the people who *really*
care already disabled SMT?
BTW for them, there is no impact at all.
Right. People who really care about security and are
On Sun, 18 Nov 2018, Jiri Kosina wrote:
> It's probably not just browsers, but anything running JITed sandboxed
> code. So the most straightforward way might be the prctl() aproach, where
> userspace would claim "I do care about this, please fix it up for me". So
> prctl() + perhaps SECCOMP.
On Sun, 18 Nov 2018, Jiri Kosina wrote:
> It's probably not just browsers, but anything running JITed sandboxed
> code. So the most straightforward way might be the prctl() aproach, where
> userspace would claim "I do care about this, please fix it up for me". So
> prctl() + perhaps SECCOMP.
On 11/18/2018 02:36 PM, Linus Torvalds wrote:
> On Sun, Nov 18, 2018 at 2:17 PM Jiri Kosina wrote:
>> Which gets us back to Tim's fixup patch. Do you still prefer the revert,
>> given the existence of that?
>
> I don't think the code needs to be reverted, but the *behavior* of
> just
On 11/18/2018 02:36 PM, Linus Torvalds wrote:
> On Sun, Nov 18, 2018 at 2:17 PM Jiri Kosina wrote:
>> Which gets us back to Tim's fixup patch. Do you still prefer the revert,
>> given the existence of that?
>
> I don't think the code needs to be reverted, but the *behavior* of
> just
> On Nov 18, 2018, at 2:17 PM, Jiri Kosina wrote:
>
> It's probably not just browsers, but anything running JITed sandboxed
> code. So the most straightforward way might be the prctl() aproach, where
> userspace would claim "I do care about this, please fix it up for me". So
> prctl() +
> On Nov 18, 2018, at 2:17 PM, Jiri Kosina wrote:
>
> It's probably not just browsers, but anything running JITed sandboxed
> code. So the most straightforward way might be the prctl() aproach, where
> userspace would claim "I do care about this, please fix it up for me". So
> prctl() +
On 11/18/2018 02:17 PM, Jiri Kosina wrote:
> On Sun, 18 Nov 2018, Linus Torvalds wrote:
>
>>> So, I think it's as theoretical as any other spectrev2 (only with the
>>> extra "HT" condition added on top).
>>
>> What? No.
>>
>> It's *way* more theoretical than something like meltdown, which could
On 11/18/2018 02:17 PM, Jiri Kosina wrote:
> On Sun, 18 Nov 2018, Linus Torvalds wrote:
>
>>> So, I think it's as theoretical as any other spectrev2 (only with the
>>> extra "HT" condition added on top).
>>
>> What? No.
>>
>> It's *way* more theoretical than something like meltdown, which could
On Sun, Nov 18, 2018 at 2:17 PM Jiri Kosina wrote:
> Which gets us back to Tim's fixup patch. Do you still prefer the revert,
> given the existence of that?
I don't think the code needs to be reverted, but the *behavior* of
just unconditionally enabling STIBP needs to be reverted.
Because it
On Sun, Nov 18, 2018 at 2:19 PM Jiri Kosina wrote:
> Which gets us back to Tim's fixup patch. Do you still prefer the revert,
> given the existence of that? I think that if Tim's fixup makes it through
> (it's currently missing SECCOMP handling, but that is trivial to add on
> top), it might be
On Sun, Nov 18, 2018 at 2:17 PM Jiri Kosina wrote:
> Which gets us back to Tim's fixup patch. Do you still prefer the revert,
> given the existence of that?
I don't think the code needs to be reverted, but the *behavior* of
just unconditionally enabling STIBP needs to be reverted.
Because it
On Sun, Nov 18, 2018 at 2:19 PM Jiri Kosina wrote:
> Which gets us back to Tim's fixup patch. Do you still prefer the revert,
> given the existence of that? I think that if Tim's fixup makes it through
> (it's currently missing SECCOMP handling, but that is trivial to add on
> top), it might be
On Sun, 18 Nov 2018, Linus Torvalds wrote:
> > So, I think it's as theoretical as any other spectrev2 (only with the
> > extra "HT" condition added on top).
>
> What? No.
>
> It's *way* more theoretical than something like meltdown, which could
> be trivially used to get data from another
On Sun, 18 Nov 2018, Linus Torvalds wrote:
> > So, I think it's as theoretical as any other spectrev2 (only with the
> > extra "HT" condition added on top).
>
> What? No.
>
> It's *way* more theoretical than something like meltdown, which could
> be trivially used to get data from another
On Sun, Nov 18, 2018 at 10:49:44PM +0100, Jiri Kosina wrote:
> odds are that people
> who don't care about spectrev2 already have 'nospectre_v2' on their
> command-line, so they are fine as well.
FWIW in our appliances, we never modify the boot loader's cmdline
in field, we only provide new
On Sun, Nov 18, 2018 at 10:49:44PM +0100, Jiri Kosina wrote:
> odds are that people
> who don't care about spectrev2 already have 'nospectre_v2' on their
> command-line, so they are fine as well.
FWIW in our appliances, we never modify the boot loader's cmdline
in field, we only provide new
On Sun, Nov 18, 2018 at 1:49 PM Jiri Kosina wrote:
>
> > So why do that STIBP slow-down by default when the people who *really*
> > care already disabled SMT?
>
> BTW for them, there is no impact at all.
Right. People who really care about security and are anal about it do
not see *any*
On Sun, Nov 18, 2018 at 1:49 PM Jiri Kosina wrote:
>
> > So why do that STIBP slow-down by default when the people who *really*
> > care already disabled SMT?
>
> BTW for them, there is no impact at all.
Right. People who really care about security and are anal about it do
not see *any*
On Sun, 18 Nov 2018, Linus Torvalds wrote:
> This was marked for stable, and honestly, nowhere in the discussion
> did I see any mention of just *how* bad the performance impact of this
> was.
Frankly, I ran some benchmarks myself, and am seeing very, very
varying/noisy results, which were
On Sun, 18 Nov 2018, Linus Torvalds wrote:
> This was marked for stable, and honestly, nowhere in the discussion
> did I see any mention of just *how* bad the performance impact of this
> was.
Frankly, I ran some benchmarks myself, and am seeing very, very
varying/noisy results, which were
This was marked for stable, and honestly, nowhere in the discussion
did I see any mention of just *how* bad the performance impact of this
was.
When performance goes down by 50% on some loads, people need to start
asking themselves whether it was worth it. It's apparently better to
just disable
This was marked for stable, and honestly, nowhere in the discussion
did I see any mention of just *how* bad the performance impact of this
was.
When performance goes down by 50% on some loads, people need to start
asking themselves whether it was worth it. It's apparently better to
just disable
42 matches
Mail list logo
