On Wed, 5 Sep 2018, Andrea Arcangeli wrote:
> [ 1838.621010] Kernel panic - not syncing: Watchdog detected hard LOCKUP on
> cpu 6
> [ 1838.629070] CPU: 6 PID: 0 Comm: swapper/6 Not tainted
> 3.10.0-327.62.4.el7.x86_64 #1
> [ 1838.637610] Hardware name: Dell Inc. PowerEdge R430/0CN7X8, BIOS
On Wed, 5 Sep 2018, Andrea Arcangeli wrote:
> [ 1838.621010] Kernel panic - not syncing: Watchdog detected hard LOCKUP on
> cpu 6
> [ 1838.629070] CPU: 6 PID: 0 Comm: swapper/6 Not tainted
> 3.10.0-327.62.4.el7.x86_64 #1
> [ 1838.637610] Hardware name: Dell Inc. PowerEdge R430/0CN7X8, BIOS
> -Original Message-
> From: Peter Zijlstra [mailto:pet...@infradead.org]
> Sent: Wednesday, September 05, 2018 12:03 PM
> To: Andrea Arcangeli
> Cc: Jiri Kosina ; Andi Kleen ; Tim
> Chen
> ; Schaufler, Casey ;
> Thomas Gleixner ; Ingo Molnar ;
> Josh Poimboeuf ; Woodhouse, David
> ;
> -Original Message-
> From: Peter Zijlstra [mailto:pet...@infradead.org]
> Sent: Wednesday, September 05, 2018 12:03 PM
> To: Andrea Arcangeli
> Cc: Jiri Kosina ; Andi Kleen ; Tim
> Chen
> ; Schaufler, Casey ;
> Thomas Gleixner ; Ingo Molnar ;
> Josh Poimboeuf ; Woodhouse, David
> ;
On Wed, Sep 05, 2018 at 02:40:18PM -0400, Andrea Arcangeli wrote:
> [ 1838.769917] <> [] avc_compute_av+0x126/0x1b5
That does read_lock(), which is not allowed from scheduler context.
> [ 1838.777125] [] ? walk_tg_tree_from+0xbe/0x110
> [ 1838.783828] [] avc_has_perm_noaudit+0xc4/0x110
In
On Wed, Sep 05, 2018 at 02:40:18PM -0400, Andrea Arcangeli wrote:
> [ 1838.769917] <> [] avc_compute_av+0x126/0x1b5
That does read_lock(), which is not allowed from scheduler context.
> [ 1838.777125] [] ? walk_tg_tree_from+0xbe/0x110
> [ 1838.783828] [] avc_has_perm_noaudit+0xc4/0x110
In
On Wed, 5 Sep 2018, Andrea Arcangeli wrote:
> Perhaps you didn't sandbox KVM inside selinux by default?
We by default do not enable selinux, so that's probably why.
Thanks again, will go through the code in mainline and adapt the patch
before sending v4.
--
Jiri Kosina
SUSE Labs
On Wed, 5 Sep 2018, Andrea Arcangeli wrote:
> Perhaps you didn't sandbox KVM inside selinux by default?
We by default do not enable selinux, so that's probably why.
Thanks again, will go through the code in mainline and adapt the patch
before sending v4.
--
Jiri Kosina
SUSE Labs
On Wed, Sep 05, 2018 at 08:29:07PM +0200, Jiri Kosina wrote:
> (and no, my testing of the patch I sent on current tree didn't produce any
> hangs -- was there a reliable way to trigger it on 3.10?).
Only a very specific libvirt acceptance test found this after a while
and it wasn't a customer it
On Wed, Sep 05, 2018 at 08:29:07PM +0200, Jiri Kosina wrote:
> (and no, my testing of the patch I sent on current tree didn't produce any
> hangs -- was there a reliable way to trigger it on 3.10?).
Only a very specific libvirt acceptance test found this after a while
and it wasn't a customer it
On Wed, 5 Sep 2018, Andi Kleen wrote:
> Please if you repost include plenty of performance numbers for multi
> threaded workloads. It's ridiculous to even discuss this without them.
Talking about ridiculous ... I find it a bit sad that Intel has let this
be unfixed for 3/4 years in linux;
On Wed, 5 Sep 2018, Andi Kleen wrote:
> Please if you repost include plenty of performance numbers for multi
> threaded workloads. It's ridiculous to even discuss this without them.
Talking about ridiculous ... I find it a bit sad that Intel has let this
be unfixed for 3/4 years in linux;
On Wed, 5 Sep 2018, Andrea Arcangeli wrote:
> ptrace_has_cap(tcred->user_ns, mode) is supposed to eventually lockup
> hard if called from scheduler as it does some locking, and we fixed
> that already half a year ago.
>
> Not sure how it's still unfixed in Jiri's codebase after so long, or
> if
On Wed, 5 Sep 2018, Andrea Arcangeli wrote:
> ptrace_has_cap(tcred->user_ns, mode) is supposed to eventually lockup
> hard if called from scheduler as it does some locking, and we fixed
> that already half a year ago.
>
> Not sure how it's still unfixed in Jiri's codebase after so long, or
> if
On Wed, 5 Sep 2018, Andi Kleen wrote:
> > So, after giving it a bit more thought, I still believe "I want spectre V2
> > protection" vs. "I do not care about spectre V2 on my system
> > (=nospectre_v2)" are the sane options we should provide; so I'll respin v4
> > of my patchset, including the
On Wed, 5 Sep 2018, Andi Kleen wrote:
> > So, after giving it a bit more thought, I still believe "I want spectre V2
> > protection" vs. "I do not care about spectre V2 on my system
> > (=nospectre_v2)" are the sane options we should provide; so I'll respin v4
> > of my patchset, including the
On Wed, Sep 05, 2018 at 08:58:23AM -0700, Andi Kleen wrote:
> > So, after giving it a bit more thought, I still believe "I want spectre V2
> > protection" vs. "I do not care about spectre V2 on my system
> > (=nospectre_v2)" are the sane options we should provide; so I'll respin v4
> > of my
On Wed, Sep 05, 2018 at 08:58:23AM -0700, Andi Kleen wrote:
> > So, after giving it a bit more thought, I still believe "I want spectre V2
> > protection" vs. "I do not care about spectre V2 on my system
> > (=nospectre_v2)" are the sane options we should provide; so I'll respin v4
> > of my
> So, after giving it a bit more thought, I still believe "I want spectre V2
> protection" vs. "I do not care about spectre V2 on my system
> (=nospectre_v2)" are the sane options we should provide; so I'll respin v4
> of my patchset, including the ptrace check in switch_mm() (statically
>
> So, after giving it a bit more thought, I still believe "I want spectre V2
> protection" vs. "I do not care about spectre V2 on my system
> (=nospectre_v2)" are the sane options we should provide; so I'll respin v4
> of my patchset, including the ptrace check in switch_mm() (statically
>
> -Original Message-
> From: Peter Zijlstra [mailto:pet...@infradead.org]
> Sent: Wednesday, September 05, 2018 1:00 AM
> To: Jiri Kosina
> Cc: Tim Chen ; Thomas Gleixner
> ; Ingo Molnar ; Josh Poimboeuf
> ; Andrea Arcangeli ;
> Woodhouse, David ; Oleg Nesterov
> ; Schaufler, Casey ;
> -Original Message-
> From: Peter Zijlstra [mailto:pet...@infradead.org]
> Sent: Wednesday, September 05, 2018 1:00 AM
> To: Jiri Kosina
> Cc: Tim Chen ; Thomas Gleixner
> ; Ingo Molnar ; Josh Poimboeuf
> ; Andrea Arcangeli ;
> Woodhouse, David ; Oleg Nesterov
> ; Schaufler, Casey ;
On Tue, Sep 04, 2018 at 07:35:29PM +0200, Jiri Kosina wrote:
> On Tue, 4 Sep 2018, Tim Chen wrote:
>
> > > Current ptrace_may_access() implementation assumes that the 'source' task
> > > is
> > > always the caller (current).
> > >
> > > Expose ___ptrace_may_access() that can be used to apply
On Tue, Sep 04, 2018 at 07:35:29PM +0200, Jiri Kosina wrote:
> On Tue, 4 Sep 2018, Tim Chen wrote:
>
> > > Current ptrace_may_access() implementation assumes that the 'source' task
> > > is
> > > always the caller (current).
> > >
> > > Expose ___ptrace_may_access() that can be used to apply
On Tue, Sep 04, 2018 at 04:40:57PM +0200, Jiri Kosina wrote:
> From: Jiri Kosina
>
> Current ptrace_may_access() implementation assumes that the 'source' task is
> always the caller (current).
Note that now you 'fixed' the new user, this is still true. Which makes
me think you do not in fact
On Tue, Sep 04, 2018 at 04:40:57PM +0200, Jiri Kosina wrote:
> From: Jiri Kosina
>
> Current ptrace_may_access() implementation assumes that the 'source' task is
> always the caller (current).
Note that now you 'fixed' the new user, this is still true. Which makes
me think you do not in fact
On Tue, 4 Sep 2018, Tim Chen wrote:
> I think STIBP should be an opt in option as it will have significant
> impact on performance. The attack from neighbor thread is pretty
> difficult to pull off considering you have to know what the sibling
> thread is running and its address allocation.
In
On Tue, 4 Sep 2018, Tim Chen wrote:
> I think STIBP should be an opt in option as it will have significant
> impact on performance. The attack from neighbor thread is pretty
> difficult to pull off considering you have to know what the sibling
> thread is running and its address allocation.
In
On Wed, Sep 05, 2018 at 01:00:37AM +, Schaufler, Casey wrote:
> Sorry, I've been working in security too long for my
> optimistic streak to be very wide.
Eheh. So I was simply trying to follow in context, but it wasn't
entirely clear, so I tried to take it out of context and then it was
even
On Wed, Sep 05, 2018 at 01:00:37AM +, Schaufler, Casey wrote:
> Sorry, I've been working in security too long for my
> optimistic streak to be very wide.
Eheh. So I was simply trying to follow in context, but it wasn't
entirely clear, so I tried to take it out of context and then it was
even
> -Original Message-
> From: Andrea Arcangeli [mailto:aarca...@redhat.com]
> Sent: Tuesday, September 04, 2018 4:37 PM
> To: Schaufler, Casey
> Cc: Jiri Kosina ; Tim Chen ;
> Thomas Gleixner ; Ingo Molnar ;
> Peter Zijlstra ; Josh Poimboeuf
> ; Woodhouse, David ; Oleg
> Nesterov ;
> -Original Message-
> From: Andrea Arcangeli [mailto:aarca...@redhat.com]
> Sent: Tuesday, September 04, 2018 4:37 PM
> To: Schaufler, Casey
> Cc: Jiri Kosina ; Tim Chen ;
> Thomas Gleixner ; Ingo Molnar ;
> Peter Zijlstra ; Josh Poimboeuf
> ; Woodhouse, David ; Oleg
> Nesterov ;
Hello,
On Tue, Sep 04, 2018 at 06:10:47PM +, Schaufler, Casey wrote:
> The real reason to use an LSM based approach is that overloading ptrace
> checks is a Really Bad Idea. Ptrace is a user interface. Side-channel is a
> processor interface. Even if ptrace_may_access() does exactly what you
Hello,
On Tue, Sep 04, 2018 at 06:10:47PM +, Schaufler, Casey wrote:
> The real reason to use an LSM based approach is that overloading ptrace
> checks is a Really Bad Idea. Ptrace is a user interface. Side-channel is a
> processor interface. Even if ptrace_may_access() does exactly what you
On 09/04/2018 11:48 AM, Jiri Kosina wrote:
> On Tue, 4 Sep 2018, Schaufler, Casey wrote:
>
>>> So if this should be done in LSM, it'd probably have to be written by
>>> someone else than me :) who actually understands how the "sidechannel LSM"
>>> idea works.
>>
>> Yes. That would be me.
>
>
On 09/04/2018 11:48 AM, Jiri Kosina wrote:
> On Tue, 4 Sep 2018, Schaufler, Casey wrote:
>
>>> So if this should be done in LSM, it'd probably have to be written by
>>> someone else than me :) who actually understands how the "sidechannel LSM"
>>> idea works.
>>
>> Yes. That would be me.
>
>
On Tue, 4 Sep 2018, Schaufler, Casey wrote:
> > So if this should be done in LSM, it'd probably have to be written by
> > someone else than me :) who actually understands how the "sidechannel LSM"
> > idea works.
>
> Yes. That would be me.
Ok, cool. Then 1/2 and 2/3 can be ignored / replaced
On Tue, 4 Sep 2018, Schaufler, Casey wrote:
> > So if this should be done in LSM, it'd probably have to be written by
> > someone else than me :) who actually understands how the "sidechannel LSM"
> > idea works.
>
> Yes. That would be me.
Ok, cool. Then 1/2 and 2/3 can be ignored / replaced
> -Original Message-
> From: Jiri Kosina [mailto:ji...@kernel.org]
> Sent: Tuesday, September 04, 2018 10:35 AM
> To: Tim Chen
> Cc: Thomas Gleixner ; Ingo Molnar ;
> Peter Zijlstra ; Josh Poimboeuf
> ; Andrea Arcangeli ;
> Woodhouse, David ; Oleg Nesterov
> ; Schaufler, Casey ; linux-
>
> -Original Message-
> From: Jiri Kosina [mailto:ji...@kernel.org]
> Sent: Tuesday, September 04, 2018 10:35 AM
> To: Tim Chen
> Cc: Thomas Gleixner ; Ingo Molnar ;
> Peter Zijlstra ; Josh Poimboeuf
> ; Andrea Arcangeli ;
> Woodhouse, David ; Oleg Nesterov
> ; Schaufler, Casey ; linux-
>
On Tue, 4 Sep 2018, Tim Chen wrote:
> > Current ptrace_may_access() implementation assumes that the 'source' task is
> > always the caller (current).
> >
> > Expose ___ptrace_may_access() that can be used to apply the check on
> > arbitrary
> > tasks.
>
> Casey recently has proposed putting
On Tue, 4 Sep 2018, Tim Chen wrote:
> > Current ptrace_may_access() implementation assumes that the 'source' task is
> > always the caller (current).
> >
> > Expose ___ptrace_may_access() that can be used to apply the check on
> > arbitrary
> > tasks.
>
> Casey recently has proposed putting
On 09/04/2018 07:40 AM, Jiri Kosina wrote:
> From: Jiri Kosina
>
> Current ptrace_may_access() implementation assumes that the 'source' task is
> always the caller (current).
>
> Expose ___ptrace_may_access() that can be used to apply the check on arbitrary
> tasks.
Casey recently has proposed
On 09/04/2018 07:40 AM, Jiri Kosina wrote:
> From: Jiri Kosina
>
> Current ptrace_may_access() implementation assumes that the 'source' task is
> always the caller (current).
>
> Expose ___ptrace_may_access() that can be used to apply the check on arbitrary
> tasks.
Casey recently has proposed
On Tue, 4 Sep 2018, Thomas Gleixner wrote:
> On Tue, 4 Sep 2018, Jiri Kosina wrote:
> > +/**
> > + * ___ptrace_may_access - variant of ptrace_may_access that can be used
> > + * between two arbitrary tasks
> > + * @curr: source task
>
> That's a pretty shitty name, really. If @curr is supposed to
On Tue, 4 Sep 2018, Thomas Gleixner wrote:
> On Tue, 4 Sep 2018, Jiri Kosina wrote:
> > +/**
> > + * ___ptrace_may_access - variant of ptrace_may_access that can be used
> > + * between two arbitrary tasks
> > + * @curr: source task
>
> That's a pretty shitty name, really. If @curr is supposed to
On Tue, 4 Sep 2018, Jiri Kosina wrote:
> +/**
> + * ___ptrace_may_access - variant of ptrace_may_access that can be used
> + * between two arbitrary tasks
> + * @curr: source task
That's a pretty shitty name, really. If @curr is supposed to be an
arbitrary task, then please rename it in a way
On Tue, 4 Sep 2018, Jiri Kosina wrote:
> +/**
> + * ___ptrace_may_access - variant of ptrace_may_access that can be used
> + * between two arbitrary tasks
> + * @curr: source task
That's a pretty shitty name, really. If @curr is supposed to be an
arbitrary task, then please rename it in a way
From: Jiri Kosina
Current ptrace_may_access() implementation assumes that the 'source' task is
always the caller (current).
Expose ___ptrace_may_access() that can be used to apply the check on arbitrary
tasks.
Originally-by: Tim Chen
Signed-off-by: Jiri Kosina
---
Sorry for the resend, my
From: Jiri Kosina
Current ptrace_may_access() implementation assumes that the 'source' task is
always the caller (current).
Expose ___ptrace_may_access() that can be used to apply the check on arbitrary
tasks.
Originally-by: Tim Chen
Signed-off-by: Jiri Kosina
---
Sorry for the resend, my
From: Jiri Kosina
Current ptrace_may_access() implementation assumes that the 'source' task is
always the caller (current).
Expose ___ptrace_may_access() that can be used to apply the check on arbitrary
tasks.
Originally-by: Tim Chen
Signed-off-by: Jiri Kosina
---
include/linux/ptrace.h |
From: Jiri Kosina
Current ptrace_may_access() implementation assumes that the 'source' task is
always the caller (current).
Expose ___ptrace_may_access() that can be used to apply the check on arbitrary
tasks.
Originally-by: Tim Chen
Signed-off-by: Jiri Kosina
---
include/linux/ptrace.h |
52 matches
Mail list logo
