[PATCH] fhandler/proc.cc(format_proc_cpuinfo): Add Linux 6.3 cpuinfo

[PATCH] fhandler/proc.cc(format_proc_cpuinfo): Add Linux 6.3 cpuinfo

[Brian Inglis]

cpuid    0x00000007:0 ecx:7 shstk Shadow Stack support & Windows [20]20H1/[20]2004+
		    => user_shstk User mode program Shadow Stack support
AMD SVM  0x8000000a:0 edx:25 vnmi virtual Non-Maskable Interrrupts
Sync AMD 0x80000008:0 ebx flags across two output locations
---
 winsup/cygwin/fhandler/proc.cc | 29 ++++++++++++++++++++++-------
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/winsup/cygwin/fhandler/proc.cc b/winsup/cygwin/fhandler/proc.cc
index 0e60c519ef79..3c79762e0fbd 100644
--- a/winsup/cygwin/fhandler/proc.cc
+++ b/winsup/cygwin/fhandler/proc.cc
@@ -1384,8 +1384,8 @@ format_proc_cpuinfo (void *, char *&destbuf)
 
 	  ftcprint (features2,  0, "perfmon_v2"); /* Performance Monitoring Version 2 */
 	}
-      /* cpuid 0x80000008 ebx */
-      if (maxe >= 0x80000008)
+      /* AMD cpuid 0x80000008 ebx */
+      if (is_amd && maxe >= 0x80000008)
         {
 /*	  cpuid (&unused, &features1, &unused, &unused, 0x80000008, 0); */
 /*	  from above ^ */
@@ -1395,16 +1395,19 @@ format_proc_cpuinfo (void *, char *&destbuf)
 /*	  ftcprint (features1,  4, "rdpru");	*//* user level rd proc reg */
 /*	  ftcprint (features1,  6, "mba");	*//* memory BW alloc */
 /*	  ftcprint (features1,  9, "wbnoinvd"); *//* wbnoinvd instruction */
-	  ftcprint (features1, 14, "ibrs");	/* ind br restricted spec */
 	  ftcprint (features1, 12, "ibpb");	/* ind br pred barrier */
+	  ftcprint (features1, 14, "ibrs");	/* ind br restricted spec */
 	  ftcprint (features1, 15, "stibp");	/* 1 thread ind br pred */
-	  ftcprint (features1, 16, "ibrs_enhanced"); /* IBRS_ALL enhanced IBRS always on */
+	  ftcprint (features1, 16, "ibrs_enhanced"); /* ibrs_enhanced IBRS always on */
 /*	  ftcprint (features1, 17, "stibp_always_on"); */ /* stibp always on */
-/*	  ftcprint (features1, 18, "ibrs_pref");*//* IBRS_PREF IBRS preferred */
+/*	  ftcprint (features1, 18, "ibrs_pref");*//* ibrs_pref IBRS preferred */
 /*	  ftcprint (features1, 23, "amd_ppin"); *//* protected proc id no */
 /*	  ftcprint (features1, 24, "ssbd");	*//* spec store byp dis */
 /*	  ftcprint (features1, 25, "virt_ssbd");*//* vir spec store byp dis */
 /*	  ftcprint (features1, 26, "ssb_no");	*//* ssb fixed in hardware */
+/*	  ftcprint (features1, 27, "cppc");	*//* collab proc perf ctl */
+/*	  ftcprint (features1, 28, "amd_psfd"); *//* predictive store fwd dis */
+/*	  ftcprint (features1, 31, "brs");	*//* branch sampling */
         }
 
       /* cpuid 0x00000021 ebx|edx|ecx == "IntelTDX    " */
@@ -1483,6 +1486,14 @@ format_proc_cpuinfo (void *, char *&destbuf)
 
 /*	  ftcprint (features1,  6, "split_lock_detect");*//* MSR_TEST_CTRL split lock */
 
