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 d
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 it
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 t
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 load
* 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
> a
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 by
> 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 nee
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 a
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.
I
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 unconditiona
> 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() + perh
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 was
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 th
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 protec
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 kern
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* advantage
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 rathe
20 matches
Mail list logo
