Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp4654214ybf; Wed, 4 Mar 2020 08:06:45 -0800 (PST) X-Google-Smtp-Source: ADFU+vs4ZOoHbEbDD0amT+Ub8w0FlmxPYJzPgJLlOj0gG5zHy/LnrTdz8FJ1FlmHViIB7pdIeUCL X-Received: by 2002:a9d:638d:: with SMTP id w13mr2964436otk.220.1583338005805; Wed, 04 Mar 2020 08:06:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583338005; cv=none; d=google.com; s=arc-20160816; b=KwP9OOzjtozoEkRQB6CJBdZg6ACtEdKh9g7AzENtCPR7ON1FEMYmQ867tm+IspkRJD cfylZ+vEAPR5Z0mAPGtMZL7/0jOAO88IpOTEbWCjX9BeT2P5nBVqRp5xFe/4o+UZYbUf beGSS9u8Bdn9B8z7q8n+447pXlZ1eUSzbAYZ1LsuxlPdOCWk2dUKIfsShElC/yLFpKhx KhzmAIvZmQdj8u9PxqX2/0t5ta6Ol5N0YZZTGXzz7Lz/4XO6svDdddeDGyOn5tiMxCdy Ysy757H7Bn7h0MWH5VDKTE7oiV76iJp1pCdJ6+FNuDVawZtqci4HLl/pLFJq+Qc9nSKZ VNTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:dkim-signature; bh=rUY8udRQNo9T1W7t0z9MO6yA071FZ3UK1//rz1amElo=; b=KtAN/pfEmmRxnNrKRMbbLA68Q7JVTiGJ9zrAupr/Qu2Xh2JRiaILMgRs+10NJiXTcv lM3XlLnGBn1XZtEdi3uc3zvbTpJ6u/8raIrC2l0A2rxEr9oWlwdGsl0NpjzCzGfhYCSd v+ocFoH8+FWKkWyeXXL7l/jpKBXv9nMwHI2BUvcbqOJrilqtHQALVjLFH/AXjxGztkp+ gYVjqezHD/77VAg7rTjVpibPgMGEsRzkoAGf6G+jamghzMWtJ3UzWyv+Y9RmGMfpReV1 ivACgZUHwp75IYBxLfEfEDC0zpmKBLjSESv2gg2YvrYL0eFLEyYd7I6WmfSyOlry5Kho Zh6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UtJgVF9X; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i8si1345637otr.227.2020.03.04.08.06.32; Wed, 04 Mar 2020 08:06:45 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UtJgVF9X; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729573AbgCDQG0 (ORCPT + 99 others); Wed, 4 Mar 2020 11:06:26 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:20456 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726694AbgCDQGZ (ORCPT ); Wed, 4 Mar 2020 11:06:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583337984; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rUY8udRQNo9T1W7t0z9MO6yA071FZ3UK1//rz1amElo=; b=UtJgVF9Xd2FT1yYsVBBd6r9BlxNFPPjKrsPhjKS2ECsKDoFbZ8c55lC1nN613aKIpQ4zA5 4I84iF0pGz/Hrj/w1jBEavPT4qkqef3sJxOeeuVk7RRrmNatQqHueChBgPGVnvLuFIZloj QyvvTyQgN/Qq7ZAAp189yRoKHUh3nZY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-494-356PBLg5PkKYaRA0mLPPDw-1; Wed, 04 Mar 2020 11:06:22 -0500 X-MC-Unique: 356PBLg5PkKYaRA0mLPPDw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7C8C6DBA6; Wed, 4 Mar 2020 16:06:21 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 712E38B56A; Wed, 4 Mar 2020 16:06:21 +0000 (UTC) Received: from zmail21.collab.prod.int.phx2.redhat.com (zmail21.collab.prod.int.phx2.redhat.com [10.5.83.24]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 60B6586A01; Wed, 4 Mar 2020 16:06:21 +0000 (UTC) Date: Wed, 4 Mar 2020 11:06:21 -0500 (EST) From: Vladis Dronov To: joeyli Cc: Ard Biesheuvel , linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Message-ID: <701521302.13078565.1583337981352.JavaMail.zimbra@redhat.com> In-Reply-To: <20200304140720.GQ16878@linux-l9pv.suse> References: <20200303085528.27658-1-vdronov@redhat.com> <20200304140720.GQ16878@linux-l9pv.suse> Subject: Re: [PATCH] efi: fix a race and a buffer overflow while reading efivars via sysfs MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.40.204.205, 10.4.195.15] Thread-Topic: fix a race and a buffer overflow while reading efivars via sysfs Thread-Index: IH2nruIWMwx9vxI4ZbXE47kW8jiXfg== X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Joey, all, Let me address both of your emails here. > Looks that kernel uses EFI protocol to query variable everytime, then > why should kernel keeps a copy of variable data size, data and attributes in > memory? It makes sense to keep VariableName and VendorGuid, but why data? > > The efi_variable can be used to interactive with userland. But we do not > need to keep a data copy in efi_variable with efivar_entry. e.g. The > efivarfs_file_read() allocates a buffer for reading variable instead > of using efi_variable->Data. Indeed, as far as I understand the code, we keep var's data in a memory. I cannot tell why such was done when this code was written. Given that this code is considered "old" and may even be obsoleted, I wouldn't like to start a deep rewrite, and only focus on fixing bugs, like the one mentioned. > I have reviewed and tested this patch. It's good to me if we still want > to use efi_variable structure as the return buffer of UEFI get/set_variable > protocols. > > Please feel free to add: > Reviewed-by: Joey Lee Thank you for your time on the review! Much appreciated. Still, I've just sent out a v2 patch (with you in To:) which is indeed simpler and implements and idea Ard suggested, and fixes only the exact bug mentioned. I'm not sure which one will be accepted (if any), could you please, to look at v2 also? Best regards, Vladis Dronov | Red Hat, Inc. | The Core Kernel | Senior Software Engineer