linux-kernel - __randomize

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-next>] [day] [month] [year] [list]

Message-ID: <SJ1PR11MB608346DDA3F41ABB893C7860FC342@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Wed, 27 Mar 2024 15:21:59 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Kees Cook <keescook@...omium.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: __randomize_layout;

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