+      /* cpuid 0x00000007 ecx & Windows [20]20H1/[20]2004+ */
+      if (maxf >= 0x00000007 && wincap.osname () >= "10.0"
+					 && wincap.build_number () >= 19041)
+        {
+	  cpuid (&unused, &unused, &features1, &unused, 0x00000007, 0);
+	  ftcprint (features1,  7, "user_shstk");	/* "user shadow stack" */
+	}
+
       /* cpuid 0x00000007:1 eax */
       if (maxf >= 0x00000007)
 	{
@@ -1491,6 +1502,7 @@ format_proc_cpuinfo (void *, char *&destbuf)
 	  ftcprint (features1,  4, "avx_vnni");	    /* vex enc NN vec */
 	  ftcprint (features1,  5, "avx512_bf16");  /* vec bfloat16 short */
 /*	  ftcprint (features1,  7, "cmpccxadd"); */ /* CMPccXADD instructions */
+/*	  ftcprint (features1, 18, "lkgs");	 */ /* load kernel (userspace) GS */
 /*	  ftcprint (features1, 21, "amx_fp16");	 */ /* AMX fp16 Support */
 /*	  ftcprint (features1, 23, "avx_ifma");	 */ /* Support for VPMADD52[H,L]UQ */
 	  ftcprint (features1, 26, "lam");	    /* Linear Address Masking */
@@ -1510,14 +1522,15 @@ format_proc_cpuinfo (void *, char *&destbuf)
 /*	  ftcprint (features1, 12, "ibpb" ); */	    /* ind br pred barrier */
 /*	  ftcprint (features1, 14, "ibrs" ); */	    /* ind br restricted spec */
 /*	  ftcprint (features1, 15, "stibp"); */	    /* 1 thread ind br pred */
-/*	  ftcprint (features1, 16, "ibrs_enhanced");*//* IBRS_ALL enhanced IBRS always on */
+/*	  ftcprint (features1, 16, "ibrs_enhanced"); */  /* ibrs_enhanced IBRS always on */
 /*	  ftcprint (features1, 17, "stibp_always_on"); */ /* stibp always on */
-/*	  ftcprint (features1, 18, "ibrs_pref");*//* IBRS_PREF IBRS preferred */
+/*	  ftcprint (features1, 18, "ibrs_pref"); */ /* ibrs_pref IBRS preferred */
 	  ftcprint (features1, 23, "amd_ppin");     /* protected proc id no */
 /*	  ftcprint (features1, 24, "ssbd"); */	    /* spec store byp dis */
 	  ftcprint (features1, 25, "virt_ssbd");    /* vir spec store byp dis */
 /*	  ftcprint (features1, 26, "ssb_no"); */    /* ssb fixed in hardware */
 	  ftcprint (features1, 27, "cppc");	    /* collab proc perf ctl */
+/*	  ftcprint (features1, 28, "amd_psfd"); */  /* predictive store fwd dis */
 	  ftcprint (features1, 31, "brs");	    /* branch sampling */
         }
 
@@ -1558,6 +1571,7 @@ format_proc_cpuinfo (void *, char *&destbuf)
 	  ftcprint (features1, 15, "v_vmsave_vmload");  /* virt vmsave vmload */
 	  ftcprint (features1, 16, "vgif");             /* virt glb int flag */
 	  ftcprint (features1, 20, "v_spec_ctrl");	/* virt spec ctrl support */
+	  ftcprint (features1, 25, "vnmi");             /* virt NMI */
 /*	  ftcprint (features1, 28, "svme_addr_chk");  *//* secure vmexit addr check */
         }
 
@@ -1572,6 +1586,7 @@ format_proc_cpuinfo (void *, char *&destbuf)
 	  ftcprint (features1,  4, "ospke");            /* OS prot keys en */
 	  ftcprint (features1,  5, "waitpkg");          /* umon/umwait/tpause */
 	  ftcprint (features1,  6, "avx512_vbmi2");     /* vec bit manip 2 */
+/*	  ftcprint (features1,  7, "shstk"); */		/* Shadow stack */
 	  ftcprint (features1,  8, "gfni");             /* Galois field instr */
 	  ftcprint (features1,  9, "vaes");             /* vector AES */
 	  ftcprint (features1, 10, "vpclmulqdq");       /* nc mul dbl quad */
-- 
2.39.0

Re: [PATCH] fhandler/proc.cc(format_proc_cpuinfo): Add Linux 6.3 cpuinfo

[Jon Turney]

On 08/05/2023 04:12, Brian Inglis wrote:
> cpuid    0x00000007:0 ecx:7 shstk Shadow Stack support & Windows [20]20H1/[20]2004+
> 		    => user_shstk User mode program Shadow Stack support
> AMD SVM  0x8000000a:0 edx:25 vnmi virtual Non-Maskable Interrrupts
> Sync AMD 0x80000008:0 ebx flags across two output locations

