Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp721128pxj; Fri, 11 Jun 2021 09:46:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyo5RNlE95z1g9XxVP+SR5RUZCdSnUFyov6eOWEn2Dn9bRD2SzGKRnk4gWF4kxlU9/3cUXd X-Received: by 2002:a17:906:4d56:: with SMTP id b22mr4367736ejv.78.1623429999635; Fri, 11 Jun 2021 09:46:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623429999; cv=none; d=google.com; s=arc-20160816; b=gnV0DAHuukfFYxWCoXdmkKi4m8qjphC2u/K8m9j6nhCW8rWYlR7mLTQYqN2mu8fPiJ RYBc5AqiL/gQP2gDWkfHeNCDwAE6ocBncinoSqTOPcvkKRFr6Ebe3YvEUCjf9QJEykDi NBVacCTY0phOnNZ1FIj/bNUmJxkBVC8kOo260l8IVvdOWQkMZH8qL/sHz/LNaUZvCs6W ng8qKh3XkdCs94jPqTZaHtpBCbU4gQl0sNAtb9wZLNQOfjOCkTvv49C2f3TNvvVpb6Jb 81p/WIe8K2wMjngO6DyYX9ppm437qsXaPhvt1oBJb6JCILECrbALy/zIKw/Eci+kbCVg uXtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:in-reply-to:references:date:from:cc :to:subject:ironport-sdr:ironport-sdr; bh=S7SNXHDRhpjT/fgmq11xRiC8/0MI2IZ1evJFVjyvQQM=; b=nK36D2RZbANMisFKfFtcW06Ys9P05FXO3MSRsckTTZ1Dj2N+aUofvCq4xR6XRn8167 uOuFS8Jb2TMJAU2oe8upz5MYtQQUOpRM7Q0uXbB199MZ7XUYXUWOoSMgpIP7WTaKRqvE O5xUFjOancgqPQJ8f9xLff6Hfp6JSee52DTaGh/VshLrS2FfoMpjvBbwts5eZ04dgF/g 5OR7/PZpzDkRJ6uqVBaLdkY7+8PLrL2TYYq0ycYk9aRz8Q7icqPWoC3RG0VVSvjMZZBy T5OG//xZvisUZEv4bfDlzbmhZkmiiNvqt7BnOqNMs9KzcUgKU3dvfAJ1QuUJk6VQCViC 1HCA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m17si5650354ejn.202.2021.06.11.09.46.16; Fri, 11 Jun 2021 09:46:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231193AbhFKQoD (ORCPT + 99 others); Fri, 11 Jun 2021 12:44:03 -0400 Received: from mga17.intel.com ([192.55.52.151]:30442 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231166AbhFKQoA (ORCPT ); Fri, 11 Jun 2021 12:44:00 -0400 IronPort-SDR: gUb3Hl7rcA/3BNKAoNGkPfMF51AeE/w1T5MDsI33yNXejD9h9JMQXWHzqCRz7fj2DLY9NBcgXA Fiu8u8ec0y0Q== X-IronPort-AV: E=McAfee;i="6200,9189,10012"; a="185935766" X-IronPort-AV: E=Sophos;i="5.83,265,1616482800"; d="scan'208";a="185935766" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jun 2021 09:42:01 -0700 IronPort-SDR: wRPaDX1gGG8fOu6fJr+Iegl09SZ7B5jfVlVexaS3j0Vgf2plRYPCHLwQDi6zEETFVW7BHWpFGP pIIiago9GOCg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.83,265,1616482800"; d="scan'208";a="620429251" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.77.144]) by orsmga005.jf.intel.com with ESMTP; 11 Jun 2021 09:42:00 -0700 Subject: [PATCH 3/4] selftests/vm/pkeys: Refill shadow register after implicit kernel write To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Dave Hansen , tglx@linutronix.de, linuxram@us.ibm.com, sandipan@linux.ibm.com, akpm@linux-foundation.org, fweimer@redhat.com, desnesn@linux.vnet.ibm.com, mingo@kernel.org, bauerman@linux.ibm.com, aneesh.kumar@linux.ibm.com, mpe@ellerman.id.au, mhocko@kernel.org, msuchanek@suse.de, shuah@kernel.org, x86@kernel.org From: Dave Hansen Date: Fri, 11 Jun 2021 09:42:00 -0700 References: <20210611164153.91B76FB8@viggo.jf.intel.com> In-Reply-To: <20210611164153.91B76FB8@viggo.jf.intel.com> Message-Id: <20210611164200.EF76AB73@viggo.jf.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Dave Hansen The pkey test code keeps a "shadow" of the pkey register around. This ensures that any bugs which might write to the register can be caught more quickly. Generally, userspace has a good idea when the kernel is going to write to the register. For instance, alloc_pkey() is passed a permission mask. The caller of alloc_pkey() can update the shadow based on the return value and the mask. But, the kernel can also modify the pkey register in a more sneaky way. For mprotect(PROT_EXEC) mappings, the kernel will allocate a pkey and write the pkey register to create an execute-only mapping. The kernel never tells userspace what key it uses for this. This can cause the test to fail with messages like: protection_keys_64.2: pkey-helpers.h:132: _read_pkey_reg: Assertion `pkey_reg == shadow_pkey_reg' failed. because the shadow was not updated with the new kernel-set value. Forcibly update the shadow value immediately after an mprotect(). Fixes: 6af17cf89e99 ("x86/pkeys/selftests: Add PROT_EXEC test") Signed-off-by: Dave Hansen Signed-off-by: Thomas Gleixner Cc: Ram Pai Cc: Sandipan Das Cc: Andrew Morton Cc: Florian Weimer Cc: "Desnes A. Nunes do Rosario" Cc: Ingo Molnar Cc: Thiago Jung Bauermann Cc: "Aneesh Kumar K.V" Cc: Michael Ellerman Cc: Michal Hocko Cc: Michal Suchanek Cc: Shuah Khan Cc: x86@kernel.org --- b/tools/testing/selftests/vm/protection_keys.c | 7 +++++++ 1 file changed, 7 insertions(+) diff -puN tools/testing/selftests/vm/protection_keys.c~selftests_vm_pkeys_Refill_shadow_register_after_implict_kernel_write-1 tools/testing/selftests/vm/protection_keys.c --- a/tools/testing/selftests/vm/protection_keys.c~selftests_vm_pkeys_Refill_shadow_register_after_implict_kernel_write-1 2021-06-11 09:41:33.508468061 -0700 +++ b/tools/testing/selftests/vm/protection_keys.c 2021-06-11 09:41:33.517468061 -0700 @@ -1448,6 +1448,13 @@ void test_implicit_mprotect_exec_only_me ret = mprotect(p1, PAGE_SIZE, PROT_EXEC); pkey_assert(!ret); + /* + * Reset the shadow, assuming that the above mprotect() + * correctly changed PKRU, but to an unknown value since + * the actual alllocated pkey is unknown. + */ + shadow_pkey_reg = __read_pkey_reg(); + dprintf2("pkey_reg: %016llx\n", read_pkey_reg()); /* Make sure this is an *instruction* fault */ _