Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2020-05-13 12:03 p.m., Mimi Zohar wrote:
On Wed, 2020-05-13 at 11:53 -0700, Scott Branden wrote:
Hi Mimi,

On 2020-05-13 11:39 a.m., Mimi Zohar wrote:
[Cc'ing linux-security-module, linux-integrity]

On Thu, 2020-05-07 at 17:27 -0700, Scott Branden wrote:
Add kernel_pread_file* support to kernel to allow for partial read
of files with an offset into the file.  Existing kernel_read_file
functions call new kernel_pread_file functions with offset=0 and
flags=KERNEL_PREAD_FLAG_WHOLE.

Signed-off-by: Scott Branden <scott.branden@xxxxxxxxxxxx>
---
<snip>

@@ -941,14 +955,16 @@ int kernel_read_file(struct file *file, void **buf, loff_t *size,
The checkpatch shows this as kernel_read_file when it is actually the
new function kernel_pread_file.
Please see the call to kernel_pread_file from kernel_read_file in the
complete patch rather this snippet.
if (bytes == 0)
   			break;
+
+		buf_pos += bytes;
   	}
- if (pos != i_size) {
+	if (pos != read_end) {
   		ret = -EIO;
   		goto out_free;
   	}
- ret = security_kernel_post_read_file(file, *buf, i_size, id);
+	ret = security_kernel_post_read_file(file, *buf, alloc_size, id);
   	if (!ret)
   		*size = pos;
Prior to the patch set that introduced this security hook, firmware
would be read twice, once for measuring/appraising the firmware and
again reading the file contents into memory.  Partial reads will break
both IMA's measuring the file and appraising the file signatures.
The partial file read support is needed for request_firmware_into_buf
from drivers.  The EXPORT_SYMBOL_GPL is being removed so that
there can be no abuse of the partial file read support.  Such file
integrity checks are not needed for this use case.  The partial file
(firmware image) is actually downloaded in portions and verified on the
device it is loaded to.
It's all fine that the device will verify the firmware, but shouldn't
the kernel be able to also verify the firmware file signature it is
providing to the device, before providing it?
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.

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.
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.

Mimi




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux