lkml.org 
[lkml]   [2020]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
From
Date
On Wed, 2020-05-13 at 12:41 -0700, Scott Branden wrote:
>
> On 2020-05-13 12:39 p.m., Mimi Zohar wrote:
> > 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.
> Huh? I said existing functionality is NOT broken by this patch series.

Assuming a system is configured to measure and appraise firmware
(rules below), with this change the firmware file will not be properly
measured and will fail signature verification.

Sample IMA policy rules:
measure func=FIRMWARE_CHECK
appraise func=FIRMWARE_CHECK appraise_type=imasig

Mimi

\
 
 \ /
  Last update: 2020-05-13 23:21    [W:0.086 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site