[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1589398747.5098.178.camel@kernel.org>
Date: Wed, 13 May 2020 15:39:07 -0400
From: Mimi Zohar <zohar@...nel.org>
To: Scott Branden <scott.branden@...adcom.com>,
Luis Chamberlain <mcgrof@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
David Brown <david.brown@...aro.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Shuah Khan <shuah@...nel.org>, bjorn.andersson@...aro.org,
Shuah Khan <skhan@...uxfoundation.org>,
Arnd Bergmann <arnd@...db.de>
Cc: "Rafael J . Wysocki" <rafael@...nel.org>,
linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>,
Olof Johansson <olof@...om.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Dan Carpenter <dan.carpenter@...cle.com>,
Colin Ian King <colin.king@...onical.com>,
Kees Cook <keescook@...omium.org>,
Takashi Iwai <tiwai@...e.de>, linux-kselftest@...r.kernel.org,
Andy Gross <agross@...nel.org>,
linux-security-module <linux-security-module@...r.kernel.org>,
linux-integrity <linux-integrity@...r.kernel.org>
Subject: Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
On Wed, 2020-05-13 at 12:18 -0700, Scott Branden wrote:
> On 2020-05-13 12:03 p.m., Mimi Zohar wrote:
> > On Wed, 2020-05-13 at 11:53 -0700, Scott Branden wrote:
> Even if the kernel successfully verified the firmware file signature it
> would just be wasting its time. The kernel in these use cases is not always
> trusted. The device needs to authenticate the firmware image itself.
There are also environments where the kernel is trusted and limits the
firmware being provided to the device to one which they signed.
> > The device firmware is being downloaded piecemeal from somewhere and
> > won't be measured?
> It doesn't need to be measured for current driver needs.
Sure the device doesn't need the kernel measuring the firmware, but
hardened environments do measure firmware.
> If someone has such need the infrastructure could be added to the kernel
> at a later date. Existing functionality is not broken in any way by
> this patch series.
Wow! You're saying that your patch set takes precedence over the
existing expectations and can break them.
Mimi
Powered by blists - more mailing lists