From: Borislav Petkov <bp@alien8.de>
To: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Cc: Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] x86/microcode/AMD: check microcode file sanity before loading it
Date: Mon, 12 Mar 2018 15:30:21 +0100 [thread overview]
Message-ID: <20180312143021.GE9431@pd.tnic> (raw)
In-Reply-To: <2d60978a-522c-ff00-f245-a7e681283371@maciej.szmigiero.name>
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.
prev parent reply other threads:[~2018-03-12 14:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-11 15:27 [PATCH v2] x86/microcode/AMD: check microcode file sanity before loading it Maciej S. Szmigiero
2018-03-12 9:53 ` Borislav Petkov
2018-03-12 12:56 ` Maciej S. Szmigiero
2018-03-12 13:06 ` Borislav Petkov
2018-03-12 13:32 ` Maciej S. Szmigiero
2018-03-12 13:48 ` Borislav Petkov
2018-03-12 14:10 ` Maciej S. Szmigiero
2018-03-12 14:30 ` Borislav Petkov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180312143021.GE9431@pd.tnic \
--to=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mail@maciej.szmigiero.name \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.