Messages in this thread | | | Subject | Re: [PATCH] x86/speculation: Use Indirect Branch Prediction Barrier in context switch | From | Tim Chen <> | Date | Wed, 31 Jan 2018 15:25:44 -0800 |
| |
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 +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. > > I don't want other users reading my applications' memory. > > I don't want other containers reading my containers' memory. > > I don't want *any* user tasks reading root daemons' memory. > > Those are not unreasonable expectations. > > So now I have to go and modify all my containers and applications to set > PR_SET_DUMPABLE? That seems highly impractical and unlikely. > > Plus, I happen to *like* core dumps. > > The other option is to rebuild the entire userland with retpolines, but > again, that would make this patch completely pointless. > >>> [ 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. > > Is that why the ptrace approach was abandoned? Surely that's a solvable > problem? We have some smart people on lkml. And anyway I didn't see it > discussed anywhere. In the worst case we could just always do IBPB when > switching between kernel and user tasks. >
I think dumpable is not the end all policy. It is a reasonable starting point to provide us a means to secure the most sensitive processes without IBPBing the world. It is on the performance end of the security/performance trade off.
For people who opt for more security, it is reasonable to consider alternate policies to distinguish friend and foe so we know if we are coming from a potentially hostile environment. Ptrace is one means to do so, and probably there are other ways depending on usages. I hope we can have a discussion on what we should use to determine if two processes are friend or foe. Say do all the processes from the same containers are considered friends with each other? I think once we have this decided, actually putting in IBPB will simple.
Tim
| |