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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52BCCC61DA4 for ; Mon, 13 Mar 2023 23:24:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69BFD6B0072; Mon, 13 Mar 2023 19:24:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 624306B0074; Mon, 13 Mar 2023 19:24:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49DFC6B0075; Mon, 13 Mar 2023 19:24:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 333116B0072 for ; Mon, 13 Mar 2023 19:24:43 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id F367840946 for ; Mon, 13 Mar 2023 23:24:42 +0000 (UTC) X-FDA: 80565456804.05.6B0C7EC Received: from mail-oa1-f49.google.com (mail-oa1-f49.google.com [209.85.160.49]) by imf11.hostedemail.com (Postfix) with ESMTP id 36F2840009 for ; Mon, 13 Mar 2023 23:24:39 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=JKiQ9Hle; spf=pass (imf11.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.49 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678749880; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8Sq6Zfx9QgmkasrlAIB3H1ERtzMXxAb05lrA4qH+HgA=; b=1W1GLUIkPIO1JMGNNKkM2kiX/OglPLMloctGKnKePkXACydDZe6BhZUuBPGJ/7P0aA1veK TOVypVTuhJ+/Gvj2v94qxbQgDcnKs/EcnCcne3aIFg437WhjiWGBE3TngHbayfdUxwUmKp b7JmawrkSnKVKGoPGKEyKXDJaty6jl8= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=JKiQ9Hle; spf=pass (imf11.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.49 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678749880; a=rsa-sha256; cv=none; b=VD/IGDb5kNzUQyl2hrcgVuoykgqHzPDNqPYegmHuLlOajVNStoTBiLptjm/QhtOnjC4vuZ /DC88DC1zjgFlcRjjymtVoi28Fx7wlYnKBKwfJHZpnjbos3qLDUwX+y8ULjNddnWnm/ylg viaKmB6CEINX25FSPT2/b9JhbLhTrW4= Received: by mail-oa1-f49.google.com with SMTP id 586e51a60fabf-17786581fe1so8190599fac.10 for ; Mon, 13 Mar 2023 16:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1678749879; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8Sq6Zfx9QgmkasrlAIB3H1ERtzMXxAb05lrA4qH+HgA=; b=JKiQ9HleViAfVIuV4RzzGKHSRLKLyJx8o75RdpgJWBEGFZfBJuzGLtEPDrVSu9AXFo 31L0QzBmipgasF5YTx2d5Q0r0gZYqZ254/b3vhIJI+gdsTu5nQsl4/30BofXnuXCxDVK N8cUthx9ouwfjB+uYhgiHqLJlxIWRuSY0DSy0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678749879; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8Sq6Zfx9QgmkasrlAIB3H1ERtzMXxAb05lrA4qH+HgA=; b=RpIjb1KOKkvg2jXvQZ/OBzDVMwqGJOuA4CAp+u68l8BpaSonLhqkxAQ7T7d/t1QMDU 5XURZ5RV9Qgi1YmBouorIrwbA1l8+9aPr0J6HzYaG30q2h0n52tWVXk5KBc8IpXO0LHF H4z8CRVKAMPqgM8Y/ltMo0iglIRFq5xVN21Fd5rpFl3vNiEghEXZ9oXR+bV5QlQwtH/X Aha3j73kHf9eiAd6XF5S51U60nlrblyZ61C26X5T2bycd/uEG9Dc5Xgf0Yt7HhbQAVij kYOcEIzdp3z3uzlZBE37jM3594cFGlCXex6/H7Q58XBex+X3FNvhzwBy3asQJAtfDKHR gVdg== X-Gm-Message-State: AO0yUKU51k6B13NUL8rPKq1lYPxqe3T0sBIYK4rADcuza5jtl5OQAtkq B/3cL8lZlpdXMKbKGFSHrKDdtxXJi8aVZ6gx62RH7Q== X-Google-Smtp-Source: AK7set9Q+jXXOJDzoxe6gt5t/r9jY/DnGFxQ6kWGpf/eRNjgYnkdj6Mrx4YoniGB644JAuVMt0Kqv5lJzUPNQh/o6Ec= X-Received: by 2002:a05:6870:5147:b0:177:b9c0:bcba with SMTP id z7-20020a056870514700b00177b9c0bcbamr2107403oak.3.1678749879193; Mon, 13 Mar 2023 16:24:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeff Xu Date: Mon, 13 Mar 2023 16:24:27 -0700 Message-ID: Subject: Re: x86/pkeys in early kernel version To: Kyle Huey Cc: Dave Hansen , linux-mm@kvack.org, =?UTF-8?Q?Stephen_R=C3=B6ttger?= , "tglx@linutronix.de" , Jorge Lucangeli Obes , Kees Cook , Guenter Roeck Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 36F2840009 X-Stat-Signature: bc7n6z6bzu7pmj3a9br8ooj4jx1f5jni X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1678749879-990405 X-HE-Meta: U2FsdGVkX1+eNd1nTcvk0mKpqfODkpxGtVDABkUzY1BaVygXuFxQpv+67fbPlgcbgI/CZBuRGcaq4MwV36YjJRh/wAZwD92Mp9nToZYrQpe2UTd21833FmIK9SElb852LZ1rwZp15pmdv8ILZBWjSbyVSykdc4ofXqCcQX1AzFRtwzZ52cwZipUIZHBTmEtlLuOZrzqRD8M3qy463Mc5WdGJ35+4lQoem74DzFRzNxhu+nNsQ4dWU+aTwLNJUKES5M1arIr2KojJbM2yR/T3Mz/dCZUKbtVAFbGSlgjgPkYJHnwheZ++oLFi0/I1jxLfjZLemPvrPKBeamGL51to0sBiV2y2tdZOWLd9K41VgI96mS5P903Gxo1CxICnPBSmFNIHQvNd6PJT6ZXOzjDQZOXphAtu83z5LNH4LJDAtLg264HCk+WLScDVg2rplqlhqHSDR07eEeiGWo/doej/XyOA4UeNAgCAPR+xNSe1jOQkuYrRMaXIcGloF6rcZbmVKnwx6Tb4n5hUuuxVM7AGQeG+v0djNljG8MK3pd957fea7Hb/EcoMrWyEDKoZhed5GFl1kNaKJnQTaZZupbAaGyVybzb50uP38uD7BGHNXYWp5FARORCcT+FPHfyDG+xvD3FfAPVs8M3yIV6mIAr/Z0SMW+jNQwhOstglZQDndACSjSAum5/XKgzKwdTPjH5IOgKt5brHp/OO9nSeFonyJfwAXIH5xx1U7zXdV6/nwzc2eB7yyZQR9SP7NAX3TixKTK6hgRwQ73QkCTDHTmoyv29TNJYU4Gp7r5yN3AtQdVvXs5+IJvz3heMqSTBGmFwJs3EmvtWzgs6rVGIY2TO1mwmdwzGHbgs5dcNJSCecKonMiK2+CNHTlZ8j/cG0C6zTH0p4U72SXtZWd6c8djE6ck2AAlVVVvlesGcbHf1gnZEgGQciPqQBzves7bA2Vzl8xrtim+lqGsjWBXKfEs8 Uxolmaxb z6SeHo/NkTPyLb6/KuezTlDwZq8z7J83qGKvzyeP8Y/NxVTEvgo2OSt2IgzxWW29XjcE9nIdbg0r3jeMQNVVJu79IwHOCxYQRmnPqf1btukoxrF5JiFaNEPLXAEVqhZsBpfHy+JgPwA3SHdMKttHCPAA6l0OaFQNt3C1gO6e/0st7TESVoV4AUvH+GBDYjO8gwUdN5SpobmRR3fDslaQ3nqoI7Fd4vbFUB9Ix3U9XhxmwObzfZupwNdQalGY2C9goHfuytVznZqFGePqXMEHiykIPPef0jlz9HJ+SbNks7b4CSgF2tE471BkBRlAZoLmIFg36kifBCP1/oDOG+3E654s5l00pXjTu/FjoAD9ZyM1AFf/OwfpGn8VuGdyOOXvv+HOkqTLJDKhGEuqeHMitsjmGP4y7zLu2RsRxLqmBrYb6TKin/oP8X0GJHmcJXsaRSAuJp/Q2n+7GsHm5WsIhU4lZw5nTunuY2B758RSMUcUERu8= 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: On Fri, Jan 27, 2023 at 1:12=E2=80=AFPM Jeff Xu wrote= : > > On Fri, Jan 27, 2023 at 11:30 AM Kyle Huey wrote: > > > > On Fri, Jan 27, 2023 at 11:22 AM Kyle Huey wrote: > > > > > > On Fri, Jan 27, 2023 at 11:08 AM Jeff Xu wrote: > > > > > > > > On Thu, Jan 26, 2023 at 9:55 PM Kyle Huey wrote: > > > > > > > > > > On Thu, Jan 26, 2023 at 9:36 PM Jeff Xu wro= te: > > > > > > > > > > > > On Wed, Jan 25, 2023 at 5:43 PM Jeff Xu w= rote: > > > > > > > > > > > > > > On Wed, Jan 25, 2023 at 11:13 AM Dave Hansen wrote: > > > > > > > > > > > > > > > > On 1/25/23 11:02, Jeff Xu wrote: > > > > > > > > > I'm investigating if there is a need to backport x86/pkey= s > > > > > > > > > fix/feature into earlier kernel versions, Chrome is start= ing to use > > > > > > > > > PKEY in x86, and I hope experts here can give advice on t= his. > > > > > > > > > > > > > > > > > > For background, ChromeOS regularly syncs with upstream ke= rnel > > > > > > > > > versions, and has production that uses 4.4/4.14/4.19/5.4/= 5.10/5.15. > > > > > > > > To be honest, I haven't got the foggiest idea what you need= to backport. > > > > > > > > I can barely keep track of mainline. > > > > > > > > > > > > > > > > Are there really production 4.4 kernels that you need to ru= n on > > > > > > > > pkey-capable hardware? That would mean running a 2015-era = kernel on a > > > > > > > > CPU released in late 2020. I think Q3'2020 is when the 11t= h gen CPUs > > > > > > > > came out which were the first non-server CPUs that had pkey= s. > > > > > > > > > > > > > > > Thanks! > > > > > > > For 11th gen CPUs, chromebook uses 5.4 and above, so that eli= minate > > > > > > > half of the versions. > > > > > > > > > > > > > > > On a positive note, the pkeys selftest has been pretty cons= istently > > > > > > > > updated as we find bugs. I'd be curious how well a mainlin= e version of > > > > > > > > that selftests runs on old kernels. But, I'm too scared to= find out > > > > > > > > what's down that particular rabbit hole myself. > > > > > > > > > > > > > I took the latest selftest from main and run on 5.15 kernel, > > > > > > all passed except test_ptrace_modifies_pkru > > > > > > assert() at protection_keys.c::1623 test_nr: 20 iteration: 1 > > > > > > > > > > > > Is there a bugfix for the ptrace area ? > > > > > > Thanks > > > > > > > > > > > > > > > What 5.15 series kernel did you run it on? The patches for that d= idn't > > > > > get backported until 5.15.88 > > > > > > > > > Thanks! I'm using 5.15.87. > > > > Will this patch set be backported to 5.4 and 5.10 ? > > > > The selftest (from main) also failed on 5.4, in the same test, > > > > but at different line: > > > > assert() at protection_keys.c::1651 test_nr: 20 iteration: 1 > > > > > > The regression that patch set was intended to fix was introduced in > > > 5.14. I don't know why the test is failing on 5.4 but I have no plans > > > to investigate it. > > > > Just looking at the line the test is failing on though I would suspect > > that when PKRU was being managed by XSAVE (pre-5.14) that the PKRU > > register didn't get updated for clearing XSTATE_BV until the XRSTOR > > was actually executed (upon return to userspace). So multiple ptrace > > calls in succession without userspace code execution would see a stale > > PKRU value if the PKRU register was "changed" by clearing the relevant > > XSTATE_BV flag. This is an extreme edge case, so I doubt you actually > > care about the behavior. > > I have another case of test_ptrace_modifier_pkru failure. This is happening in AMD 5000 CPU and 5.15.98 kernel. The odd thing about this is: if I run the whole set of protection_keys (20 cases), it will pass. If I run the last case (by comment out the others), it will fail with below error: has pkeys: 1 startup pkey_reg: 0000000055555550 assert() at protection_keys.c::1623 test_nr: 0 iteration: 1 running abort_hooks()... errno at assert: 0 And the same test on Intel CPU is passing. I wonder if this is known or someone has a repro ? Another question regarding PKRU, may or maynot related to this failure on A= MD: During the thread context switch, will PKRU be saved to the thread's user space stack? Is this what XSAVE does (pre-5.14), and if we are not using XSAVE after 5.15, what is used ? Thanks -Jeff > Thank you for the details! > -Jeff > > > - Kyle > > > > > - Kyle > > > > > > > - Jeff > > > > > > > > > - Kyle > > > > > > > > > > > > > > > > > > > > > > > > I can start with 5.10 or 5.15, it seems there are quite some = changes though, > > > > > > > for example, this one by Thomas > > > > > > > https://lore.kernel.org/lkml/20210623120127.327154589@linutro= nix.de/ > > > > > > > > > > > > > > My question is, if I have to pick a version that doesn't requ= ire a lot > > > > > > > of backporting, > > > > > > > and functionality is stable enough, what version would this b= e ? 5.4/5.10/5.15 ? > > > > > > > > > > > > > > -Jeff