Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp4214554imm; Mon, 25 Jun 2018 11:38:14 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJBaXlp4iN83z/D6ING6athsDt7tfLgMC++3CFmvzmXKGCxvRk0N8c7uZZ3T/XXTPKNsNMc X-Received: by 2002:a17:902:e101:: with SMTP id cc1-v6mr1469669plb.96.1529951894648; Mon, 25 Jun 2018 11:38:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529951894; cv=none; d=google.com; s=arc-20160816; b=ysy6zMD8N1N9P27FGOT03NnJH7L1S6FRGbLz5A5w11os6EIoKrPeJJi6ieUUf2Y0Yp 5ekSzYAi2sZr7mN72sQc2+KxkxLusq/PyYHqvwp/XvXX3HeOCye3Iuhy8kr0fJeTuKFH 4EBGq12rrc6i9Rx76TI/HNPPh43Ku9v3DHA4VQiO1cqlEZqpLqfytb43N+/3aEMMnRxh HdSUxaXgJY2Sq7/ho6RO8ZXnFGKVwAvU98NOmrkuXjWg4DD00opETWPDvGD0F3PoiRPy iQxwjZ+SsGvQyQ59Bp2j4M92zzprFNxVdKRtKrye1lgvxLNSP22dOylARkH22CmF85Ir YinA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=xhmuDN0j8M13H+l40SfHQgkg/WUCW9FBuba+nuCfsoM=; b=FL+yJuHqTvIJ0InVkPKtxnizf2sGL/pNMAHL8ZhGMG1toszm/sZCpiSHfXgWRfdHC5 o692C7LjnQKGlPggqSlaQMlKouce5QbYh7TeslKO5VU8RtsBpRYix4LOg/iF3vcDeOLP UcimMlxVLXjejCVEvg/zclHDjaHFkiHx6RMNtUClzS7R3koBCM3r5Yn2cMiq6mD5jdbu tBZ2Xbit3CvgKmfzzgSvtpMecVeypFuDgq+LX3eu1fSZzfPL+aK2A+XS+d4eHgBwFk9P 5f1v6azLTqvP5wKumOHZ8bGnexUPqEGO/ONe2+NRzqrzidqS5vX6LzEBOSHMF5c7YcDS uv6w== 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 v6-v6si1463044pfv.278.2018.06.25.11.38.00; Mon, 25 Jun 2018 11:38:14 -0700 (PDT) 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 S964979AbeFYShO (ORCPT + 99 others); Mon, 25 Jun 2018 14:37:14 -0400 Received: from mail.skyhub.de ([5.9.137.197]:39490 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964851AbeFYShN (ORCPT ); Mon, 25 Jun 2018 14:37:13 -0400 X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (blast.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CwrO0-X5SQ6F; Mon, 25 Jun 2018 20:37:12 +0200 (CEST) Received: from zn.tnic (p200300EC2BCA5B00329C23FFFEA6A903.dip0.t-ipconnect.de [IPv6:2003:ec:2bca:5b00:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id D334E1EC02AE; Mon, 25 Jun 2018 20:37:11 +0200 (CEST) Date: Mon, 25 Jun 2018 20:37:09 +0200 From: Borislav Petkov To: "Maciej S. Szmigiero" Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] x86/microcode/AMD: Check patch size for all known CPU families Message-ID: <20180625183709.GA3024@zn.tnic> References: <39d0efb50538e4a1a06da693559bb13b060ad676.1529424596.git.mail@maciej.szmigiero.name> <20180621083649.GC12742@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jun 23, 2018 at 12:33:24AM +0200, Maciej S. Szmigiero wrote: > Previously, the AMD microcode update driver has only checked the indicated > microcode patch size for patches for the currently running CPU family. > Patches for other families had their size trusted without further > verification. > > Introduce such check for all CPU families known to the driver so if we spot > a patch that is longer than expected for its family we'll carefully skip > over only the expected length to make sure we don't miss good patches in > case the indicated patch size was something nonsensically huge. > > Signed-off-by: Maciej S. Szmigiero > --- > This is part 2/2 of a replacement for > "[PATCH v7 3/9] x86/microcode/AMD: Integrate verify_patch_size() into verify_patch()". > > arch/x86/kernel/cpu/microcode/amd.c | 67 ++++++++++++++++------------- > 1 file changed, 37 insertions(+), 30 deletions(-) > > diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c > index 53820b92aabb..04a298da4c21 100644 > --- a/arch/x86/kernel/cpu/microcode/amd.c > +++ b/arch/x86/kernel/cpu/microcode/amd.c > @@ -201,43 +201,31 @@ static bool verify_patch(u8 family, const u8 *buf, size_t buf_size, > hdr = (const u32 *)buf; > patch_size = hdr[1]; > > - if (buf_size - SECTION_HDR_SIZE < patch_size) { > + if (buf_size - SECTION_HDR_SIZE < sizeof(*mc_hdr)) { This function adds and removes SECTION_HDR_SIZE a bunch of times so that my head spins trying to remind myself which is which. Please define properly named local variables. > if (!early) > - pr_err("Patch of size %u truncated.\n", patch_size); > + pr_err("Truncated patch header.\n"); > > *crnt_size = buf_size; > return false; > } > > - /* > - * Set a patch length limit of slightly less than U32_MAX to > - * prevent overflowing 32-bit variables holding the whole > - * patch section size. > - */ > - if (patch_size > U32_MAX - SECTION_HDR_SIZE) { > - if (!early) > - pr_err("Patch of size %u too large.\n", patch_size); > - > - *crnt_size = SECTION_HDR_SIZE + PATCH_MAX_SIZE; > - return false; > - } > - > - *crnt_size = SECTION_HDR_SIZE + patch_size; > - > mc_hdr = (const struct microcode_header_amd *)(buf + SECTION_HDR_SIZE); > patch_fam = 0xf + (mc_hdr->processor_rev_id >> 12); > > - /* Is the patch for the proper CPU family? */ > - if (family != patch_fam) > - return false; > - > + /* > + * Check whether patch_size isn't something nonsensically huge so > + * we don't skip over good patches by mistake. > + */ > #define F1XH_MPB_MAX_SIZE 2048 > #define F14H_MPB_MAX_SIZE 1824 > #define F15H_MPB_MAX_SIZE 4096 > #define F16H_MPB_MAX_SIZE 3458 > #define F17H_MPB_MAX_SIZE 3200 > > - switch (family) { > + switch (patch_fam) { > + case 0x10 ... 0x13: > + max_size = F1XH_MPB_MAX_SIZE; I guess this variable should be called fam_size now. > + break; > case 0x14: > max_size = F14H_MPB_MAX_SIZE; > break; > @@ -251,22 +239,41 @@ static bool verify_patch(u8 family, const u8 *buf, size_t buf_size, > max_size = F17H_MPB_MAX_SIZE; > break; > default: > - max_size = F1XH_MPB_MAX_SIZE; > + /* > + * Don't know the max size for future families... > + * Set a patch length limit of slightly less than U32_MAX to > + * prevent overflowing 32-bit variables holding the whole > + * patch section size. > + */ > + max_size = U32_MAX - SECTION_HDR_SIZE; No, just do a WARN_ON_ONCE here. > break; > } > > - /* > - * The section header length is not included in this indicated size > - * but is present in the leftover file length so we need to subtract > - * it from the leftover file length. > - */ > - if (patch_size > min_t(u32, buf_size - SECTION_HDR_SIZE, max_size)) { > + if (patch_size > max_size) { > + if (!early) > + pr_err("Patch of size %u exceeds family %u maximum.\n", > + patch_size, (unsigned int)patch_fam); > + > + *crnt_size = min_t(unsigned int, > + SECTION_HDR_SIZE + max_size, > + buf_size); > + return false; > + } > + > + if (buf_size - SECTION_HDR_SIZE < patch_size) { > if (!early) > - pr_err("Patch of size %u too large.\n", patch_size); > + pr_err("Patch of size %u truncated.\n", patch_size); > > + *crnt_size = buf_size; > return false; > } > > + *crnt_size = SECTION_HDR_SIZE + patch_size; > + > + /* Is the patch for the proper CPU family? */ > + if (family != patch_fam) > + return false; Why are you moving the family check down? What it should do instead is the moment it knows the family, check whether they're equal. If not, skip over with minimum of the size of the corresponding patch_fam and buf_size. And then you do all the remaining checks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.