linux-kernel - Re: [PATCH v2] x86/microcode/AMD: check microcode file sanity before loading it

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

Date:   Mon, 12 Mar 2018 15:30:21 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] x86/microcode/AMD: check microcode file sanity before
 loading it

On Mon, Mar 12, 2018 at 03:10:47PM +0100, Maciej S. Szmigiero wrote:
> And this current maximum was reached by CPU types added in
> families < 15h during last 10+ years (the oldest supported CPU family in

You're assuming that the rate of adding patches to the microcode
container won't change. You have a crystal ball which shows you the
future?

Ok, enough with the bullshit.

Here's what I'll take as hardening patches:

1. Check whether the equivalence table length is not exceeding the size
of the whole blob. This is the only sane limit check we can do - no
arbitrary bullshit of it'll take how many years to reach some limit.

2. Add a PATCH_MAX_SIZE macro which evaluates against the max of all
family patch sizes:

#define F1XH_MPB_MAX_SIZE 2048
#define F14H_MPB_MAX_SIZE 1824
#define F15H_MPB_MAX_SIZE 4096
#define F16H_MPB_MAX_SIZE 3458
#define F17H_MPB_MAX_SIZE 3200

so that future additions won't break the macro.

3. Fix install_equiv_cpu_table() to return an unsigned int

Make all the points above into separate patches, please, with proper
commit messages explaining why they do what they do and test them.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.