Received: by 10.192.165.148 with SMTP id m20csp4281506imm; Mon, 30 Apr 2018 15:28:15 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq3UuVsFwl3AOFLs6iuEFAAX16Qk1LaGcjGIifjG73Q1WTsLyY8U7DA33gvYcVROUFyF/9U X-Received: by 10.98.133.154 with SMTP id m26mr13391674pfk.247.1525127295503; Mon, 30 Apr 2018 15:28:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525127295; cv=none; d=google.com; s=arc-20160816; b=DZKhCigx6FNlys/hPnDww0VqlDOqDLJFXDqkPnsfxA31dViypLKTyL8PbiepZTBuZd tbGZBblRioY1nUDtiqZluvRZYCfmQA+ViqlFdz35TGpHelq4QQFjSY3GknlhL4CCASK5 6oPix+YrVXjy9p4yejnIFDiQ39NFgb1wDRxQmBMx1353gxx4IgYV6nmL4Vk9CH2k9ev9 MUIMvNFrWDmLbIdyuJZ2fcd4epHywqRqAGc5uiXsP87B4gRFYJZqTkrQYUwoK+kJs9Da yYkm6XEskD+9DlzKSEgdkB1qYIx5pqmmlWl5M53dL42AE6i+VoHnK+6N5fY/lg3lgz9J dTaw== 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=/7035kK1ICUcAZgVFREgekOSMlqnYaQz0SFu540U3lI=; b=DvuJBEnAICOVuY/1Fk8koIckGYnx1m2EtPnbV+Kxasvffr4y7dYY2DPz9kCgI3OXDt OZD7V8Lgmgmwi8n9+L1kREBdcznPQeiu40JXWMssG/KVxvkDyT/cORom+bBFe4ypUvGN UB6LF/zA476/j+/C7XUlO8Eq9dONsWN+xvTs40Uep/Aj/NNcgDPIt+1jL0uTbT0i4XuN /o9xwXbqTpv78gXUDvXqG0d2eu2+jM0PzBt4s4Vx+ESFq4vWvmnH1+rqr5N7n45Zbsse MmNE0HdbSceLzcOXZKDejQYxCtKNO6Y91tNiB+tssE1wd43a7ArmpExk8PMiJWAkUn6I 6N7w== 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 89-v6si8253596plc.444.2018.04.30.15.28.01; Mon, 30 Apr 2018 15:28:15 -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 S1755219AbeD3W1i (ORCPT + 99 others); Mon, 30 Apr 2018 18:27:38 -0400 Received: from vps-vb.mhejs.net ([37.28.154.113]:44444 "EHLO vps-vb.mhejs.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755102AbeD3W1h (ORCPT ); Mon, 30 Apr 2018 18:27:37 -0400 Received: by vps-vb.mhejs.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fDHGg-0004CR-PP; Tue, 01 May 2018 00:27:34 +0200 Subject: Re: [PATCH v5 3/6] x86/microcode/AMD: Check microcode container data in the early loader To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org References: <60157b92eef72a73778d9e483b5376db737b5a97.1524515406.git.mail@maciej.szmigiero.name> <20180430090506.GB6509@pd.tnic> From: "Maciej S. Szmigiero" Message-ID: <587188f6-fe91-f2e4-4e41-cb9bc808ecf0@maciej.szmigiero.name> Date: Tue, 1 May 2018 00:27:34 +0200 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: <20180430090506.GB6509@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 30.04.2018 11:05, Borislav Petkov wrote: > On Mon, Apr 23, 2018 at 11:34:08PM +0200, Maciej S. Szmigiero wrote: >> --- a/arch/x86/kernel/cpu/microcode/amd.c >> +++ b/arch/x86/kernel/cpu/microcode/amd.c >> @@ -216,29 +216,33 @@ static bool verify_patch(u8 family, const u8 *buf, size_t buf_size, bool early) >> * Returns the amount of bytes consumed while scanning. @desc contains all the >> * data we're going to use in later stages of the application. >> */ >> -static ssize_t parse_container(u8 *ucode, ssize_t size, struct cont_desc *desc) >> +static size_t parse_container(u8 *ucode, size_t size, struct cont_desc *desc) >> { >> struct equiv_cpu_entry *eq; >> - ssize_t orig_size = size; >> + size_t orig_size = size; >> u32 *hdr = (u32 *)ucode; >> + u32 equiv_tbl_len; >> u16 eq_id; >> u8 *buf; >> >> - /* Am I looking at an equivalence table header? */ >> - if (hdr[0] != UCODE_MAGIC || >> - hdr[1] != UCODE_EQUIV_CPU_TABLE_TYPE || >> - hdr[2] == 0) >> + if (!verify_container(ucode, size, true)) >> + return 0; > > return CONTAINER_HDR_SZ; > > We want to make some forward progress after all. Even if the container file main magic number is wrong? In this case parsing is terminated by returning a zero from the above function. If we want to make the parser more resistant to garbage or forward-compatible to containers with a different main magic number in their headers we probably should return a length of a single byte here instead of 12 (CONTAINER_HDR_SZ) so the parser would correctly skip unknown data of size which isn't an integer multiple of this number. Thanks, Maciej