linux-kernel - BUG: early intel microcode update violating alignment rules

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

Message-ID: <20140809231911.GA4843@khazad-dum.debian.net>
Date:	Sat, 9 Aug 2014 20:19:11 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Borislav Petkov <bp@...en8.de>, H Peter Anvin <hpa@...or.com>,
	Fenghua Yu <fenghua.yu@...el.com>
Cc:	linux-kernel@...r.kernel.org
Subject: BUG: early intel microcode update violating alignment rules

Hello x86 maintainers,

While adding some paranoia to the Intel Microcode driver, I noticed the
early Intel microcode update driver is not enforcing a 16-byte alignment
when it attempts to send the microcode update data to the processor via
WRMSR 79H.

This 16-byte alignment requirement is stated in the Intel SDM, vol 3A,
section 9.11.6, page 9-34.

Apparently at least some of the recent processors don't need the full
16-byte alignment, as a microcode update that is NOT aligned to 16 bytes,
but which is aligned to 4 bytes seems to work fine on a Xeon X5550 and on a
2nd-gen Core i5.

I detected the problem by adding an alignment test in
apply_microcode_early(), on file arch/x86/kernel/microcode_intel_early.c:

	if ((unsigned long)(mc_intel->bits) % 16)
		return -1;

Which fired on the next reboot, skipping the early update on the BSP and
APs.

This will only happen when the microcode update file data inside the early
initramfs archive is not 16-byte aligned.  Unfortunately, the cpio format
used in the early initramfs aligns the member file data just to 4-byte
boundaries.

Is there a way to fix this in the kernel for the BSP?  We already have
several microcode updates that are >16KiB in size and they seem to be
getting bigger and bigger, so doing it on the stack is out.

Maybe there is a 64KiB scratch area that could be used just to get the BSP
microcode update done?  vmalloc isn't available that early, but it can be
used to fix the issue for the APs.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/