linux-kernel - Re: [PATCH v7 0/6] Introduce CET supervisor state support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ede5efc3-1a6d-45c7-807d-ac83d3de223e@intel.com>
Date: Fri, 16 May 2025 08:15:56 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Uros Bizjak <ubizjak@...il.com>, Chao Gao <chao.gao@...el.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
 tglx@...utronix.de, seanjc@...gle.com, pbonzini@...hat.com,
 peterz@...radead.org, rick.p.edgecombe@...el.com, weijiang.yang@...el.com,
 john.allen@....com, bp@...en8.de, chang.seok.bae@...el.com,
 xin3.li@...el.com, Aruna Ramakrishna <aruna.ramakrishna@...cle.com>,
 Dave Hansen <dave.hansen@...ux.intel.com>, Eric Biggers
 <ebiggers@...gle.com>, "H. Peter Anvin" <hpa@...or.com>,
 Ingo Molnar <mingo@...hat.com>, Kees Cook <kees@...nel.org>,
 Maxim Levitsky <mlevitsk@...hat.com>, Mitchell Levy
 <levymitchell0@...il.com>, Nikolay Borisov <nik.borisov@...e.com>,
 Oleg Nesterov <oleg@...hat.com>, Samuel Holland <samuel.holland@...ive.com>,
 Sohil Mehta <sohil.mehta@...el.com>, Stanislav Spassov <stanspas@...zon.de>,
 Vignesh Balasubramanian <vigbalas@....com>, Zhao Liu <zhao1.liu@...el.com>
Subject: Re: [PATCH v7 0/6] Introduce CET supervisor state support

On 5/16/25 00:51, Uros Bizjak wrote:
> I wonder if the same approach can be used to optimize switching of
> Intel PT configuration context. There was a patch series [1] posted
> some time ago that showed substantial reduction of overhead when
> switching Intel PT configuration context on VM-Entry/Exit using
> XSAVES/XRSTORS instructions:
> 
> Manual save(rdmsr):     ~334  cycles
> Manual restore(wrmsr):  ~1668 cycles
> 
> XSAVES insturction:     ~124  cycles
> XRSTORS instruction:    ~378  cycles

There's nothing stopping us from using XSAVES/XRSTORS for PT,
independent of the kernel FPU infrastructure. RFBM exists for a reason.

There's also WRMSRLIST which we're not using yet either. It's an even
better fit and doesn't have the goofiness that using XSAVE does like the
legacy portion of the save area including the header.