All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Chen <tim.c.chen@linux.intel.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>,
	David Woodhouse <dwmw@amazon.co.uk>
Cc: arjan@linux.intel.com, tglx@linutronix.de, karahmed@amazon.de,
	x86@kernel.org, linux-kernel@vger.kernel.org, bp@alien8.de,
	peterz@infradead.org, pbonzini@redhat.com, ak@linux.intel.com,
	torvalds@linux-foundation.org, gregkh@linux-foundation.org,
	mingo@kernel.org, luto@kernel.org, linux@dominikbrodowski.net
Subject: Re: [PATCH] x86/speculation: Use Indirect Branch Prediction Barrier in context switch
Date: Tue, 30 Jan 2018 13:23:17 -0800	[thread overview]
Message-ID: <d4d8111b-5758-7541-cc30-b11d6b4d6bec@linux.intel.com> (raw)
In-Reply-To: <20180130174850.bwypk4r5yn2344jb@treble>

On 01/30/2018 09:48 AM, Josh Poimboeuf wrote:
> On Mon, Jan 29, 2018 at 10:04:47PM +0000, David Woodhouse wrote:
>> From: Tim Chen <tim.c.chen@linux.intel.com>
>>
>> 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 point of this patch is.  An audit of my laptop shows
> only a single user of PR_SET_DUMPABLE: systemd-coredump.

This is an opt in approach.  For processes who need extra
security, it set itself as non-dumpable.  Then it can
ensure that it doesn't see any poisoned BTB.  

> 
> [ And yes, I have gpg-agent running.  Also, a grep of the gnupg source
> doesn't show any evidence of it being used there.  So the gpg thing
> seems to be a myth. ]

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.

> 
> But also, I much preferred the original version of the patch which only
> skipped IBPB when 'prev' could ptrace 'next'.

For the A->kernel thread->B scenario, you will need context of A
to decide if you need IBPB when switching to B.  You need to
worry about whether the context of A has been released ... etc if
you want to use ptrace.

> 
> If performance is a concern, let's look at that in more detail.  But I
> don't see how the solution to a performance issue could possibly be
> "leave (almost) all tasks vulnerable by default."
> 

Thanks.

Tim

  reply	other threads:[~2018-01-30 21:23 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-29 22:04 [PATCH] x86/speculation: Use Indirect Branch Prediction Barrier in context switch David Woodhouse
2018-01-30 17:48 ` Josh Poimboeuf
2018-01-30 21:23   ` Tim Chen [this message]
2018-01-30 22:00     ` Borislav Petkov
2018-01-30 22:21       ` Thomas Gleixner
2018-01-30 22:55         ` Borislav Petkov
2018-01-31  3:59     ` Josh Poimboeuf
2018-01-31 23:25       ` Tim Chen
2018-01-30 20:38 ` Borislav Petkov
2018-01-30 21:03   ` Tim Chen
2018-01-30 21:57     ` Borislav Petkov
2018-01-30 22:26       ` Tim Chen
2018-01-30 22:43         ` Borislav Petkov
2018-01-31  0:25           ` Tim Chen
2018-01-31  0:41             ` Borislav Petkov
2018-01-30 22:39 ` [tip:x86/pti] " tip-bot for Tim Chen
2018-01-31  7:03   ` Dominik Brodowski
2018-01-31 13:24     ` Josh Poimboeuf
2018-02-01  8:25     ` Christian Brauner
2018-02-01  8:31     ` David Woodhouse
2018-02-01 15:40       ` Josh Poimboeuf
2018-02-04 19:39       ` Dominik Brodowski
2018-02-05 14:18   ` David Woodhouse
2018-02-05 19:35     ` Tim Chen
2018-02-05 19:35       ` Tim Chen
  -- strict thread matches above, loose matches on Subject: below --
2018-01-29 11:33 [PATCH] " David Woodhouse
2018-01-29 12:28 ` Dominik Brodowski
2018-01-29 12:44   ` David Woodhouse
2018-01-29 13:56     ` Dominik Brodowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d4d8111b-5758-7541-cc30-b11d6b4d6bec@linux.intel.com \
    --to=tim.c.chen@linux.intel.com \
    --cc=ak@linux.intel.com \
    --cc=arjan@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dwmw@amazon.co.uk \
    --cc=gregkh@linux-foundation.org \
    --cc=jpoimboe@redhat.com \
    --cc=karahmed@amazon.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.