Received: by 10.213.65.68 with SMTP id h4csp502376imn; Sat, 17 Mar 2018 12:07:17 -0700 (PDT) X-Google-Smtp-Source: AG47ELtWx1oWWrcB4RDwZD4teW3LEdM8djZ/NC4WSOCGbqAggKSoBAiD+ed14sD7+FQiJhMnYT6S X-Received: by 10.99.97.203 with SMTP id v194mr4912131pgb.373.1521313637209; Sat, 17 Mar 2018 12:07:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521313637; cv=none; d=google.com; s=arc-20160816; b=ySTJAKUPGToVYUiUZE9ksJe1R1axzgSoV6oXH6HmLIokReETNtQ9ZykUwfkQGRTn4u J89dZW+AfeJaD5iOLUGNVrlWNjiU3QRdojiOZstYrRioBR3jfd+Dg7RjR/sJ4X86bvsl maabyiujptNLFjFWfUqUSuUNOifNSqaJ76y6eQfbatHMvgPuVtyri4fITNDQVR4PhTrf NS7yxHTaE3arEYroqqmPafHelgz9jKewfuT7a1CMtzeOH80LpNg2nf3WZW1T3LBsuF4g zoc6WCPNxk5QQMdxIS5ufemcnf9tMQW4uOkMkxQkyU5NxbCzQYS5BRlbN6ZgyIjJUW36 nfAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=VL2OvsUP4ff3tk4rwZTOUuRfq8MRQ4GNgzRubxW1vvw=; b=ecMn7VY9d0QsmWw9BNrwh3uBLV+mj/rinvK9hlfiOPgUXXe1eLT/VPNg8GLMYAnV3/ 50f+KfRkMKqp5SutCsbunTjG7Dh8LIwELcHTPxZ5o3CZCOr1FUHJmD3HLPHr+WsiQWgS gMCMzdKMDW5Tgth8ccoQlvC+4tKjxNyoQBlx4PnSK0zUgLKc0I0YyjK8s7eXZeJfz21m u1UxizyhHI/PdOd0uMSusZKhQnYYKI5NRhPAgFgp8vSgHAWZJFnwateUJpLmQZoFq/MX aLtkKeclz8NO2MwzGbXYpfzbtxpdkUzPUcWlo+Q1uBtj0YgwM2cY8nsEAvTiIxo0SFs8 YLtg== 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 61-v6si8629527plf.640.2018.03.17.12.07.03; Sat, 17 Mar 2018 12:07:17 -0700 (PDT) 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 S1753907AbeCQTFY (ORCPT + 99 others); Sat, 17 Mar 2018 15:05:24 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:57956 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753847AbeCQTFW (ORCPT ); Sat, 17 Mar 2018 15:05:22 -0400 Received: from p4fea5f09.dip0.t-ipconnect.de ([79.234.95.9] helo=nanos.glx-home) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1exH8j-0001gO-C3; Sat, 17 Mar 2018 20:05:13 +0100 Date: Sat, 17 Mar 2018 20:05:12 +0100 (CET) From: Thomas Gleixner To: Dave Hansen cc: Dave Hansen , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxram@us.ibm.com, mpe@ellerman.id.au, mingo@kernel.org, akpm@linux-foundation.org, shuah@kernel.org Subject: Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0 In-Reply-To: <6e0c687d-f465-5433-10be-db04489278a9@intel.com> Message-ID: References: <20180316214654.895E24EC@viggo.jf.intel.com> <20180316214656.0E059008@viggo.jf.intel.com> <6e0c687d-f465-5433-10be-db04489278a9@intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 17 Mar 2018, Dave Hansen wrote: > On 03/17/2018 02:12 AM, Thomas Gleixner wrote: > >> This is a bit nicer than what Ram proposed because it is simpler > >> and removes special-casing for pkey 0. On the other hand, it does > >> allow applciations to pkey_free() pkey-0, but that's just a silly > >> thing to do, so we are not going to protect against it. > > What's the consequence of that? Application crashing and burning itself or > > something more subtle? > > You would have to: > > pkey_free(0) > ... later > new_key = pkey_alloc(); > // now new_key=0 > pkey_deny_access(new_key); // or whatever > > At which point most apps would probably croak because its stack is > inaccessible. The free itself does not make the key inaccessible, *but* > we could also do that within the existing ABI if we want. I think I > called out that behavior as undefined in the manpage. As long as its documented and the change only allows people to shoot them more in the foot, we're all good. Thanks, tglx