Kees,
I'm working on some changes/cleanups to make supporting new x86 CPUID families
easier and safer. The big picture is to make the Intel CPU model definitions in
<asm/intel_family.h> encode vendor, family and model so that code like:
if (c->x86_vendor == X86_VENDOR_INTEL && c->x86 == 6 && c->x86_model == INTEL_FAM6_ICELAKE_X)
can become:
if (c->x86_vfm == INTEL_ICELAKE_X)
Source and generated code are smaller. Safer too as it becomes impossible to skip the
vendor and family checks.
To achieve this I want to make a union in struct cpuinfo_x86 that overlays vendor/family/model onto
a 32-bit "x86_vfm" field:
struct cpuinfo_x86 {
union {
struct {
__u8 x86_vendor; /* CPU vendor */
__u8 x86; /* CPU family */
__u8 x86_model;
__u8 x86_reserved;
};
__u32 x86_vfm; /* combined vendor, family, model */
};
__u8 x86_stepping;
... many other fields
} __randomize_layout;
This e-mail is to check you on whether that __randomize_layout can shuffle the
fields inside that nested union/structure. I tried some experiments, and in a
few kernel builds I saw the whole block move to different offsets, but the order
of x86_vendor, x86, x86_model, and x86_reserved was preserved.
But experiments aren't proof. Nor defense against future versions of
scripts/gcc-plugins/randomize_layout_plugin.c becoming smarter or
more aggressive about changing layout.
Thanks
-Tony
On March 27, 2024 9:21:59 AM MDT, "Luck, Tony" <[email protected]> wrote:
>This e-mail is to check you on whether that __randomize_layout can shuffle the
>fields inside that nested union/structure. I tried some experiments, and in a
>few kernel builds I saw the whole block move to different offsets, but the order
>of x86_vendor, x86, x86_model, and x86_reserved was preserved.
Yes, this is an intentional behavior: __randomize_layout will only apply to the struct it is attached to, and is not enabled for any substructs (anonymous or otherwise).
>But experiments aren't proof. Nor defense against future versions of
>scripts/gcc-plugins/randomize_layout_plugin.c becoming smarter or
>more aggressive about changing layout.
The behavior is also supported natively by Clang -- neither implementation is likely to ever change its treatment of substructs as it would kind of cause chaos.
So you're all good! :)
--
Kees Cook