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=-4.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 1C6F2C433EA for ; Thu, 23 Jul 2020 17:08:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CAC8920792 for ; Thu, 23 Jul 2020 17:08:48 +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="yoXd9uVk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CAC8920792 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 66F076B0010; Thu, 23 Jul 2020 13:08:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6469E6B0022; Thu, 23 Jul 2020 13:08:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 534D76B0023; Thu, 23 Jul 2020 13:08:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0021.hostedemail.com [216.40.44.21]) by kanga.kvack.org (Postfix) with ESMTP id 3FC856B0010 for ; Thu, 23 Jul 2020 13:08:48 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C7CAA1801584F for ; Thu, 23 Jul 2020 17:08:47 +0000 (UTC) X-FDA: 77069975094.01.dust03_6209a3526f40 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id 82C1010051147 for ; Thu, 23 Jul 2020 17:08:47 +0000 (UTC) X-HE-Tag: dust03_6209a3526f40 X-Filterd-Recvd-Size: 6304 Received: from mail-pj1-f65.google.com (mail-pj1-f65.google.com [209.85.216.65]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Thu, 23 Jul 2020 17:08:46 +0000 (UTC) Received: by mail-pj1-f65.google.com with SMTP id a9so3444282pjd.3 for ; Thu, 23 Jul 2020 10:08:46 -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=NPbssqK1INtrFyjAUzj5mlbSJgxK4WzDaPmXZHhkVOg=; b=yoXd9uVkO2vV1qapKWvg6gqU+YlOechgMeu61k1dp7CN9clp8UmaHRbquyhgRG0EEc qzNe84TrLIXIyjqC0IiE0n1EHX+P8HvoY7yvHrCHdph8GNfNnaBIpslpqlns5gX8TQ4q Bjc8eIcn2XxbBGMyr4IOZe4gzlsbUnxZEddFJMD7FKjlftnULb8az0udybrX2ZdDEO6x +Zy+/yT5PdnRQvQeYA0xF4eJxdQH8BXXKKGfX9TFsapCl/a4p9//S4304AlD7ypcAdCx lgtOkhY7tTnU+9KXye1d1QzYZAXqKP44YDuwrRT/s98xYKGWvdcqCEQ8yQLWxSOQlrvX Yn2w== 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=NPbssqK1INtrFyjAUzj5mlbSJgxK4WzDaPmXZHhkVOg=; b=EVcEzkgytaixH43Ve0R8EFKKMsuKmsL9XhVW2b2M7/Hl5yVFwASImjL5MaUp/G7OMi KnQMBSpU/58O00fO0uL5UWo+1FpG1xNYX/MmDE9NHuKWAxPoofVBO595UEKH4O1JMdUl RJARrmKAxu430m9M5x2mwyJo9JSQneDb2HK+QmT52dAtTMoP/5f+OpJabmlcQqQIzBeB AHN3sMe9Kztr1ztOZXZj1wdePctdbLmuNQBSPRnyy0RYZqzJmL8Hfhdoc+CKz09Gw5gN IMUwm5+dtOoBP4qn35Rq/wv8l53Q8X+SQtr6vSefCqEHd4HQfM/HQjUw8xHluy4z+rjP 8JOA== X-Gm-Message-State: AOAM531PHgC00Ob/vDuw9oFyDA0WvEys9MktCprqll54Y3yMENBpmiOV CmLPMfBkk3t3dTLBLyTJ1ln+iQ== X-Google-Smtp-Source: ABdhPJzhEVeWE+MsYhg97fGrJZMWD4MyQ/tPFCjeaW/T/ed2wa91gkVSb8XcX/EmBjVpwheP/E/Q+w== X-Received: by 2002:a17:90a:ff0c:: with SMTP id ce12mr1353809pjb.100.1595524125805; Thu, 23 Jul 2020 10:08:45 -0700 (PDT) Received: from ?IPv6:2601:646:c200:1ef2:ecdf:69cc:bc40:aa6d? ([2601:646:c200:1ef2:ecdf:69cc:bc40:aa6d]) by smtp.gmail.com with ESMTPSA id v197sm3695465pfc.35.2020.07.23.10.08.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jul 2020 10:08:45 -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 RFC V2 17/17] x86/entry: Preserve PKRS MSR across exceptions Date: Thu, 23 Jul 2020 10:08:42 -0700 Message-Id: References: <20200723165204.GB77434@romley-ivt3.sc.intel.com> Cc: Dave Hansen , Andy Lutomirski , Weiny Ira , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Peter Zijlstra , Dave Hansen , X86 ML , Dan Williams , Vishal Verma , Andrew Morton , "open list:DOCUMENTATION" , LKML , linux-nvdimm , Linux FS Devel , Linux-MM , "open list:KERNEL SELFTEST FRAMEWORK" In-Reply-To: <20200723165204.GB77434@romley-ivt3.sc.intel.com> To: Fenghua Yu X-Mailer: iPhone Mail (17F80) X-Rspamd-Queue-Id: 82C1010051147 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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 Jul 23, 2020, at 9:52 AM, Fenghua Yu wrote: >=20 > =EF=BB=BFHi, Dave, >=20 >> On Thu, Jul 23, 2020 at 09:23:13AM -0700, Dave Hansen wrote: >>> On 7/23/20 9:18 AM, Fenghua Yu wrote: >>> The PKRS MSR has been preserved in thread_info during kernel entry. We >>> don't need to preserve it in another place (i.e. idtentry_state). >>=20 >> I'm missing how the PKRS MSR gets preserved in thread_info. Could you >> explain the mechanism by which this happens and point to the code >> implementing it, please? >=20 > [Sorry, my mistake: I mean "thread_struct" instead of "thread_info". > Hopefully the typo doesn't change the essential part in my last email.] >=20 > The "saved_pkrs" is defined in thread_struct and context switched in > patch 04/17: > https://lore.kernel.org/lkml/20200717072056.73134-5-ira.weiny@intel.com/ >=20 > Because there is no XSAVE support the PKRS MSR, we preserve it in > "saved_pkrs" in thread_struct. It's initialized as 0 (init state, no > protection key) in fork() or exec(). It's updated to a right protection > value when a driver calls the updating API. The PKRS MSR is context > switched by "saved_pkrs" when switching to a task (unless optimized if the= > cached MSR is the same as the saved one). >=20 >=20 Suppose some kernel code (a syscall or kernel thread) changes PKRS then takes a page fault. The page fault handler n= eeds a fresh PKRS. Then the page fault handler (say a VMA=E2=80=99s .fault h= andler) changes PKRS. The we get an interrupt. The interrupt *also* needs a= fresh PKRS and the page fault value needs to be saved somewhere. So we have more than one saved value per thread, and thread_struct isn=E2=80= =99t going to solve this problem. But idtentry_state is also not great for a couple reasons. Not all entries h= ave idtentry_state, and the unwinder can=E2=80=99t find it for debugging. Fo= r that matter, the page fault logic probably wants to know the previous PKRS= , so it should either be stashed somewhere findable or it should be explicit= ly passed around. My suggestion is to enlarge pt_regs. The save and restore logic can probabl= y be in C, but pt_regs is the logical place to put a register that is saved a= nd restored across all entries. Whoever does this work will have the delightful job of figuring out whether B= PF thinks that the layout of pt_regs is ABI and, if so, fixing the resulting= mess. The fact the new fields will go at the beginning of pt_regs will make this a= n entertaining prospect.=