Thanks.  I applied this.

Does this need applying to the 3.4 branch as well?

> ---
>   winsup/cygwin/fhandler/proc.cc | 29 ++++++++++++++++++++++-------

>   
> +      /* cpuid 0x00000007 ecx & Windows [20]20H1/[20]2004+ */
> +      if (maxf >= 0x00000007 && wincap.osname () >= "10.0"
> +					 && wincap.build_number () >= 19041)
> +        {
> +	  cpuid (&unused, &unused, &features1, &unused, 0x00000007, 0);
> +	  ftcprint (features1,  7, "user_shstk");	/* "user shadow stack" */
> +	}
> +

This seems a little odd and maybe worthy of a comment, as surely the CPU 
has the capability irrespective of the OS?

Re: [PATCH] fhandler/proc.cc(format_proc_cpuinfo): Add Linux 6.3 cpuinfo

[Brian Inglis]

On 2023-05-12 09:36, Jon Turney wrote:
> On 08/05/2023 04:12, Brian Inglis wrote:
>> cpuid    0x00000007:0 ecx:7 shstk Shadow Stack support & Windows 
>> [20]20H1/[20]2004+
>>             => user_shstk User mode program Shadow Stack support
>> AMD SVM  0x8000000a:0 edx:25 vnmi virtual Non-Maskable Interrrupts
>> Sync AMD 0x80000008:0 ebx flags across two output locations
> 
> Thanks.  I applied this.
> 
> Does this need applying to the 3.4 branch as well?

How many users with the latest models will worry about this before 3.5 release 
about October, and may Cygwin have support by then?

>> ---
>>   winsup/cygwin/fhandler/proc.cc | 29 ++++++++++++++++++++++-------
> 
>> +      /* cpuid 0x00000007 ecx & Windows [20]20H1/[20]2004+ */
>> +      if (maxf >= 0x00000007 && wincap.osname () >= "10.0"
>> +                     && wincap.build_number () >= 19041)
>> +        {
>> +      cpuid (&unused, &unused, &features1, &unused, 0x00000007, 0);
>> +      ftcprint (features1,  7, "user_shstk");    /* "user shadow stack" */
>> +    }
>> +
> 
> This seems a little odd and maybe worthy of a comment, as surely the CPU has the 
> capability irrespective of the OS?

Yes, see the log comment documenting the shtsk feature and the Windows release 
supporting the process feature, and the patch comment echoing that.

Intel 11th gen and AMD Zen3+ processor models both support the same Control-flow 
Enforcement Technology CET and shstk cpuid and arch features, save areas, MSRs, 
etc.

That is the (currently commented out in the patch) shstk feature, which is 
detected by the Linux kernel but not reported by Linux cpuinfo, and not yet 
fully supported in the kernel by the Intel CET Linux patches.

Whereas Linux cpuinfo does report "user_shstk", which depends on kernel, 
process, compiler, library, and image support, which requires Windows from 
[20]20H1/[20]2004+ enabling and setting up the supported variants of CET flagged 
in one of the process image debug headers, and saving/restoring the shadow stack 
pointer SSP register.

https://www.intel.com/content/www/us/en/developer/articles/technical/technical-look-control-flow-enforcement-technology.html

The current GCC supports -mshstk, but I don't know if there is yet any back end 
support for variants of CET to be flagged in ELF or PE32+ process image debug 
headers, or plans for newlib x86 or Cygwin startup support, and exception 
handling?

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: [PATCH] fhandler/proc.cc(format_proc_cpuinfo): Add Linux 6.3 cpuinfo

[Jon Turney]

On 12/05/2023 19:09, Brian Inglis wrote:
> On 2023-05-12 09:36, Jon Turney wrote:
>> On 08/05/2023 04:12, Brian Inglis wrote:
>>> cpuid    0x00000007:0 ecx:7 shstk Shadow Stack support & Windows 
>>> [20]20H1/[20]2004+
>>>             => user_shstk User mode program Shadow Stack support
>>> AMD SVM  0x8000000a:0 edx:25 vnmi virtual Non-Maskable Interrrupts
>>> Sync AMD 0x80000008:0 ebx flags across two output locations
>>
>> Thanks.  I applied this.
>>
>> Does this need applying to the 3.4 branch as well?
> 
> How many users with the latest models will worry about this before 3.5 
> release about October, and may Cygwin have support by then?

