From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A5F1CA9EC3 for ; Tue, 29 Oct 2019 17:37:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4BAAA20679 for ; Tue, 29 Oct 2019 17:37:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4BAAA20679 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F02366B0005; Tue, 29 Oct 2019 13:37:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB38E6B0006; Tue, 29 Oct 2019 13:37:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DC8876B000C; Tue, 29 Oct 2019 13:37:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id B49EE6B0005 for ; Tue, 29 Oct 2019 13:37:20 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 609718249980 for ; Tue, 29 Oct 2019 17:37:20 +0000 (UTC) X-FDA: 76097528640.22.blade76_5d144500d8b46 X-HE-Tag: blade76_5d144500d8b46 X-Filterd-Recvd-Size: 4666 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Tue, 29 Oct 2019 17:37:19 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Oct 2019 10:37:18 -0700 X-IronPort-AV: E=Sophos;i="5.68,244,1569308400"; d="scan'208";a="193678661" Received: from acox1-desk1.ger.corp.intel.com ([10.251.81.197]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Oct 2019 10:37:13 -0700 Message-ID: <57f25261400464ea58b65bf39ca1b4f89eea2ce2.camel@linux.intel.com> Subject: Re: [PATCH RFC] mm: add MAP_EXCLUSIVE to create exclusive user mappings From: Alan Cox To: Andy Lutomirski , "Reshetova, Elena" Cc: Mike Rapoport , "linux-kernel@vger.kernel.org" , Alexey Dobriyan , Andrew Morton , Arnd Bergmann , Borislav Petkov , Dave Hansen , James Bottomley , Peter Zijlstra , Steven Rostedt , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "linux-api@vger.kernel.org" , "linux-mm@kvack.org" , "x86@kernel.org" , Mike Rapoport , Tycho Andersen Date: Tue, 29 Oct 2019 17:37:10 +0000 In-Reply-To: References: <1572171452-7958-1-git-send-email-rppt@kernel.org> <2236FBA76BA1254E88B949DDB74E612BA4EEC0CE@IRSMSX102.ger.corp.intel.com> Organization: Intel Corporation Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 (3.32.4-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > Doing all of this with MAP_SECRET seems bad to me. If user code > wants > UC memory, it should ask for UC memory -- having the kernel involved > in the decision to use UC memory is a bad idea, because the > performance impact of using UC memory where user code wasn't > expecting The user has no idea that they want UC memory. It varies by platform what this means. There are some systems (eg in order uclinux devices, M68K, old atoms) for which it probably means 'no-op', there are those where UC helps, those it hinders, there are those where WC is probably sufficient. There are platforms where 'secret' memory might best be implemented by using on die memory pools or cache locking. It might even mean 'put me in a non HT cgroup'. Secret might also mean 'not accessible by thunderbolt', or 'do not swap unless swap is encrypted' and other things. IMHO the question is what is the actual semantic here. What are you asking for ? Does it mean "at any cost", what does it guarantee (100% or statistically), what level of guarantee is acceptable, what level is -EOPNOTSUPP or similar ? I'm also wary of the focus always being on keys. If you decrypt a file I'm probably just as interested in the contents so can I mmap a file this way and if so what happens on the unmap. Yes key theft lets me do all sorts of theoretical long term bad stuff, but frequently data theft is sufficient to do lots of practical short term bad stuff. Also as an attacker I'm probably a script, and I don't want to be exposing my master long term because they want the footprints gone. > in gnome-shell. The system slowed down to such an extent that I was > unable to enter the three or so keystrokes to turn it back off.) Yes - and any uncached pages also need to be kept away from anything that the kernel touches under locks, or use in atomic user operations stuff. Copy on write of an uncached page for example is suddenly really slow and there are so many other cases we'd have to find and deal with. > EXCLUSIVE makes sense. Saying "don't ptrace this" makes sense. UC > makes sense. But having one flag to rule them all does not make > sense > to me. We already support not ptracing, and if I can ptrace any of the code I can access all of its code/data so that one isn't hard and the LSM interfaces can do it. That one is easy - minus the fact that malware writers are big fans of anything that stops tracing... Alan