All of lore.kernel.org
 help / color / mirror / Atom feed
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.

      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.