On Sun, 21 Oct 2018, Pavel Machek wrote:
> Imagine JIT running evil code (flash, javascript). JIT will prevent evil
> code from doing ptrace() (or maybe there is syscall filter in effect or
> something like that), but if evil code can poison branch buffers and do
> timings, security problem
On Sun, 21 Oct 2018, Pavel Machek wrote:
> Imagine JIT running evil code (flash, javascript). JIT will prevent evil
> code from doing ptrace() (or maybe there is syscall filter in effect or
> something like that), but if evil code can poison branch buffers and do
> timings, security problem
Hi!
> In order to minimize the performance impact (for usecases that do require
> spectrev2 protection), issue the barrier only in cases when switching between
> processess where the victim can't be ptraced by the potential attacker (as in
> such cases, the attacker doesn't have to bother with
Hi!
> In order to minimize the performance impact (for usecases that do require
> spectrev2 protection), issue the barrier only in cases when switching between
> processess where the victim can't be ptraced by the potential attacker (as in
> such cases, the attacker doesn't have to bother with
On Tue, 11 Sep 2018, Schaufler, Casey wrote:
> How about this? Take Jiri's patch as written. You get everything except checks
> on the security blobs and any "magic" that my safesidechannel module did. I
> will propose a follow on patch that fixes the SELinux code to eliminate the
> locking
>
On Tue, 11 Sep 2018, Schaufler, Casey wrote:
> How about this? Take Jiri's patch as written. You get everything except checks
> on the security blobs and any "magic" that my safesidechannel module did. I
> will propose a follow on patch that fixes the SELinux code to eliminate the
> locking
>
> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
...
>
> Casey, can you please spare us the completely redundant copy of the mail
> header?
Sorry to be a bother.
> > Short of a patch to show the changes (which I wish I could do today, but
> > really can't) what I
> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
...
>
> Casey, can you please spare us the completely redundant copy of the mail
> header?
Sorry to be a bother.
> > Short of a patch to show the changes (which I wish I could do today, but
> > really can't) what I
On Mon, 10 Sep 2018, Schaufler, Casey wrote:
> > -Original Message-
> > From: Jiri Kosina [mailto:ji...@kernel.org]
> > Sent: Monday, September 10, 2018 1:42 PM
> > To: Schaufler, Casey
> > Cc: Thomas Gleixner ; Ingo Molnar ;
> > Peter Zijlstra ; Josh Poimboeuf
> > ; Andrea Arcangeli ;
>
On Mon, 10 Sep 2018, Schaufler, Casey wrote:
> > -Original Message-
> > From: Jiri Kosina [mailto:ji...@kernel.org]
> > Sent: Monday, September 10, 2018 1:42 PM
> > To: Schaufler, Casey
> > Cc: Thomas Gleixner ; Ingo Molnar ;
> > Peter Zijlstra ; Josh Poimboeuf
> > ; Andrea Arcangeli ;
>
On Mon, 10 Sep 2018, Schaufler, Casey wrote:
> > So please tell me what exactly you'd like to see changed in the IBPB patch
> > and why exactly, I am not seeing it yet.
>
> Short of a patch to show the changes (which I wish I could do today, but
> really can't)
> what I want to see is:
>
>
On Mon, 10 Sep 2018, Schaufler, Casey wrote:
> > So please tell me what exactly you'd like to see changed in the IBPB patch
> > and why exactly, I am not seeing it yet.
>
> Short of a patch to show the changes (which I wish I could do today, but
> really can't)
> what I want to see is:
>
>
gt; Tim Chen ; linux-kernel@vger.kernel.org;
> x...@kernel.org
> Subject: RE: [PATCH v5 1/2] x86/speculation: apply IBPB more strictly to avoid
> cross-process data leak
>
> On Mon, 10 Sep 2018, Schaufler, Casey wrote:
>
> > It you're going to call __ptrace_access_check(
gt; Tim Chen ; linux-kernel@vger.kernel.org;
> x...@kernel.org
> Subject: RE: [PATCH v5 1/2] x86/speculation: apply IBPB more strictly to avoid
> cross-process data leak
>
> On Mon, 10 Sep 2018, Schaufler, Casey wrote:
>
> > It you're going to call __ptrace_access_check(
On Mon, 10 Sep 2018, Schaufler, Casey wrote:
> It you're going to call __ptrace_access_check(),
I guess you mean __ptrace_may_access() here.
> which already includes an LSM hook, it makes a whole lot of sense to
> make that the path for doing any module specific checks. It seems wrong
> to
On Mon, 10 Sep 2018, Schaufler, Casey wrote:
> It you're going to call __ptrace_access_check(),
I guess you mean __ptrace_may_access() here.
> which already includes an LSM hook, it makes a whole lot of sense to
> make that the path for doing any module specific checks. It seems wrong
> to
gt; Tim Chen ; linux-kernel@vger.kernel.org;
> x...@kernel.org
> Subject: RE: [PATCH v5 1/2] x86/speculation: apply IBPB more strictly to avoid
> cross-process data leak
>
> On Mon, 10 Sep 2018, Schaufler, Casey wrote:
>
> > Yes, It would require that this patch be t
gt; Tim Chen ; linux-kernel@vger.kernel.org;
> x...@kernel.org
> Subject: RE: [PATCH v5 1/2] x86/speculation: apply IBPB more strictly to avoid
> cross-process data leak
>
> On Mon, 10 Sep 2018, Schaufler, Casey wrote:
>
> > Yes, It would require that this patch be t
On Mon, 10 Sep 2018, Schaufler, Casey wrote:
> Yes, It would require that this patch be tested against all the existing
> security modules that provide a ptrace_access_check hook. It's not like
> the security module writers don't have a bunch of locking issues to deal
> with.
Yeah, that was
On Mon, 10 Sep 2018, Schaufler, Casey wrote:
> Yes, It would require that this patch be tested against all the existing
> security modules that provide a ptrace_access_check hook. It's not like
> the security module writers don't have a bunch of locking issues to deal
> with.
Yeah, that was
gt; Tim Chen ; linux-kernel@vger.kernel.org;
> x...@kernel.org
> Subject: RE: [PATCH v5 1/2] x86/speculation: apply IBPB more strictly to avoid
> cross-process data leak
>
> On Mon, 10 Sep 2018, Schaufler, Casey wrote:
>
> > Why are you dropping the LSM check here, when in v
gt; Tim Chen ; linux-kernel@vger.kernel.org;
> x...@kernel.org
> Subject: RE: [PATCH v5 1/2] x86/speculation: apply IBPB more strictly to avoid
> cross-process data leak
>
> On Mon, 10 Sep 2018, Schaufler, Casey wrote:
>
> > Why are you dropping the LSM check here, when in v
On Mon, 10 Sep 2018, Schaufler, Casey wrote:
> Why are you dropping the LSM check here, when in v4 you fixed the
> SELinux audit locking issue? We can avoid introducing an LSM hook
> and all the baggage around it if you can do the security_ptrace_access_check()
> here.
So what guarantees that
On Mon, 10 Sep 2018, Schaufler, Casey wrote:
> Why are you dropping the LSM check here, when in v4 you fixed the
> SELinux audit locking issue? We can avoid introducing an LSM hook
> and all the baggage around it if you can do the security_ptrace_access_check()
> here.
So what guarantees that
> -Original Message-
> From: Jiri Kosina [mailto:ji...@kernel.org]
> Sent: Monday, September 10, 2018 2:24 AM
> To: Thomas Gleixner ; Ingo Molnar ;
> Peter Zijlstra ; Josh Poimboeuf
> ; Andrea Arcangeli ;
> Woodhouse, David ; Andi Kleen ;
> Tim Chen ; Schaufler, Casey
>
> Cc:
> -Original Message-
> From: Jiri Kosina [mailto:ji...@kernel.org]
> Sent: Monday, September 10, 2018 2:24 AM
> To: Thomas Gleixner ; Ingo Molnar ;
> Peter Zijlstra ; Josh Poimboeuf
> ; Andrea Arcangeli ;
> Woodhouse, David ; Andi Kleen ;
> Tim Chen ; Schaufler, Casey
>
> Cc:
26 matches
Mail list logo
