Received: by 10.223.176.46 with SMTP id f43csp1226724wra; Wed, 24 Jan 2018 12:47:55 -0800 (PST) X-Google-Smtp-Source: AH8x227gXd7ZUm3nDNG/xHPB8ck3kEzPSNZbzY1vhs8psP4bQZKhsNjWcUJ+7WLcyyJg9xaMieVd X-Received: by 2002:a17:902:9895:: with SMTP id s21-v6mr9089044plp.297.1516826875733; Wed, 24 Jan 2018 12:47:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516826875; cv=none; d=google.com; s=arc-20160816; b=CUrAMAVppaRCn6Mf6gONudEEUt2z9ZpXKvvEnNYzH+icHPZA2L7cFd4Fco0suiy4ED UlwYOd9MRspVZPaH/qyySjSNEwmK2ROOqXje3BSy1T8Y8Nwx7HmEoycdVe1vMkmTXNmr xQB8XDrVXbvAVNyW1/bKu9cxnKngwCUMWXVUlWLWaCNV+WOnkZW6s7iuG9vLFx8MnOwD 8dF5FOLTV642OrdhhB/0AvuTbUSfz+Ms1P/SiBk/KKHRUW+j6+eFo8cMO9guv++pcaHU 2eLxr6ZjFtd94Kshyu2S4YBqrjg432Fc+7PW7pvBh3DHUOv2rxzk981mEMwklnFN2Zg7 0zdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=1kyYasVzCewqfgD2BIzyfY2P4xMs65tKNhfdrrNPqQc=; b=aXkNkSBLNf7DxNJsuvb3NtwoRJ5m3BSQH+Q9bCxfMxhozMI2Enij0ahI++uo0gO0OR NVb5wxqK1F6nVQk9riwxPyIQoP+rAyol7z84puaIiDvlYWzvJVcOzpfgi8hXXDlBYdTa APumuLvVfTnMiyQpxpaP83pf/cNCi5G0bLppMNA4NUGCtWv+hV7IANmWSVqZeiZzWqjw ewBjx4OVtZVZW2fhuSdwauRYvmd2vKRfewstLqEETrry8JfJvLd4EHx9rA/ghE/lnGAt vuZm0AbXaIRRbPR5J6Yd8btigmXWimJxc3wjdzK/14gDJe7HBQfJPPK0LCEq5/leqdZW sviQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r63-v6si75175plb.788.2018.01.24.12.47.42; Wed, 24 Jan 2018 12:47:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932606AbeAXUrO (ORCPT + 99 others); Wed, 24 Jan 2018 15:47:14 -0500 Received: from www.llwyncelyn.cymru ([82.70.14.225]:36988 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932139AbeAXUrM (ORCPT ); Wed, 24 Jan 2018 15:47:12 -0500 Received: from alans-desktop (82-70-14-226.dsl.in-addr.zen.co.uk [82.70.14.226]) by fuzix.org (8.15.2/8.15.2) with ESMTP id w0OKkNxg015607; Wed, 24 Jan 2018 20:46:23 GMT Date: Wed, 24 Jan 2018 20:46:22 +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: <20180124204622.1f7b0de2@alans-desktop> In-Reply-To: <20180124190105.GA30107@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> 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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. Alan