From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x225rB6g6kK+YyjRLt32ANV2DO+NG2q9g+XNuyVlelMudgSIfcAWWfGsu9coXjIrSMsTe6BSe ARC-Seal: i=1; a=rsa-sha256; t=1516775775; cv=none; d=google.com; s=arc-20160816; b=xypmBqPtTGvUeu8QpCaStpUVPefKexThFkbzCNHyV3j4zT4gzJG39hdhsFt8m6OUze fgo5bwhN7H1YgMNclvJv2wa7dlBRkIKAk01wmXOXj2176RtwNbykurK3ciAjrOBQz4lu LiJ+4VWfyJP1x4L6a4u5XqlgtZe96ktZ9EVAhd2F/vvzAqJCLQ+Js/eMjMTnV9HOrUdi 07obYGbyRJX3b0n0bU+GZWFvO7KXbf5F3N+m7pGJAmKC8na2ZmiYM0GXZzVb8+Txumak 1+ZXpO6i/6eFuRSyJmKUVcxuNQ1fDRDB9mafbEX22FAZU71wLKo6MWgR2fQQBy2yzqJx 31WQ== 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=jfH3FPWUdLz+ScpnDu5nYvKKAYT0gYhKn5H82mlIdkg=; b=KpP5gSktWp8aSih1ILDJ35n/qXH0nxt7G61f3t194E9NY9CuMf0q1dXCm5LXauwFV9 JF+3596M2VFChNytZlTWLhmDnWMQlbtCILCiK8kw0uZIp2Auwt17Z83g/G+Be4z4dmO8 5rsNjLeEQXSeAAVFk+Z/40sEdqAFV3QgAVkI8vXgzwFLGBNZZ8CbqtPZaxwiquY1YNAV 9hrh0lm4v8Huu+b5QT12cgvUEwctiDkgK4tZ+FvlUncomql5kWHEYv4m4SM4I2yGCKMZ xQwR3lyeNB6LSLjvVPXmh4bRkU3CYOLsSS5OJnHoCS3dc1WxglktGmMgf9OfGZYBCIXO TuHg== 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 07:36:05 +0100 From: Martin Schwidefsky To: Radim =?UTF-8?B?S3LEjW3DocWZ?= Cc: Christian Borntraeger , kvm@vger.kernel.org, Paolo Bonzini , linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, Heiko Carstens , Cornelia Huck , David Hildenbrand , Greg Kroah-Hartman , Jon Masters , Marcus Meissner , Jiri Kosina Subject: Re: [PATCH 4/5] s390: define ISOLATE_BP to run tasks with modified branch prediction In-Reply-To: <20180123203223.GA648@flask> References: <1516712825-2917-1-git-send-email-schwidefsky@de.ibm.com> <1516712825-2917-5-git-send-email-schwidefsky@de.ibm.com> <20180123203223.GA648@flask> 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: 18012406-0008-0000-0000-000004C53188 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18012406-0009-0000-0000-00001E58B345 Message-Id: <20180124073605.494aceb8@mschwideX1> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-24_03:,, 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-1801240087 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590388681708887133?= X-GMAIL-MSGID: =?utf-8?q?1590454676176878974?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Tue, 23 Jan 2018 21:32:24 +0100 Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > 2018-01-23 15:21+0100, Christian Borntraeger: > > Paolo, Radim, > >=20 > > this patch not only allows to isolate a userspace process, it also allo= ws us > > to add a new interface for KVM that would allow us to isolate a KVM gue= st CPU > > to no longer being able to inject branches in any host or other guests= . (while > > at the same time QEMU and host kernel can run with full power).=20 > > We just have to set the TIF bit TIF_ISOLATE_BP_GUEST for the thread tha= t runs a > > given CPU. This would certainly be an addon patch on top of this patch = at a later > > point in time. =20 >=20 > I think that the default should be secure, so userspace will be > breaking the isolation instead of setting it up and having just one > place to screw up would be better -- the prctl could decide which > isolation mode to pick. The prctl is one direction only. Once a task is "secured" there is no way b= ack. If we start with a default of secure then *all* tasks will run with limited branch prediction. > Maybe we can change the conditions and break logical connection between > TIF_ISOLATE_BP and TIF_ISOLATE_BP_GUEST, to make a separate KVM > interface useful. The thinking here is that you use TIF_ISOLATE_BP to make use space secure, but you need to close the loophole that you can use a KVM guest to get out = of the secured mode. That is why you need to run the guest with isolated BP if TIF_ISOLATE_BP is set. But if you want to run qemu as always and only the KVM guest with isolataed BP you need a second bit, thus TIF_ISOLATE_GUEST_B= P. > > Do you think something similar would be useful for other architectures = as well? =20 >=20 > It goes against my idea of virtualization, but there probably are users > that don't care about isolation and still use virtual machines ... > I expect most architectures to have a fairly similar resolution of > branch prediction leaks, so the idea should be easily abstractable on > all levels. (At least x86 is.) Yes. > > In that case we should try to come up with a cross-architecture interfa= ce to enable > > that. =20 >=20 > Makes me think of a generic VM control "prefer performance over > security", which would also take care of future problems and let arches > decide what is worth the code. VM as in virtual machine or VM as in virtual memory? > A main drawback is that this will introduce dynamic branches to the > code, which are going to slow down the common case to speed up a niche. Where would you place these additional branches? I don't quite get the idea. --=20 blue skies, Martin. "Reality continues to ruin my life." - Calvin.