Received: by 10.223.185.111 with SMTP id b44csp1601418wrg; Sat, 10 Mar 2018 09:27:12 -0800 (PST) X-Google-Smtp-Source: AG47ELvaHGHxS+2xXBRbayOHwK4F1raaHSr0Az5j+Z7YFMuCbbhGIt/gQzqH77UkL6teZt8JiBDW X-Received: by 10.99.130.199 with SMTP id w190mr1448080pgd.15.1520702832796; Sat, 10 Mar 2018 09:27:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520702832; cv=none; d=google.com; s=arc-20160816; b=ud0+6R/pX/ycIgt9TqreuBQybMtS42kIIoj5e1FAQuumrPl6e2GOa+cTZqryNeDnyi ZaWAh8HLvSXmle+qm1BlubbZNpHGGoLYWhe0nbBq66+ypnTXX9xD9ZhGZni+dpV6r+qp 3/PMt1BoAoXyoaL/VR2mF1tPuS2U5+O2w2Vq8K+RBP4/1yXAR/q5QKZLqYvTYiFTG4dz ONxl73/0xMq7GJNVlw9znv3bB21leapD038FwDqeEPtt1vxO1uGJJOpDvTIovvcwm3ju mSuJwCY5RUJDEkyOeEmhQh8/+fCWKZhKY0Fu2LxMm+ke38FPN4wpwFPTLQ4s+shq/6Cn eZVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=qaqw5383t1Cp4DbD7yMcRD5QOdCbct2LGoUWwcVX2YE=; b=BTo44oOLsmz6e6msrf0Lc7amP4m7xnUPTpv+vaoN8rcnXXWR2WWoFp0KEyuzIlFuxB 4DDl3+R8w1i3RmPY5YggSdxLTi/m5cOCywts9yNrIzwoX40d6RrH3KB2JP1mI/E9VEv3 2WWVKZEiIFlxqasZZlreCtNZNfIPpZnF/BVX6ukZVeGega+HlzmzGPCfRFxmyL1U1G4H Oumfrgbe4hbWkRxS+a8r8IIkh6ipbnWO1EGdJxezXGTVeXtSRfsfNxG1oI3hQNV/nKYk 4kq0yc3nOAgPkN1JPZIdEc2LXM3gh4R8rmGbCQwRU00VReQRMPCFfN1KIHMmZH9io237 pbEg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r4si2531285pgs.323.2018.03.10.09.26.57; Sat, 10 Mar 2018 09:27:12 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751237AbeCJR0I (ORCPT + 99 others); Sat, 10 Mar 2018 12:26:08 -0500 Received: from vps-vb.mhejs.net ([37.28.154.113]:34004 "EHLO vps-vb.mhejs.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750884AbeCJR0H (ORCPT ); Sat, 10 Mar 2018 12:26:07 -0500 Received: by vps-vb.mhejs.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1euiFx-0003G9-An; Sat, 10 Mar 2018 18:26:05 +0100 Subject: Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org References: <34e9d679-2eca-90cf-9a95-3864f0be060e@maciej.szmigiero.name> <20180310164654.GD8261@pd.tnic> From: "Maciej S. Szmigiero" Message-ID: Date: Sat, 10 Mar 2018 18:26:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180310164654.GD8261@pd.tnic> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10.03.2018 17:46, Borislav Petkov wrote: > On Sat, Mar 10, 2018 at 05:16:40PM +0100, Maciej S. Szmigiero wrote: (..) >> There is no container file at all for family 17h (Zen) so >> distributions like OpenSUSE that include this file must have gotten it >> from some other source > > Or maybe they've gotten it from AMD directly. Don't you think that > getting microcode from the CPU vendor directly is the logical thing? "some other source" than linux-firmware includes the CPU vendor. Also please note that while OpenSUSE can get the microcode directly from the CPU vendor there seems to be no official AMD web site that distributes microcode. And it looks like other distros simply get it from OpenSUSE: https://bugs.archlinux.org/task/56951 >> That's why to get things like IBPB it is sometimes necessary to use >> a newer microcode version than included in linux-firmware, sourced for >> example from a BIOS update. > > linux-firmware will get F17h microcode soon. Great! Hope it will include latest production versions for the whole family 17h. >> Since BIOS updates contain only actual (raw) microcode updates one >> has to place it in a microcode container file so this driver can parse >> it. >> >> As far I know there is no tool to automate this work so one has to >> manually tweak the container metadata. > > Let me get this straight: am I reading this correctly that you've tried > to carve out the F17h microcode from a BIOS update blob and you're > trying to load that?!? > > If so, you could've simply taken a distro microcode package and used > F17h microcode from there - they are all the same. > "microcode_amd_fam17h.bin" from both my distro (Gentoo) and OpenSUSE only contains family 23 model 2 microcode while my Ryzen is model 1. And my motherboard BIOS-loaded microcode is too old to contain IBPB support. Maciej