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]
Message-ID: <lsq.1587683028.212227277@decadent.org.uk>
Date:   Fri, 24 Apr 2020 00:06:53 +0100
From:   Ben Hutchings <ben@...adent.org.uk>
To:     linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC:     akpm@...ux-foundation.org, Denis Kirjanov <kda@...ux-powerpc.org>,
        "Luis Chamberlain" <mcgrof@...nel.org>,
        "Linus Torvalds" <torvalds@...ux-foundation.org>,
        "Borislav Petkov" <bp@...en8.de>,
        "Fenghua Yu" <fenghua.yu@...el.com>,
        "Jari Ruusu" <jari.ruusu@...il.com>
Subject: [PATCH 3.16 186/245] Fix built-in early-load Intel microcode
 alignment

3.16.83-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Jari Ruusu <jari.ruusu@...il.com>

commit f5ae2ea6347a308cfe91f53b53682ce635497d0d upstream.

Intel Software Developer's Manual, volume 3, chapter 9.11.6 says:

 "Note that the microcode update must be aligned on a 16-byte boundary
  and the size of the microcode update must be 1-KByte granular"

When early-load Intel microcode is loaded from initramfs, userspace tool
'iucode_tool' has already 16-byte aligned those microcode bits in that
initramfs image.  Image that was created something like this:

 iucode_tool --write-earlyfw=FOO.cpio microcode-files...

However, when early-load Intel microcode is loaded from built-in
firmware BLOB using CONFIG_EXTRA_FIRMWARE= kernel config option, that
16-byte alignment is not guaranteed.

Fix this by forcing all built-in firmware BLOBs to 16-byte alignment.

[ If we end up having other firmware with much bigger alignment
  requirements, we might need to introduce some method for the firmware
  to specify it, this is the minimal "just increase the alignment a bit
  to account for this one special case" patch    - Linus ]

Signed-off-by: Jari Ruusu <jari.ruusu@...il.com>
Cc: Borislav Petkov <bp@...en8.de>
Cc: Fenghua Yu <fenghua.yu@...el.com>
Cc: Luis Chamberlain <mcgrof@...nel.org>
Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
[bwh: Backported to 3.16: adjust filename, context, indentation]
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
 firmware/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -156,7 +156,7 @@ quiet_cmd_fwbin = MK_FW   $@
 		  PROGBITS=$(if $(CONFIG_ARM),%,@)progbits;		     \
 		  echo "/* Generated by firmware/Makefile */"		> $@;\
 		  echo "    .section .rodata"				>>$@;\
-		  echo "    .p2align $${ASM_ALIGN}"			>>$@;\
+		  echo "    .p2align 4"					>>$@;\
 		  echo "_fw_$${FWSTR}_bin:"				>>$@;\
 		  echo "    .incbin \"$(2)\""				>>$@;\
 		  echo "_fw_end:"					>>$@;\

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