linux-kernel - Re: [PATCH] arch/x86/kernel/cpu/microcode/intel: don't store initrd's start

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]

Message-ID: <20160725181841.GB22704@nazgul.tnic>
Date:	Mon, 25 Jul 2016 20:18:41 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Nicolai Stange <nicstange@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arch/x86/kernel/cpu/microcode/intel: don't store
 initrd's start

On Mon, Jul 25, 2016 at 07:44:10PM +0200, Nicolai Stange wrote:
> Boots fine and updates microcode (as always, on top of next-20160722).

Thanks!

> Now that you've got basically the same #ifdefery

Are you saying one #ifdef in my version is the same as at least 7 #if*
lines in yours?

Jeez.

> and if(->valid)'s in your final result as I did,

Your get_ucode_offset() thing is called three times. That function is
also ugly as it gets a bool just to test it and return early if it is
false.

I have the valid test only once for the builtin case.

> may I ask whether you would still consider it as being simpler?

You're joking, right?

Your diffstat:

1 file changed, 44 insertions(+), 21 deletions(-)

My diffstat:

1 file changed, 14 insertions(+), 2 deletions(-)

Along with the reasons above.

> In particular, what's the point of having that ->start if it's
> redundant and has to be corrected in a more or less hackish way
> anyway?

You must be kidding right? Yours returns start too. Let me break it to
ya: we need start.

And now let me break to you the ultimate reason why: the less
intrusive/big/complex the patch, the less problems I have. Because next
time the microcode loader breaks, it won't be *you* picking up the
pieces.

Got that?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--