Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp813640pxb; Fri, 22 Apr 2022 11:43:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzxVrpfapGi1szXlNix5YQRjNzhLtL4/rUovb29b3JpRWzH5SVuyw92E35lvqWF0TZZ+X5Z X-Received: by 2002:a63:84c7:0:b0:3aa:9fc5:8db6 with SMTP id k190-20020a6384c7000000b003aa9fc58db6mr4977884pgd.375.1650653015336; Fri, 22 Apr 2022 11:43:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650653015; cv=none; d=google.com; s=arc-20160816; b=Wx1SDbjPQ++z4lMFN3I1mTjkEFtvAdcTy/ibzHKbNr8QxU1vm/6kGFUo53O/W6jAkM bSIuv+iJSU3vWSg988T0wdi5K0YqdTHlgarnCEANMjh6Ke3CUhhirTN+jKiRddJpHcBN KODNy2/X8hcMsVH+Xrs8sLAOQOmXWudfXZAwfarPStcPgKHbygmC428mocPkw/7zg6Lb pxBeMSq7dr+J+jO7ol5VhIvpJkGrIL2GNQrpgv9cFTSQ4VqbJa3Aw4Dixrb/McjRtvIc /dYPA4ZIyKfAFWuuqJKjIk8qwfdnuWFGwkfiuiUBCaXBP3h8qF4tg/PJ52YS4R+YwUMj NEmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=49PB6tOA8brwPqcvF/EQOQNQhakvZxUgohiYG8tkm6w=; b=igkM7EwMZQkPqi8815ZKP2rFXWr0CyBJiKXsT+5wu1k62IZcqEKBZb6g8uKTCm9Mib rLYuq6zjskrYTZc6cKi3pT8Q6pyNGd7WOdZLZZo8t67RmtEHbTekk6cHBbSm3+H89Bj3 syHVIBmQLYKPGHEAohhPwsZYp+ZXjhF7Y9JlBiWBgJ/ZA70ydhKbFrb9Ungs9LeS3Jds E006IgJlgzBwAAO9X7AzkUJKQahDMaUMqvXqHPR1Rn6c4UikMhazBHBrVxOQO3yz7oOf dm6z6MCmu573Iq8L3ghZYQt5EGK3X2Ni9AjZdiLqR0dWMVYhWCBaaUSfSdPSIap3ZBvC +tfA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="RmO8Q/g1"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id q10-20020a056a00088a00b005061f41c548si9650421pfj.352.2022.04.22.11.43.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 11:43:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="RmO8Q/g1"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 539D212860B; Fri, 22 Apr 2022 11:12:02 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380882AbiDTRKQ (ORCPT + 99 others); Wed, 20 Apr 2022 13:10:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56354 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356013AbiDTRKL (ORCPT ); Wed, 20 Apr 2022 13:10:11 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 872D2BE15; Wed, 20 Apr 2022 10:07:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 3E621B8210D; Wed, 20 Apr 2022 17:07:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79355C385A1; Wed, 20 Apr 2022 17:07:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1650474442; bh=QAxVP4eS9yUe2My8LiKu9u/E2UpxORATLT2tPbgMn48=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RmO8Q/g16xTHL/UFejqaVxdr/oHqxuONTfP4M47wVeBSn0Gy710Bm2+2hFccoUH0p aebHP9JNC4xtR4K2spDiYH82/Zen8UtXR94yWWGyDn3QBUDKxk7wFdc7WYoq5A3qdr fe8qAJLmkqrvAWeZZUJ1YaZS4CYabd1i72I8CESQ= Date: Wed, 20 Apr 2022 19:07:19 +0200 From: Greg Kroah-Hartman To: =?iso-8859-1?Q?Thi=E9baud?= Weksteen Cc: Luis Chamberlain , Jeffrey Vander Stoep , Saravana Kannan , Alistair Delva , Adam Shih , selinux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] firmware_loader: use kernel credentials when reading firmware Message-ID: References: <20220404054642.3095732-1-tweek@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220404054642.3095732-1-tweek@google.com> X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 04, 2022 at 03:46:42PM +1000, Thi?baud Weksteen wrote: > Device drivers may decide to not load firmware when probed to avoid > slowing down the boot process should the firmware filesystem not be > available yet. In this case, the firmware loading request may be done > when a device file associated with the driver is first accessed. The > credentials of the userspace process accessing the device file may be > used to validate access to the firmware files requested by the driver. > Ensure that the kernel assumes the responsibility of reading the > firmware. > > This was observed on Android for a graphic driver loading their firmware > when the device file (e.g. /dev/mali0) was first opened by userspace > (i.e. surfaceflinger). The security context of surfaceflinger was used > to validate the access to the firmware file (e.g. > /vendor/firmware/mali.bin). > > Because previous configurations were relying on the userspace fallback > mechanism, the security context of the userspace daemon (i.e. ueventd) > was consistently used to read firmware files. More devices are found to > use the command line argument firmware_class.path which gives the kernel > the opportunity to read the firmware directly, hence surfacing this > misattribution. > > Signed-off-by: Thi?baud Weksteen > --- > drivers/base/firmware_loader/main.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c > index 94d1789a233e..416ee3cc6584 100644 > --- a/drivers/base/firmware_loader/main.c > +++ b/drivers/base/firmware_loader/main.c > @@ -735,6 +735,8 @@ _request_firmware(const struct firmware **firmware_p, const char *name, > size_t offset, u32 opt_flags) > { > struct firmware *fw = NULL; > + struct cred *kern_cred = NULL; > + const struct cred *old_cred; > bool nondirect = false; > int ret; > > @@ -751,6 +753,13 @@ _request_firmware(const struct firmware **firmware_p, const char *name, > if (ret <= 0) /* error or already assigned */ > goto out; > > + kern_cred = prepare_kernel_cred(NULL); > + if (!kern_cred) { > + ret = -ENOMEM; > + goto out; > + } > + old_cred = override_creds(kern_cred); Can you add a comment here before the call to prepare_kernel_cred() to say why you are doing this and what it is for? Otherwise it is not obvious at all. thanks, greg k-h