I don't have the data to answer that question.

Instead, I would ask what have we done for previous additions to 
/proc/cpuinfo ?

Re: [PATCH] fhandler/proc.cc(format_proc_cpuinfo): Add Linux 6.3 cpuinfo

[Brian Inglis]

On 2023-05-21 14:32, Jon Turney wrote:
> On 12/05/2023 19:09, Brian Inglis wrote:
>> On 2023-05-12 09:36, Jon Turney wrote:
>>> On 08/05/2023 04:12, Brian Inglis wrote:
>>>> cpuid    0x00000007:0 ecx:7 shstk Shadow Stack support & Windows 
>>>> [20]20H1/[20]2004+
>>>>             => user_shstk User mode program Shadow Stack support
>>>> AMD SVM  0x8000000a:0 edx:25 vnmi virtual Non-Maskable Interrrupts
>>>> Sync AMD 0x80000008:0 ebx flags across two output locations
>>>
>>> Thanks.  I applied this.
>>>
>>> Does this need applying to the 3.4 branch as well?

TL;DR: don't think so, just the next mainline release.

>> How many users with the latest models will worry about this before 3.5 release 
>> about October, and may Cygwin have support by then?
> 
> I don't have the data to answer that question.
> 
> Instead, I would ask what have we done for previous additions to /proc/cpuinfo ?

While updated for each Linux release that makes visible changes dependent only 
on cpuid (and available Windows) data (without needing kernel data like 
processor bug errata, CR, and MSR settings), it is rarely mentioned in 
announcements, unless additional lines are added for better Linux compatibility.
Without the kernel info, some of the Linux output can not be provided.

This info is for compatibility and informational for human consumption, more a 
nice to have than an essential, and a side effect of keeping up my own arch and 
cpuid interests and code with AMD, Intel, and Linux next features.

I don't know if it is used by any code rather than using cpuid instructions to 
get the info directly.

I don't think Corinna ever back-ported it; I always also tested it on, and 
Corinna /may/ have also applied to it to, 32 bit 3.3 for consistency.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: [PATCH] fhandler/proc.cc(format_proc_cpuinfo): Add Linux 6.3 cpuinfo

[Corinna Vinschen]

On May 12 16:36, Jon Turney wrote:
> On 08/05/2023 04:12, Brian Inglis wrote:
> > cpuid    0x00000007:0 ecx:7 shstk Shadow Stack support & Windows [20]20H1/[20]2004+
> > 		    => user_shstk User mode program Shadow Stack support
> > AMD SVM  0x8000000a:0 edx:25 vnmi virtual Non-Maskable Interrrupts
> > Sync AMD 0x80000008:0 ebx flags across two output locations
> 
> Thanks.  I applied this.
> 
> Does this need applying to the 3.4 branch as well?
> 
> > ---
> >   winsup/cygwin/fhandler/proc.cc | 29 ++++++++++++++++++++++-------
> 
> > +      /* cpuid 0x00000007 ecx & Windows [20]20H1/[20]2004+ */
> > +      if (maxf >= 0x00000007 && wincap.osname () >= "10.0"
> > +					 && wincap.build_number () >= 19041)

No problems checking for the OS versions, but not like this.

  wincap.osname () >= "10.0"   ?

That will not do what you expect it to do.  wincap.osname() is a char *
and the >= operator will not work as on cstring in C++, but compare the
pointer values of the two strings instead.

While changing this to

  strcmp (wincap.osname (), "10.0") >= 0

is possible, it doesn't make sense.  For all supported Windows versions,
the build number is unambiguously bumped with each new release.  So
there's no older OS version with a build number >= 19041.  As a result,
the check for osname() can simply go away.

But then again, this is a windows feature which would best served by
adding a bit flag to the wincaps array, *and* we already have a wincaps
array for windows versions starting with build number 19041
(wincap_10_2004).

So, Brian, would you mind to create a followup patch which rather defines
a new bitflag in the wincaps array, set it to false or true according
to the OS version, and check this flag instead?


Thanks,
Corinna