From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx2.suse.de ([195.135.220.15]) by Galois.linutronix.de with esmtps (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1fEDlR-0000vY-2w for speck@linutronix.de; Thu, 03 May 2018 14:55:16 +0200 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 52A58ACB8 for ; Thu, 3 May 2018 12:55:07 +0000 (UTC) Date: Thu, 3 May 2018 14:55:02 +0200 (CEST) From: Jiri Kosina Subject: [MODERATED] Re: [PATCH v2] Linux Patch 1/1 In-Reply-To: Message-ID: References: <92c45587-5eb3-2421-6fc1-42e74a715e30@linux.intel.com> <20180427164743.GA14180@pd.tnic> <6e2b14fc-3bf6-071d-6ce2-e518f2c4f069@redhat.com> <20180427173221.GB14180@pd.tnic> <20180427180944.GD75137@tassilo.jf.intel.com> <2de93c45-9bcc-136d-3534-03d05bd6b660@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, 27 Apr 2018, speck for Linus Torvalds wrote: > So it's kernel exit I'd worry about, where a kernel store that is (still) > in the store buffers can be incorrectly seen by user space because the > store buffer load forwarding doesn't do any permission checking at all. > > I'm assuming nobody has _that_ bug. But it might be worth asking around. > > Linus > > PS. The real kernel worry wrt the store buffer bypass is obviously ebpf, > not kernel entry/exit. Well but in principle ebpf makes just the whole thing easier, as the attacker can freely construct fine-grained load+store gadget instead of having to find it in the code. We've identified numberous spectre v1 gadgets already present in the kernel, I don't really see how this is different in *principle* ("only" you need load+store, instead of v1's load+load). So JITed code is more of a concern because it allows for creating the gadget instead to having to actively find it in the existing code, but I fail to see how this is not an issue of userspace being able to read all of kernel's memory (either by using explicitly ebpf-instrumented gadget, or simply finding one in the existing code). So I still believe we need to protect kernel as well, and prctl()-based aproach doesn't work for that. So ... how does current patchset even deal with the ebpf scenario? I'd be glad to be enlightened and proven wrong. Thanks, -- Jiri Kosina SUSE Labs