On Mon, Jan 29, 2018 at 01:35:30AM -0500, Jon Masters wrote:
> > So if I understand it right, this is only needed if the 'other'
> > executable itself is susceptible to spectre. If say someone audited gpg
> > for spectre-v1 and build it with retpoline, it would be safe to not
> > issue the IBPB, ri
Hi Peter, David, all,
First a quick note on David's earlier comment, about this optimization
being still up for debate. The problem with this optimization as-is is
that it doesn't protect userspace-to-userspace unless applications are
rebuilt and we get the infrastructure to handle that (ELF, what
On 01/20/2018 01:06 PM, Woodhouse, David wrote:
> On Sat, 2018-01-20 at 20:22 +0100, KarimAllah Ahmed wrote:
>> From: Tim Chen
>
> I think this is probably From: Andi now rather than From: Tim?
This change is from Andi.
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/arc
On Mon, 2018-01-22 at 11:19 +0100, Peter Zijlstra wrote:
> Right, so if its v2/retpoline only, we really should do this asap and
> then rebuild world on distros (or arch/gentoo people could read a book
> or something).
By the time we manage to rebuild all the distros, I *seriously* hope
that someo
On Sun, Jan 21, 2018 at 12:04:03PM -, David Woodhouse wrote:
> > So if I understand it right, this is only needed if the 'other'
> > executable itself is susceptible to spectre. If say someone audited gpg
> > for spectre-v1 and build it with retpoline, it would be safe to not
> > issue the IBPB
On Sun, 2018-01-21 at 17:21 +0100, Ingo Molnar wrote:
>
> Because putting something like this into an ELF flag raises the question of
> who isÂ
> allowed to set the flag - does a user-compiled binary count? If yes then it
> wouldÂ
> be a trivial thing for local exploits to set the flag and turn
On 1/21/2018 8:21 AM, Ingo Molnar wrote:
So if it's only about the scheduler barrier, what cycle cost are we talking
about
here?
in the order of 5000 to 1 cycles.
(depends a bit on the cpu generation but this range is a reasonable
approximation)
Because putting something like this
* Peter Zijlstra wrote:
> On Sat, Jan 20, 2018 at 08:22:55PM +0100, KarimAllah Ahmed wrote:
> > From: Tim Chen
> >
> > Flush indirect branches when switching into a process that marked
> > itself non dumpable. This protects high value processes like gpg
> > better, without having too high per
On Sun, Jan 21, 2018 at 4:04 AM, David Woodhouse wrote:
>
>> On Sat, Jan 20, 2018 at 08:22:55PM +0100, KarimAllah Ahmed wrote:
>>> From: Tim Chen
>>>
>>> Flush indirect branches when switching into a process that marked
>>> itself non dumpable. This protects high value processes like gpg
>>> bet
> On Sat, Jan 20, 2018 at 08:22:55PM +0100, KarimAllah Ahmed wrote:
>> From: Tim Chen
>>
>> Flush indirect branches when switching into a process that marked
>> itself non dumpable. This protects high value processes like gpg
>> better, without having too high performance overhead.
>
> So if I u
On Sat, Jan 20, 2018 at 08:22:55PM +0100, KarimAllah Ahmed wrote:
> From: Tim Chen
>
> Flush indirect branches when switching into a process that marked
> itself non dumpable. This protects high value processes like gpg
> better, without having too high performance overhead.
So if I understand
On Sat, 2018-01-20 at 20:22 +0100, KarimAllah Ahmed wrote:
> From: Tim Chen
I think this is probably From: Andi now rather than From: Tim?
We do need the series this far in order to have a full retpoline-based
mitigation, and I'd like to see that go in sooner rather than later.
There's a little
From: Tim Chen
Flush indirect branches when switching into a process that marked
itself non dumpable. This protects high value processes like gpg
better, without having too high performance overhead.
Signed-off-by: Andi Kleen
Signed-off-by: David Woodhouse
Signed-off-by: KarimAllah Ahmed
---
13 matches
Mail list logo
