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=-7.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 DEB5EC2BB84 for ; Thu, 3 Sep 2020 04:36:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7D905208B3 for ; Thu, 3 Sep 2020 04:36:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com header.i=@amacapital-net.20150623.gappssmtp.com header.b="2TRg6Pt2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D905208B3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=amacapital.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D76226B0003; Thu, 3 Sep 2020 00:36:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CFED96B0037; Thu, 3 Sep 2020 00:36:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA00D6B0055; Thu, 3 Sep 2020 00:36:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id 9DC4F6B0003 for ; Thu, 3 Sep 2020 00:36:01 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 442DF8248068 for ; Thu, 3 Sep 2020 04:36:01 +0000 (UTC) X-FDA: 77220487722.08.ray62_580038c270a6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 0F1F91819E76B for ; Thu, 3 Sep 2020 04:36:01 +0000 (UTC) X-HE-Tag: ray62_580038c270a6 X-Filterd-Recvd-Size: 7509 Received: from mail-pj1-f66.google.com (mail-pj1-f66.google.com [209.85.216.66]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Thu, 3 Sep 2020 04:36:00 +0000 (UTC) Received: by mail-pj1-f66.google.com with SMTP id s2so836649pjr.4 for ; Wed, 02 Sep 2020 21:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=c4AodrXdr1y4XfEvpz1cwzbqc0Ntf48J70eL2aX9oQI=; b=2TRg6Pt2o98tfWujTDiLLf6/VEGtI649lNEM2WkQGpk5OujV684ZLl1+qouHnVzCxI ToSXizqAPkBQ6AVBn1hMw0OAXSQYfxGE+Cd7YpFLxFHGLySOQlE4kNo98rNNCUXhNf0c arXqJo4aLZK1ppcDlHPJks8e3VOXyXWWVLeJEapUQJBuJ4hMrixSWr1qgns1jUDjIWTx pdxrHsyVQ1Z/mAfec2PKKlgYL0dGUd7OABGH/Sq4mWZiDXD0WghrDhnCj/k2bluv3Zsk z/YObrYdwUpa0M6OjGrUwZtO5PSXH20kWbGxRS0XihZlJktcT2tnAMU9AWWtGZEscSCp lx+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=c4AodrXdr1y4XfEvpz1cwzbqc0Ntf48J70eL2aX9oQI=; b=qerfSLs9/8WyafMXC3iRn5ApMqF9m4ipH4S/zBX/IDxkA5fod6oY8oIg07SofycxHs KkDw+G/P5kXINgux29KbaOoZJ9JBFGFvGG9A1kG8m3qjpxV/p+cWQi2fDzJfLp6uD92V Wz+ZnX4qnv4wPC7ZCq61LdOOWjPo5mG3StcSf4s5pOA2Dyq2eOAt45nzbN3erj8V7mNW 3RxAH3wzXUJPO8m23gI57TAxdtehv9B0s5Q5dWbD+brhBrkXRt68wnN1j5Yz0gWHgble TzJiU8uRlp5YawmjmrKLzSbc0V9nrsg1LS+Nd0aSZi+eekhCQx/ieA5tE7Bv94YZzgrA QUHg== X-Gm-Message-State: AOAM532VQrdSgmqwbU1x7NXhng3F4t5hIg3WmZcZNtAoSWqiVYTr27LE XgkBA02gOjyXqduyuZr9BEzefQ== X-Google-Smtp-Source: ABdhPJwaRQQGkv4eqs7ZIu/88dhYc9SDUGZTxIHWO2yBYvRFSnsqam/VW1c/u0PoJZoI8hvFN36jkw== X-Received: by 2002:a17:90a:160f:: with SMTP id n15mr1310345pja.75.1599107759363; Wed, 02 Sep 2020 21:35:59 -0700 (PDT) Received: from ?IPv6:2600:1010:b068:276f:834:4bae:7a0f:cb7d? ([2600:1010:b068:276f:834:4bae:7a0f:cb7d]) by smtp.gmail.com with ESMTPSA id q34sm917533pgl.28.2020.09.02.21.35.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2020 21:35:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET Date: Wed, 2 Sep 2020 21:35:56 -0700 Message-Id: <40BC093A-F430-4DCC-8DC0-2BA90A6FC3FA@amacapital.net> References: <46e42e5e-0bca-5f3f-efc9-5ab15827cc0b@intel.com> Cc: Jann Horn , the arch/x86 maintainers , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , kernel list , linux-doc@vger.kernel.org, Linux-MM , linux-arch , Linux API , Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , Weijiang Yang In-Reply-To: <46e42e5e-0bca-5f3f-efc9-5ab15827cc0b@intel.com> To: "Yu, Yu-cheng" X-Mailer: iPhone Mail (17G80) X-Rspamd-Queue-Id: 0F1F91819E76B X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 Sep 2, 2020, at 7:53 PM, Yu, Yu-cheng wrote: >=20 > =EF=BB=BFOn 9/2/2020 4:50 PM, Andy Lutomirski wrote: >>>> On Sep 2, 2020, at 3:13 PM, Yu, Yu-cheng wrote:= >>>=20 >>> =EF=BB=BFOn 9/2/2020 1:03 PM, Jann Horn wrote: >>>>> On Tue, Aug 25, 2020 at 2:30 AM Yu-cheng Yu wr= ote: >>>>> Add REGSET_CET64/REGSET_CET32 to get/set CET MSRs: >>>>>=20 >>>>> IA32_U_CET (user-mode CET settings) and >>>>> IA32_PL3_SSP (user-mode Shadow Stack) >>>> [...] >>>>> diff --git a/arch/x86/kernel/fpu/regset.c b/arch/x86/kernel/fpu/regset= .c >>>> [...] >>>>> +int cetregs_get(struct task_struct *target, const struct user_regset *= regset, >>>>> + struct membuf to) >>>>> +{ >>>>> + struct fpu *fpu =3D &target->thread.fpu; >>>>> + struct cet_user_state *cetregs; >>>>> + >>>>> + if (!boot_cpu_has(X86_FEATURE_SHSTK)) >>>>> + return -ENODEV; >>>>> + >>>>> + fpu__prepare_read(fpu); >>>>> + cetregs =3D get_xsave_addr(&fpu->state.xsave, XFEATURE_CET_USE= R); >>>>> + if (!cetregs) >>>>> + return -EFAULT; >>>> Can this branch ever be hit without a kernel bug? If yes, I think >>>> -EFAULT is probably a weird error code to choose here. If no, this >>>> should probably use WARN_ON(). Same thing in cetregs_set(). >>>=20 >>> When a thread is not CET-enabled, its CET state does not exist. I looke= d at EFAULT, and it means "Bad address". Maybe this can be ENODEV, which me= ans "No such device"? Having read the code, I=E2=80=99m unconvinced. It looks like a get_xsave_add= r() failure means =E2=80=9Cstate not saved; task sees INIT state=E2=80=9D. S= o *maybe* it=E2=80=99s reasonable -ENODEV this, but I=E2=80=99m not really c= onvinced. I tend to think we should return the actual INIT state and that we= should permit writes and handle them correctly. Dave, what do you think? >>>=20 >>> [...] >>>=20 >>>>> @@ -1284,6 +1293,13 @@ static struct user_regset x86_32_regsets[] __ro= _after_init =3D { >>>> [...] >>>>> + [REGSET_CET32] =3D { >>>>> + .core_note_type =3D NT_X86_CET, >>>>> + .n =3D sizeof(struct cet_user_state) / sizeof(u64), >>>>> + .size =3D sizeof(u64), .align =3D sizeof(u64), >>>>> + .active =3D cetregs_active, .regset_get =3D cetregs_ge= t, >>>>> + .set =3D cetregs_set >>>>> + }, >>>>> }; >>>> Why are there different identifiers for 32-bit CET and 64-bit CET when >>>> they operate on the same structs and have the same handlers? If >>>> there's a good reason for that, the commit message should probably >>>> point that out. >>>=20 >>> Yes, the reason for two regsets is that fill_note_info() does not expect= any holes in a regsets. I will put this in the commit log. >>>=20 >>>=20 >> Perhaps we could fix that instead? >=20 > As long as we understand the root cause, leaving it as-is may be OK. The regset mechanism=E2=80=99s interactions with compat are awful. Let=E2=80= =99s please not make it worse. One CET regret is good; two is not good. >=20 > I had a patch in the past, but did not follow up on it. >=20 > https://lore.kernel.org/lkml/20180717162502.32274-1-yu-cheng.yu@intel.com/= >=20 > Yu-cheng