Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2335004ybz; Thu, 23 Apr 2020 16:14:22 -0700 (PDT) X-Google-Smtp-Source: APiQypIcgXl/ye3RoQpWIBmQBFRjK2iTVQCEzLQBC3Wh9DxDKAgrbQAzLBsTFWn+VkKiT5XRbBrk X-Received: by 2002:aa7:dcd7:: with SMTP id w23mr4949026edu.300.1587683662622; Thu, 23 Apr 2020 16:14:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587683662; cv=none; d=google.com; s=arc-20160816; b=Kr+b+v1tCXNBk8ifA6jFMASgI/PcMczRgA5+6IePMSSEiP7zf/FIPCLvD7rgO2hsam WaAXy8F6DImloIZKOFggIcTe4uZ+lLX7BsRDfviVmbhLDSedbAtOBM+bdR614bXh7Ucr lisTSwkggCGZ0AQteuNEUJmsDApnC8aXHNDirE7ZUfG+7wl1oLS6QfuT+SaZe7vvH+FI jeiUZ28w82h3IhvPOb2slGhrShOPikkxFcEpAiT4nHe5z6jXXRw4Z75SxPAUr1js7MlE sD5VRazWGtieDOe+TKwh046D5G9juDfckZ5DmLg4ORoEguVqjT4nvDClXahQtk3Bv0GG v/YQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=CnnludpERgZYcAdRsW9cJapaJ4b7O6wHf9e0Uus8wU8=; b=uYehyrrgw6CIzGugCy7NWqcsIY2iM6K7uW9iFrNcLFDXdfGUXptbCjSq0gP/JWa9ZR Cycqf4Eiy+EWZRdQxMWRv4Mgo97sLwR10Z3uYFzGF3CADXoec7OeDLqrcjfEuOT+MsXA 9fSCUOm/MI4841bxDaPEGCCPj0TepF2+Le/r581BVted19PgAu1SFP9m3Odxca5ALbpw ZbS+A0vVdXnYahqIR9U7+h17aiBHWgHEfsVM4mxCcVc7UAeKprKD4++G/v17jTZ0hgJT LUw7rfCYcHHzUr+qzgAbGE/odm/fsaU9XqR9J5v2xJ+ziUQOZvffn2cUvtObGhXV1w3u zMKw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dn15si1986731edb.555.2020.04.23.16.13.59; Thu, 23 Apr 2020 16:14:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728936AbgDWXLS (ORCPT + 99 others); Thu, 23 Apr 2020 19:11:18 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:50240 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728560AbgDWXGw (ORCPT ); Thu, 23 Apr 2020 19:06:52 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvb-0004n5-Jr; Fri, 24 Apr 2020 00:06:43 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvW-00E6wn-OP; Fri, 24 Apr 2020 00:06:38 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, Denis Kirjanov , "Luis Chamberlain" , "Linus Torvalds" , "Borislav Petkov" , "Fenghua Yu" , "Jari Ruusu" Date: Fri, 24 Apr 2020 00:06:53 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 186/245] Fix built-in early-load Intel microcode alignment In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Jari Ruusu 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 Cc: Borislav Petkov Cc: Fenghua Yu Cc: Luis Chamberlain Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: adjust filename, context, indentation] Signed-off-by: Ben Hutchings --- 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:" >>$@;\