提交 · 38f901735a9e2b3d182fc04a1dfcdb0d3325ea5d · openeuler / Kernel

05 10月, 2020 22 次提交

module: Call security_kernel_post_load_data() · 38f90173

由 Kees Cook 提交于 10月 02, 2020

Now that there is an API for checking loaded contents for modules
loaded without a file, call into the LSM hooks.
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NKP Singh <kpsingh@google.com>
Acked-by: NJessica Yu <jeyu@kernel.org>
Link: https://lore.kernel.org/r/20201002173828.2099543-11-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

38f90173

firmware_loader: Use security_post_load_data() · 4f2d99b0

由 Kees Cook 提交于 10月 02, 2020

Now that security_post_load_data() is wired up, use it instead
of the NULL file argument style of security_post_read_file(),
and update the security_kernel_load_data() call to indicate that a
security_kernel_post_load_data() call is expected.

Wire up the IMA check to match earlier logic. Perhaps a generalized
change to ima_post_load_data() might look something like this:

return process_buffer_measurement(buf, size,
kernel_load_data_id_str(load_id),
read_idmap[load_id] ?: FILE_CHECK,
0, NULL);
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NMimi Zohar <zohar@linux.ibm.com>
Link: https://lore.kernel.org/r/20201002173828.2099543-10-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

4f2d99b0

LSM: Introduce kernel_post_load_data() hook · b64fcae7

由 Kees Cook 提交于 10月 02, 2020

There are a few places in the kernel where LSMs would like to have
visibility into the contents of a kernel buffer that has been loaded or
read. While security_kernel_post_read_file() (which includes the
buffer) exists as a pairing for security_kernel_read_file(), no such
hook exists to pair with security_kernel_load_data().

