linux-kernel - Re: [PATCH 7/8] x86, microcode, intel: forbid some incorrect metadata

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

Date:	Fri, 8 Aug 2014 14:54:30 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	linux-kernel@...r.kernel.org, H Peter Anvin <hpa@...or.com>
Subject: Re: [PATCH 7/8] x86, microcode, intel: forbid some incorrect metadata

On Mon, Aug 04, 2014 at 05:18:36PM -0300, Henrique de Moraes Holschuh wrote:
> > Because I think it would be better if we simply load the microcode blob
> > we get from Intel unchanged. Like we do on AMD.
> 
> And like we currently do on Intel.  We agree on this, I don't want the
> kernel microcode driver to split anything.

Ok.

So if we don't split, we can savely check ->total_size % 1024.

If someone tries to load a microcode blob which has been split and so
on, then we should refuse loading. We want to accept microcode from the
vendor and nothing else glued together.

> I would hope so as well, but I am a bit more sceptical than you on this.

Well, if you spot a discrepancy where they diverge from the SDM, you
make sure you scream loudly.

> "CPUID returns a value in a model specific register in addition to its usual
> register return values. The semantics of CPUID cause it to deposit an update
> ID value in the 64-bit model-specific register at address 08BH
> (IA32_BIOS_SIGN_ID).  If no update is present in the processor, the value in
> the MSR remains unmodified.  The BIOS must pre-load a zero into the MSR
> before executing CPUID. If a read of the MSR at 8BH still returns zero after
> executing CPUID, this indicates that no update is present."
> 
> Reading a revision of zero really is supposed to mean "no update is present
> in the processor", and that's because it must be pre-loaded with a zero
> before cpuid is called.
> 
> IMHO, this mean that one should be really paranoid over any Intel microcode
> update that claims to have a revision of zero.  Intel wouldn't release such
> a microcode update except in error, and we can safely assume we want nothing
> to do with any such update attempts.

Ok, then please change the patch to reflect that - it is not "silicon
microcode" anymore but revision 0 is special and means no update was
done. Which is a proper way for the CPU to signal microcode update
status.

> Yeah, well, if you have CONFIG_X86_MSR enabled, all bets are off.  Thanks
> for reminding me about that one.

Yes, the only thing you need is the ability to execute *MSR insns in ring0.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/