Summary: | glibc 2.34 and newer segfault if CPUID leaf 0x2 reports zero | ||
---|---|---|---|
Product: | glibc | Reporter: | Dexuan Cui <decui> |
Component: | libc | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | ayi, decui, drepper.fsp, fweimer, goldstein.w.n, hjl.tools, ioanna.alifieraki |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | 2.36 | ||
Target Milestone: | --- | ||
See Also: | https://sourceware.org/bugzilla/show_bug.cgi?id=30643 | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Attachments: | Proposed patch |
Description
Dexuan Cui
2023-01-24 03:48:00 UTC
I'm reading "Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2A: Instruction Set Reference, A-L" for the definition of CPUID leaf 0x2: " INPUT EAX = 02H: TLB/Cache/Prefetch Information Returned in EAX, EBX, ECX, EDX When CPUID executes with EAX set to 02H, the processor returns information about the processor’s internal TLBs, cache and prefetch hardware in the EAX, EBX, ECX, and EDX registers. The information is reported in encoded form and fall into the following categories: • The least-significant byte in register EAX (register AL) will always return 01H. Software should ignore this value and not interpret it as an informational descriptor. • The most significant bit (bit 31) of each register indicates whether the register contains valid information (set to 0) or is reserved (set to 1). • If a register contains valid information, the information is contained in 1 byte descriptors. There are four types of encoding values for the byte descriptor, the encoding type is noted in the second column of Table 3-12. Table 3-12 lists the encoding of these descriptors. Note that the order of descriptors in the EAX, EBX, ECX, and EDX registers is not defined; that is, specific bytes are not designated to contain descriptors for specific cache, prefetch, or TLB types. The descriptors may appear in any order. Note also a processor may report a general descriptor type (FFH) and not report any byte descriptor of “cache type” via CPUID leaf 2. " CPUID leaf 0x2 is emulated for a TDX guest, and currently the returned EAX/EBX/ECX/EDX are all zeros, and I see the segfault issue in recent releases of glibc, including 2.36-0ubuntu4. If I change the emulation logic in Linux kernel to return 0xff01 in EAX, then the segfault is gone. 0xff01 in EAX means "CPUID leaf 2 does not report cache descriptor information, use CPUID leaf 4 to query cache parameters". So it looks like recent versions of glibc (2.34 and newer?) require a non-zero value in EAX? Please shed some light on this. Thanks! Maybe this is duplicate of: https://sourceware.org/bugzilla/show_bug.cgi?id=29953 in which case it was fixed by: https://sourceware.org/git/?p=glibc.git;a=commit;h=48b74865c63840b288bd85b4d8743533b73b339b x86: Check minimum/maximum of non_temporal_threshold [BZ #29953] The minimum non_temporal_threshold is 0x4040. non_temporal_threshold may be set to less than the minimum value when the shared cache size isn't available (e.g., in an emulator) or by the tunable. Add checks for minimum and maximum of non_temporal_threshold. This fixes BZ #29953. Created attachment 14719 [details]
Proposed patch
Ah sorry please ignore the patch above. I added it to the wrong bug :( I can confirm that this is a duplicate of https://sourceware.org/bugzilla/show_bug.cgi?id=29953 and commit https://sourceware.org/git/?p=glibc.git;a=commit;h=48b74865c63840b288bd85b4d8743533b73b339b resolves the crash on Ubuntu 22.04. |