From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x225xYA3q0re3r26uxvF4DYpXjbuD6pUjiNntfqU+nCznta7Glr2ygMbNHWq/ql9nWvrDc8We ARC-Seal: i=1; a=rsa-sha256; t=1516798096; cv=none; d=google.com; s=arc-20160816; b=wps+Bf+OoVUatHUDgMTQR40vlRDweNxrQ/CvmGv+SUeYvGKatrM10QADYMxsp5QoVK 2tzySBk44COWAT3+5rq/KF7Uj+tCNtWjeMHlbKz7OwUOGmd7rFUwvfeflmprfbLYbYPb CeiYs4pVzB+k0PcEYZAooXQWkx90kp7nmR9vFBoGP19DrpgKnDoYkBLQX1UyskFm82aY TMdFxaA6lk7+RHcU8WWgrd5I9Hl0PjKqHo7sxSI/ay0F6v955c0qyGxwsyDdTUcMqbTg SDRdTIN4SCOctL+qimufQcHgCtuQgV39ooKOiZ/LHaVwFhIUNoBMF2K1tcO3qeaV1PW6 oEwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:content-transfer-encoding:mime-version:references :in-reply-to:subject:cc:to:from:date:arc-authentication-results; bh=C6KLCqwqR1BPyRMtWg0vObGusV6FLGCfMYcUFOndXiA=; b=k8zJkaqL9rTkn+5RdQT1YokJIcxwgPIq/eMw2PMdpRQT+DwYGtQMcHIxhCfrV7Pkow yabLhqUG7FBYSeDtqry/NTE+newjpEhgYTvhIh1acYKyc+mp3gmWyNqnG12sbaH6ddPF aMxbjGfj0EaPorc2Ga6pbu5ifciI2opl9XBISFnn+dPsGBVvqgU1bSswd7+7wLUyy/0t 71dEXj/GW7ar3+r10VFUA27+9ZZGW6nUpw99gZqFTD4vcUI8l+sIKXmBfB6n8xK8+5th m9tE2Zxd1DcuIlUsWTl3G59xpiOPcReSxRvxmU+WNvih5Kh8FxtWn/rHFqumTkL1yZvv xAJw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of schwidefsky@de.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=schwidefsky@de.ibm.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of schwidefsky@de.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=schwidefsky@de.ibm.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Date: Wed, 24 Jan 2018 13:48:03 +0100 From: Martin Schwidefsky To: Pavel Machek Cc: Dominik Brodowski , linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, Heiko Carstens , Christian Borntraeger , Paolo Bonzini , Cornelia Huck , David Hildenbrand , Greg Kroah-Hartman , Jon Masters , Marcus Meissner , Jiri Kosina , w@1wt.eu, keescook@chromium.org, thomas.lendacky@amd.com, dwmw@amazon.co.uk, ak@linux.intel.com Subject: Re: Avoiding information leaks between users and between processes by default? [Was: : [PATCH 1/5] prctl: add PR_ISOLATE_BP process control] In-Reply-To: <20180124111552.GA24675@amd> References: <1516712825-2917-1-git-send-email-schwidefsky@de.ibm.com> <1516712825-2917-2-git-send-email-schwidefsky@de.ibm.com> <20180123170719.GA4154@isilmar-4.linta.de> <20180124072953.50851fec@mschwideX1> <20180124083705.GA14868@light.dominikbrodowski.net> <20180124111552.GA24675@amd> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-TM-AS-GCONF: 00 x-cbid: 18012412-0016-0000-0000-0000051B4C05 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18012412-0017-0000-0000-00002857D59B Message-Id: <20180124134803.3e11c6d6@mschwideX1> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-24_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1801240171 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590462291652474475?= X-GMAIL-MSGID: =?utf-8?q?1590478080208220027?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Wed, 24 Jan 2018 12:15:53 +0100 Pavel Machek wrote: > Hi! >=20 > On Wed 2018-01-24 09:37:05, Dominik Brodowski wrote: > > On Wed, Jan 24, 2018 at 07:29:53AM +0100, Martin Schwidefsky wrote: =20 > > > On Tue, 23 Jan 2018 18:07:19 +0100 > > > Dominik Brodowski wrote: > > > =20 > > > > On Tue, Jan 23, 2018 at 02:07:01PM +0100, Martin Schwidefsky wrote:= =20 > > > > > Add the PR_ISOLATE_BP operation to prctl. The effect of the proce= ss > > > > > control is to make all branch prediction entries created by the e= xecution > > > > > of the user space code of this task not applicable to kernel code= or the > > > > > code of any other task. =20 > > > >=20 > > > > What is the rationale for requiring a per-process *opt-in* for this= added > > > > protection? > > > >=20 > > > > For KPTI on x86, the exact opposite approach is being discussed (se= e, e.g. > > > > http://lkml.kernel.org/r/1515612500-14505-1-git-send-email-w@1wt.eu= ): By > > > > default, play it safe, with KPTI enabled. But for "trusted" process= es, one > > > > may opt out using prctrl. =20 > > >=20 > > > The rationale is that there are cases where you got code from *somewh= ere* > > > and want to run it in an isolated context. Think: a docker container = that > > > runs under KVM. But with spectre this is still not really safe. So you > > > include a wrapper program in the docker container to use the trap door > > > prctl to start the potential malicious program. Now you should be goo= d, no? =20 > >=20 > > Well, partly. It may be that s390 and its use cases are special -- but = as I > > understand it, this uapi question goes beyond this question: > >=20 > > To my understanding, Linux traditionally tried to aim for the security = goal > > of avoiding information leaks *between* users[+], probably even between > > processes of the same user. It wasn't a guarantee, and there always =20 >=20 > It used to be guarantee. It still is, on non-buggy CPUs. In a perfect world none of this would have ever happened. But reality begs to differ. > Leaks between users need to be prevented. >=20 > Leaks between one user should be prevented, too. There are various > ways to restrict the user these days, and for example sandboxed > chromium process should not be able to read my ~/.ssh. Interesting that you mention the use case of a sandboxed browser process. Why do you sandbox it in the first place? Because your do not trust it as it might download malicious java-script code which uses some form of attack to read the content of your ~/.ssh files. That is the use case for the new prctl, limit this piece of code you *identified* as untrusted. > can_ptrace() is closer to "can allow leaks between these two". Still > not quite there, as code might be running in process that > can_ptrace(), but the code has been audited by JIT or something not to > do syscalls. >=20 > > (and will be) information leaks -- and that is where additional safegua= rds > > such as seccomp come into play, which reduce the attack surface against > > unknown or unresolved security-related bugs. And everyone knew (or shou= ld > > have known) that allowing "untrusted" code to be run (be it by an user,= be > > it JavaScript, etc.) is more risky. But still, avoiding information lea= ks > > between users and between processes was (to my understanding) at least a > > goal.[=C2=A7] > >=20 > > In recent days however, the outlook on this issue seems to have shifted: > >=20 > > - Your proposal would mean to trust all userspace code, unless it is > > specifically marked as untrusted. As I understand it, this would mean= that > > by default, spectre isn't fully mitigated cross-user and cross-proces= s, > > though the kernel could. And rogue user-run code may make use of that, > > unless it is run with a special wrapper. =20 >=20 > Yeah, well, that proposal does not fly, then. =20 It does not fly as a solution for the general case if cross-process attacks. But for the special case where you can identify all of the potential untrus= ted code in your setup it should work just fine, no? --=20 blue skies, Martin. "Reality continues to ruin my life." - Calvin.