On 01/30/2018 07:59 PM, Josh Poimboeuf wrote:
> On Tue, Jan 30, 2018 at 01:23:17PM -0800, Tim Chen wrote:
>> On 01/30/2018 09:48 AM, Josh Poimboeuf wrote:
>>> On Mon, Jan 29, 2018 at 10:04:47PM +, David Woodhouse wrote:
From: Tim Chen
Flush indirect branches when switching into
On Tue, Jan 30, 2018 at 01:23:17PM -0800, Tim Chen wrote:
> On 01/30/2018 09:48 AM, Josh Poimboeuf wrote:
> > On Mon, Jan 29, 2018 at 10:04:47PM +, David Woodhouse wrote:
> >> From: Tim Chen
> >>
> >> Flush indirect branches when switching into a process that marked itself
> >> non dumpable. T
On Tue, Jan 30, 2018 at 04:25:26PM -0800, Tim Chen wrote:
> As dumpable is a property in mm->flags, it affects all threads running
> on other cpus sharing the same mm.
It is not about sharing the same mm - it is about sharing the RSB. How
many logical CPUs share an RSB? If it is per core (which ca
On 01/30/2018 02:43 PM, Borislav Petkov wrote:
> On Tue, Jan 30, 2018 at 02:26:53PM -0800, Tim Chen wrote:
>> If the process has multiple threads running on different cpus,
>
> I'm talking about issuing the barrier in set_dumpable(). What threads on
> multiple CPUs?
>
As dumpable is a property i
On Tue, Jan 30, 2018 at 11:21:58PM +0100, Thomas Gleixner wrote:
> prctl(PR_SET_DUMPABLE, 0) = 0
>
> That does the trick.
Ok, found it: https://dev.gnupg.org/T1211
Looks like this is debian-specific for now. Not in gnupg mainlne, AFAICT.
--
Regards/Gruss,
Boris.
Good mailing
On Tue, Jan 30, 2018 at 02:26:53PM -0800, Tim Chen wrote:
> If the process has multiple threads running on different cpus,
I'm talking about issuing the barrier in set_dumpable(). What threads on
multiple CPUs?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and t
On 01/30/2018 01:57 PM, Borislav Petkov wrote:
> On Tue, Jan 30, 2018 at 01:03:20PM -0800, Tim Chen wrote:
>> So it doesn't seem to be very practical attack if the victim has set
>> itself to be non-dumpable.
>
> Probably, but considering how cheap our fix is, we might just as well
> plug that hol
On Tue, 30 Jan 2018, Borislav Petkov wrote:
> On Tue, Jan 30, 2018 at 01:23:17PM -0800, Tim Chen wrote:
> > I'm less familiar with gpg-agent. Dave was the one who
> > put in comments about gpg-agent in this patch so perhaps
> > he can comment.
>
> So I looked at gpg-agent and AFAICT, it disables
On Tue, Jan 30, 2018 at 01:23:17PM -0800, Tim Chen wrote:
> I'm less familiar with gpg-agent. Dave was the one who
> put in comments about gpg-agent in this patch so perhaps
> he can comment.
So I looked at gpg-agent and AFAICT, it disables core dumping with
setrlimit().
I wasn't able to attach
On Tue, Jan 30, 2018 at 01:03:20PM -0800, Tim Chen wrote:
> So it doesn't seem to be very practical attack if the victim has set
> itself to be non-dumpable.
Probably, but considering how cheap our fix is, we might just as well
plug that hole too.
--
Regards/Gruss,
Boris.
Good mailing pract
On 01/30/2018 09:48 AM, Josh Poimboeuf wrote:
> On Mon, Jan 29, 2018 at 10:04:47PM +, David Woodhouse 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 t
On 01/30/2018 12:38 PM, Borislav Petkov wrote:
> On Mon, Jan 29, 2018 at 10:04:47PM +, David Woodhouse wrote:
>> +if (tsk && tsk->mm &&
>> +tsk->mm->context.ctx_id != last_ctx_id &&
>> +get_dumpable(tsk->mm) != SUID_DUMP_USER)
>> +
On Mon, Jan 29, 2018 at 10:04:47PM +, David Woodhouse wrote:
> + if (tsk && tsk->mm &&
> + tsk->mm->context.ctx_id != last_ctx_id &&
> + get_dumpable(tsk->mm) != SUID_DUMP_USER)
> + indirect_branch_prediction_barrier();
Ok, so whi
On Mon, Jan 29, 2018 at 10:04:47PM +, David Woodhouse 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.
I wonder what the poi
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.
If done naïvely, we could switch to a kernel idle thread and then back
to the original process,
On Mon, Jan 29, 2018 at 12:44:59PM +, David Woodhouse wrote:
> On Mon, 2018-01-29 at 13:28 +0100, Dominik Brodowski wrote:
>
> > The commit message is much more about the A->idle-> improvement than
> > on the basic design decisions to limit this to non-dumpable processes.
>
> Yeah, I collapse
On Mon, 2018-01-29 at 13:28 +0100, Dominik Brodowski wrote:
> The commit message is much more about the A->idle-> improvement than
> on the basic design decisions to limit this to non-dumpable processes.
Yeah, I collapsed the commit messages from the three commits into one.
But the resulting comm
On Mon, Jan 29, 2018 at 11:33:28AM +, David Woodhouse 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.
>
> If done naïvely,
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.
If done naïvely, we could switch to a kernel idle thread and then back
to the original process,
19 matches
Mail list logo
