From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x2257t31+5qlj/yEaP+Nt8DmL5BRMMllUJ7Y4VRdsb/XKQi97SSFcOxx5gw8oKgAPVu/4/ers ARC-Seal: i=1; a=rsa-sha256; t=1517256790; cv=none; d=google.com; s=arc-20160816; b=c3wPFRJTMkNc3XOmHJZR6T88lvFbmA3S4kvbkjQaZJvkFcX/kp+eFvozgbWzmAP9+e jXFaAgu0HE71Qk7e+II078aRgKgEv3P1Hn4b8sRB1rMKnaW7Xbn3I7NcmAMA53OPUSnA sjkC7G+noHcWmMagx6lbolTapaXgHqzDieGv5GcgXJTOdWnYIZGXW03GKHGtsmB5H0kM iqyBiNmloXHBtdoGzHw9ww2yRrgze4neXWmPmdRA/UE9pKtGD0+GQc0aGR+jCeVqISWn qFBSfNdhK+VohkRwPzCUsNSJ4keuqZKxlCGBnZ+RUYF3eq/elYNIqESCdAsbRsdgxZB9 HLGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=VhOOaASG2bVx4dNiHghS72toyh+B1T1oCCZl/DCQPhk=; b=SAjwkg7PB4bRPhVUrQTlOGCTojKsXeHhQNn0PVrqX9xaUcO2FNt6SEK3J1HJJtKBha 2qyKjPIhwe5azZGzsSP5PfxW9KAkSRhI/DVUSYzzTEWpxCeIEPqR4AV5XBLnd/r8O0MY b/R+FYcisqULqPaDd53ow+l2tnWTJ245MpMqbPBZQXQMrGxvGlH7TcIVTjRLqUxbwoRw qqhIwP6Su73nn6AZRas9Pf8t4jr4t6LiCwo7oYYJjTzGQ2RDMcImMXIw27a22+7lNpsx phB+IxKO4cdbr0YFGzxzaiBxXJ27kNMBLxlwMiiV3tTxWgE5OBHm7qRCK/00gGe9YXEy cwAg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of gnomes@lxorguk.ukuu.org.uk designates 82.70.14.225 as permitted sender) smtp.mailfrom=gnomes@lxorguk.ukuu.org.uk Authentication-Results: mx.google.com; spf=pass (google.com: domain of gnomes@lxorguk.ukuu.org.uk designates 82.70.14.225 as permitted sender) smtp.mailfrom=gnomes@lxorguk.ukuu.org.uk Date: Mon, 29 Jan 2018 20:12:31 +0000 From: Alan Cox To: Pavel Machek Cc: Martin Schwidefsky , 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] Message-ID: <20180129201231.4ebec569@alans-desktop> In-Reply-To: <20180129131446.GB4669@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> <20180124134803.3e11c6d6@mschwideX1> <20180124190105.GA30107@amd> <20180124204622.1f7b0de2@alans-desktop> <20180129131446.GB4669@amd> Organization: Intel Corporation X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590462291652474475?= X-GMAIL-MSGID: =?utf-8?q?1590959056007899929?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Mon, 29 Jan 2018 14:14:46 +0100 Pavel Machek wrote: > On Wed 2018-01-24 20:46:22, Alan Cox wrote: > > > Anyway, no need to add prctl(), if A can ptrace B and B can ptrace A, > > > leaking info between them should not be a big deal. You can probably > > > find existing macros doing neccessary checks. > > > > Until one of them is security managed so it shouldn't be able to ptrace > > the other, or (and this is the nasty one) when a process is executing > > code it wants to protect from the rest of the same process (eg an > > untrusted jvm, javascript or probably nastiest of all webassembly) > > > > We don't need a prctl for trusted/untrusted IMHO but we do eventually > > need to think about API's for "this lot is me but I don't trust > > it" (flatpack, docker, etc) and for what JIT engines need to do. > > Agreed. > > And yes, JITs are interesting, and given the latest > rowhammer/sidechannel attacks, something we may want to limit in > future... > > It sounds nice on paper but is just risky. I don't think java, javascript, webassembly, (and for some implementations truetype, pdf, postscript, ... and more) are going away in a hurry. Alan