Earlier proposals for just using security_kernel_post_read_file() with a
NULL file argument were rejected (i.e. "file" should always be valid for
the security_..._file hooks, but it appears at least one case was
left in the kernel during earlier refactoring. (This will be fixed in
a subsequent patch.)

Since not all cases of security_kernel_load_data() can have a single
contiguous buffer made available to the LSM hook (e.g. kexec image
segments are separately loaded), there needs to be a way for the LSM to
reason about its expectations of the hook coverage. In order to handle
this, add a "contents" argument to the "kernel_load_data" hook that
indicates if the newly added "kernel_post_load_data" hook will be called
with the full contents once loaded. That way, LSMs requiring full contents
can choose to unilaterally reject "kernel_load_data" with contents=false
(which is effectively the existing hook coverage), but when contents=true
they can allow it and later evaluate the "kernel_post_load_data" hook
once the buffer is loaded.

With this change, LSMs can gain coverage over non-file-backed data loads
(e.g. init_module(2) and firmware userspace helper), which will happen
in subsequent patches.

Additionally prepare IMA to start processing these cases.
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NKP Singh <kpsingh@google.com>
Link: https://lore.kernel.org/r/20201002173828.2099543-9-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

b64fcae7

fs/kernel_read_file: Add file_size output argument · 88535288

由 Kees Cook 提交于 10月 02, 2020

In preparation for adding partial read support, add an optional output
argument to kernel_read_file*() that reports the file size so callers
can reason more easily about their reading progress.
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NMimi Zohar <zohar@linux.ibm.com>
Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org>
Reviewed-by: NJames Morris <jamorris@linux.microsoft.com>
Acked-by: NScott Branden <scott.branden@broadcom.com>
Link: https://lore.kernel.org/r/20201002173828.2099543-8-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

88535288

fs/kernel_read_file: Switch buffer size arg to size_t · 113eeb51

由 Kees Cook 提交于 10月 02, 2020

In preparation for further refactoring of kernel_read_file*(), rename
the "max_size" argument to the more accurate "buf_size", and correct
its type to size_t. Add kerndoc to explain the specifics of how the
arguments will be used. Note that with buf_size now size_t, it can no
longer be negative (and was never called with a negative value). Adjust
callers to use it as a "maximum size" when *buf is NULL.
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NMimi Zohar <zohar@linux.ibm.com>
Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org>
Reviewed-by: NJames Morris <jamorris@linux.microsoft.com>
Acked-by: NScott Branden <scott.branden@broadcom.com>
Link: https://lore.kernel.org/r/20201002173828.2099543-7-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

113eeb51

fs/kernel_read_file: Remove redundant size argument · f7a4f689

由 Kees Cook 提交于 10月 02, 2020

In preparation for refactoring kernel_read_file*(), remove the redundant
"size" argument which is not needed: it can be included in the return
code, with callers adjusted. (VFS reads already cannot be larger than
INT_MAX.)
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NMimi Zohar <zohar@linux.ibm.com>
Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org>
Reviewed-by: NJames Morris <jamorris@linux.microsoft.com>
Acked-by: NScott Branden <scott.branden@broadcom.com>
Link: https://lore.kernel.org/r/20201002173828.2099543-6-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

f7a4f689

fs/kernel_read_file: Split into separate source file · 5287b07f

由 Kees Cook 提交于 10月 02, 2020

These routines are used in places outside of exec(2), so in preparation
for refactoring them, move them into a separate source file,
fs/kernel_read_file.c.
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NMimi Zohar <zohar@linux.ibm.com>
Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org>
Acked-by: NScott Branden <scott.branden@broadcom.com>
Link: https://lore.kernel.org/r/20201002173828.2099543-5-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

5287b07f

fs/kernel_read_file: Split into separate include file · b89999d0

由 Scott Branden 提交于 10月 02, 2020

Move kernel_read_file* out of linux/fs.h to its own linux/kernel_read_file.h
include file. That header gets pulled in just about everywhere
and doesn't really need functions not related to the general fs interface.
Suggested-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NScott Branden <scott.branden@broadcom.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NMimi Zohar <zohar@linux.ibm.com>
Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NJames Morris <jamorris@linux.microsoft.com>
Link: https://lore.kernel.org/r/20200706232309.12010-2-scott.branden@broadcom.com
Link: https://lore.kernel.org/r/20201002173828.2099543-4-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

b89999d0

fs/kernel_read_file: Remove FIRMWARE_EFI_EMBEDDED enum · 06e67b84

由 Kees Cook 提交于 10月 02, 2020

The "FIRMWARE_EFI_EMBEDDED" enum is a "where", not a "what". It
should not be distinguished separately from just "FIRMWARE", as this
confuses the LSMs about what is being loaded. Additionally, there was
no actual validation of the firmware contents happening.

Fixes: e4c2c0ff ("firmware: Add new platform fallback mechanism and firmware_request_platform()")
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org>
Acked-by: NScott Branden <scott.branden@broadcom.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201002173828.2099543-3-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

06e67b84

fs/kernel_read_file: Remove FIRMWARE_PREALLOC_BUFFER enum · c307459b

由 Kees Cook 提交于 10月 02, 2020

FIRMWARE_PREALLOC_BUFFER is a "how", not a "what", and confuses the LSMs
that are interested in filtering between types of things. The "how"
should be an internal detail made uninteresting to the LSMs.

Fixes: a098ecd2 ("firmware: support loading into a pre-allocated buffer")
Fixes: fd90bc55 ("ima: based on policy verify firmware signatures (pre-allocated buffer)")
Fixes: 4f0496d8 ("ima: based on policy warn about loading firmware (pre-allocated buffer)")
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NMimi Zohar <zohar@linux.ibm.com>
Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org>
Acked-by: NScott Branden <scott.branden@broadcom.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201002173828.2099543-2-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

c307459b

power: supply: Constify static w1_family_ops structs · 6925478c

由 Rikard Falkeborn 提交于 10月 04, 2020

The only usage of these structs is to assign their address to the fops
field in the w1_family struct, which is a const pointer. Make them const
to allow the compiler to put them in read-only memory.

This was done with the following Coccinelle semantic patch
(http://coccinelle.lip6.fr/):

// <smpl>
@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct w1_family_ops i@p = {...};

@ok1@
identifier r1.i;
position p;
identifier s;
@@
static struct w1_family s = {
	.fops=&i@p,
};

@bad1@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad1 disable optional_qualifier@
identifier r1.i;
@@
static
+const
struct w1_family_ops i={};
// </smpl>
Acked-by: NSebastian Reichel <sre@kernel.org>
Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20201004193202.4044-4-rikard.falkeborn@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

6925478c

w1: Constify static w1_family_ops structs · 57de2dfc

由 Rikard Falkeborn 提交于 10月 04, 2020

The only usage of these structs is to assign their address to the fops
field in the w1_family struct, which is a const pointer. Make them const
to allow the compiler to put them in read-only memory.

This was done with the following Coccinelle semantic patch
(http://coccinelle.lip6.fr/):

// <smpl>
@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct w1_family_ops i@p = {...};

@ok1@
identifier r1.i;
position p;
identifier s;
@@
static struct w1_family s = {
	.fops=&i@p,
};

@bad1@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad1 disable optional_qualifier@
identifier r1.i;
@@
static
+const
struct w1_family_ops i={};
// </smpl>
Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20201004193202.4044-3-rikard.falkeborn@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

57de2dfc

w1: Constify struct w1_family_ops · 07f8569f

由 Rikard Falkeborn 提交于 10月 04, 2020

The fops field in the w1_family struct is never modified. Make it const
to indicate that. Constifying the pointer makes it possible for drivers
to declare static w1_family_ops structs const, which in turn will allow
the compiler to put it in read-only memory.
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20201004193202.4044-2-rikard.falkeborn@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

07f8569f

intel_th: pci: Add Alder Lake CPU support · 9f126c56

由 Alexander Shishkin 提交于 10月 05, 2020

This adds support for the Trace Hub in Alder Lake CPU.
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Link: https://lore.kernel.org/r/20201005071319.78508-9-alexander.shishkin@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

9f126c56

intel_th: pci: Add Alder Lake-S support · 951e4d71

由 Alexander Shishkin 提交于 10月 05, 2020

This adds support for the Trace Hub in Alder Lake-S.
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Link: https://lore.kernel.org/r/20201005071319.78508-8-alexander.shishkin@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

951e4d71

stm class: ftrace: Use different channel accroding to CPU · b8f8534b