Received: by 10.213.65.68 with SMTP id h4csp86463imn; Mon, 12 Mar 2018 07:32:38 -0700 (PDT) X-Google-Smtp-Source: AG47ELvouvtyT1N2ugHv6/mL0vN/7tbMAqHcCbn2j2IXOgYJotLYZ1cl0B+yKa3UEeMb+m23iD7r X-Received: by 10.98.73.140 with SMTP id r12mr8160337pfi.229.1520865158075; Mon, 12 Mar 2018 07:32:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520865158; cv=none; d=google.com; s=arc-20160816; b=cMh/BROuTRqJ3vCQH5zhB53Z+TlOLZQobrAa+SARXikPpuIvIxwEPP+zeKzrMembpY 0US5ZROOHWnRJEuytuj766zWQSHJmwnVS0YucS9K8lJ4xSDK/DpjBjOkXIv1/MApJHok 0UIQDw5YL7ofBqxkHvGPY8+bAe74clTn+t5QhF/Tu1YVxShW6U6/pF308Ha5uKTjo026 2aJiTcm10G6h4hFEbuLK3DrBCz9E8KhmlbYKS2M4ARhQH0FcRK7Y2zBmHxGn1zFf/n7S q3Ceyb7taJ8PhYgHb1K0mocWqPkZSlq8xSg9+9YQKeFUnnGCsCnsXt2hFwgPqqv2U1vU yoDQ== 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=uQw+FrJLVFXOGWFaRdbOweiAUS+LuXTLyy3WmzATSak=; b=VCQFDlaTeLD55z++syz/xlVgJTMlNIsPDAWl8BEHssU73uauhSUU/o21pyCDSrFVdr Tb8fQqNukKNWjJ8Cp8HTTU+ggoYpQYe3jQW6FNIL21npVNuXNzQ5vsuXqEM62B8owQot mnX7gSuuPPn47zwOZtqurw8Q5wqj+K/GDo6L6OTE7oQiX6adonyzt9aD7MacVSKHkr+s SDGf4XrvTsMqFNOFSqvA5q/VG+7kLnAkNYiVYvMakPytbA9iuBXBoslBtXp3cSavZANJ GaPReTiUv1+Dn5k5Td6zqa1rN+O2tr9/P3HPGGSaP17L2vNRHaElFgSeVnpfEf34DLq4 xZuw== 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 a190si4659558pge.436.2018.03.12.07.32.24; Mon, 12 Mar 2018 07:32:38 -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 S1751991AbeCLOam (ORCPT + 99 others); Mon, 12 Mar 2018 10:30:42 -0400 Received: from mail.skyhub.de ([5.9.137.197]:56318 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751361AbeCLOak (ORCPT ); Mon, 12 Mar 2018 10:30:40 -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 GVg0sDxAhNBp; Mon, 12 Mar 2018 15:30:39 +0100 (CET) Received: from pd.tnic (p200300EC2BC5BE00D8383C045719CF88.dip0.t-ipconnect.de [IPv6:2003:ec:2bc5:be00:d838:3c04:5719:cf88]) (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 355FF1EC06BA; Mon, 12 Mar 2018 15:30:39 +0100 (CET) Date: Mon, 12 Mar 2018 15:30:21 +0100 From: Borislav Petkov To: "Maciej S. Szmigiero" Cc: Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] x86/microcode/AMD: check microcode file sanity before loading it Message-ID: <20180312143021.GE9431@pd.tnic> References: <787b0ecc-8c1a-3b5a-82e0-9840c7b7c595@maciej.szmigiero.name> <20180312095336.GB9431@pd.tnic> <20180312130653.GC9431@pd.tnic> <20180312134853.GD9431@pd.tnic> <2d60978a-522c-ff00-f245-a7e681283371@maciej.szmigiero.name> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2d60978a-522c-ff00-f245-a7e681283371@maciej.szmigiero.name> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 12, 2018 at 03:10:47PM +0100, Maciej S. Szmigiero wrote: > And this current maximum was reached by CPU types added in > families < 15h during last 10+ years (the oldest supported CPU family in You're assuming that the rate of adding patches to the microcode container won't change. You have a crystal ball which shows you the future? Ok, enough with the bullshit. Here's what I'll take as hardening patches: 1. Check whether the equivalence table length is not exceeding the size of the whole blob. This is the only sane limit check we can do - no arbitrary bullshit of it'll take how many years to reach some limit. 2. Add a PATCH_MAX_SIZE macro which evaluates against the max of all family patch sizes: #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 so that future additions won't break the macro. 3. Fix install_equiv_cpu_table() to return an unsigned int Make all the points above into separate patches, please, with proper commit messages explaining why they do what they do and test them. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.