* [PATCH v6 09/10] drivers/perf: open access for CAP_PERFMON privileged process
From: Alexey Budankov @ 2020-01-28 6:13 UTC (permalink / raw)
To: Peter Zijlstra, Arnaldo Carvalho de Melo, Ingo Molnar,
benh@kernel.crashing.org, Paul Mackerras, Michael Ellerman,
james.bottomley@hansenpartnership.com, Serge Hallyn, Will Deacon,
Robert Richter, Alexei Starovoitov
Cc: intel-gfx@lists.freedesktop.org, Jiri Olsa, Andi Kleen,
Stephane Eranian, Igor Lubashev, Alexander Shishkin, Namhyung Kim,
Song Liu, Lionel Landwerlin, linux-kernel,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, linux-perf-users@vger.kernel.org,
oprofile-list
In-Reply-To: <74d524ab-ac11-a7b8-1052-eba10f117e09@linux.intel.com>
Open access to monitoring for CAP_PERFMON privileged process.
Providing the access under CAP_PERFMON capability singly, without the
rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
credentials and makes operation more secure.
CAP_PERFMON implements the principal of least privilege for performance
monitoring and observability operations (POSIX IEEE 1003.1e 2.2.2.39 principle
of least privilege: A security design principle that states that a process
or program be granted only those privileges (e.g., capabilities) necessary
to accomplish its legitimate function, and only for the time that such
privileges are actually required)
For backward compatibility reasons access to the monitoring remains open
for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure
monitoring is discouraged with respect to CAP_PERFMON capability.
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
---
drivers/perf/arm_spe_pmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
index 4e4984a55cd1..5dff81bc3324 100644
--- a/drivers/perf/arm_spe_pmu.c
+++ b/drivers/perf/arm_spe_pmu.c
@@ -274,7 +274,7 @@ static u64 arm_spe_event_to_pmscr(struct perf_event *event)
if (!attr->exclude_kernel)
reg |= BIT(SYS_PMSCR_EL1_E1SPE_SHIFT);
- if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && capable(CAP_SYS_ADMIN))
+ if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && perfmon_capable())
reg |= BIT(SYS_PMSCR_EL1_CX_SHIFT);
return reg;
@@ -700,7 +700,7 @@ static int arm_spe_pmu_event_init(struct perf_event *event)
return -EOPNOTSUPP;
reg = arm_spe_event_to_pmscr(event);
- if (!capable(CAP_SYS_ADMIN) &&
+ if (!perfmon_capable() &&
(reg & (BIT(SYS_PMSCR_EL1_PA_SHIFT) |
BIT(SYS_PMSCR_EL1_CX_SHIFT) |
BIT(SYS_PMSCR_EL1_PCT_SHIFT))))
--
2.20.1
^ permalink raw reply related
* [PATCH v6 10/10] drivers/oprofile: open access for CAP_PERFMON privileged process
From: Alexey Budankov @ 2020-01-28 6:14 UTC (permalink / raw)
To: Peter Zijlstra, Arnaldo Carvalho de Melo, Ingo Molnar,
benh@kernel.crashing.org, Paul Mackerras, Michael Ellerman,
james.bottomley@hansenpartnership.com, Serge Hallyn, Will Deacon,
Robert Richter, Alexei Starovoitov
Cc: intel-gfx@lists.freedesktop.org, Jiri Olsa, Andi Kleen,
Stephane Eranian, Igor Lubashev, Alexander Shishkin, Namhyung Kim,
Song Liu, Lionel Landwerlin, linux-kernel,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, linux-perf-users@vger.kernel.org,
oprofile-list
In-Reply-To: <74d524ab-ac11-a7b8-1052-eba10f117e09@linux.intel.com>
Open access to monitoring for CAP_PERFMON privileged process. Providing
the access under CAP_PERFMON capability singly, without the rest of
CAP_SYS_ADMIN credentials, excludes chances to misuse the credentials and
makes operation more secure.
CAP_PERFMON implements the principal of least privilege for performance
monitoring and observability operations (POSIX IEEE 1003.1e 2.2.2.39 principle
of least privilege: A security design principle that states that a process
or program be granted only those privileges (e.g., capabilities) necessary
to accomplish its legitimate function, and only for the time that such
privileges are actually required)
For backward compatibility reasons access to the monitoring remains open
for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure
monitoring is discouraged with respect to CAP_PERFMON capability.
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
---
drivers/oprofile/event_buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/oprofile/event_buffer.c b/drivers/oprofile/event_buffer.c
index 12ea4a4ad607..6c9edc8bbc95 100644
--- a/drivers/oprofile/event_buffer.c
+++ b/drivers/oprofile/event_buffer.c
@@ -113,7 +113,7 @@ static int event_buffer_open(struct inode *inode, struct file *file)
{
int err = -EPERM;
- if (!capable(CAP_SYS_ADMIN))
+ if (!perfmon_capable())
return -EPERM;
if (test_and_set_bit_lock(0, &buffer_opened))
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v7 02/11] proc: add proc_fs_info struct to store proc information
From: Oleg Nesterov @ 2020-01-28 13:43 UTC (permalink / raw)
To: Alexey Gladkov
Cc: LKML, Kernel Hardening, Linux API, Linux FS Devel,
Linux Security Module, Akinobu Mita, Alexander Viro,
Alexey Dobriyan, Andrew Morton, Andy Lutomirski, Daniel Micay,
Djalal Harouni, Dmitry V . Levin, Eric W . Biederman,
Greg Kroah-Hartman, Ingo Molnar, J . Bruce Fields, Jeff Layton,
Jonathan Corbet, Kees Cook, Linus Torvalds, Solar Designer,
Stephen Rothwell
In-Reply-To: <20200125130541.450409-3-gladkov.alexey@gmail.com>
On 01/25, Alexey Gladkov wrote:
>
> static int proc_init_fs_context(struct fs_context *fc)
> {
> struct proc_fs_context *ctx;
> + struct pid_namespace *pid_ns;
>
> ctx = kzalloc(sizeof(struct proc_fs_context), GFP_KERNEL);
> if (!ctx)
> return -ENOMEM;
>
> - ctx->pid_ns = get_pid_ns(task_active_pid_ns(current));
> + pid_ns = get_pid_ns(task_active_pid_ns(current));
> +
> + if (!pid_ns->proc_mnt) {
> + ctx->fs_info = kzalloc(sizeof(struct proc_fs_info), GFP_KERNEL);
> + if (!ctx->fs_info) {
> + kfree(ctx);
> + return -ENOMEM;
> + }
> + ctx->fs_info->pid_ns = pid_ns;
> + } else {
> + ctx->fs_info = proc_sb_info(pid_ns->proc_mnt->mnt_sb);
> + }
> +
it seems that this code lacks put_pid_ns() if pid_ns->proc_mnt != NULL
or if kzalloc() fails?
Or, better,
pid_ns = task_active_pid_ns();
if (!pid_ns->proc_mnt) {
ctx->fs_info = kzalloc();
...
ctx->fs_info->pid_ns = get_pid_ns(pid_ns);
}
No?
Oleg.
^ permalink raw reply
* Re: [PATCH v7 02/11] proc: add proc_fs_info struct to store proc information
From: Oleg Nesterov @ 2020-01-28 14:58 UTC (permalink / raw)
To: Alexey Gladkov
Cc: LKML, Kernel Hardening, Linux API, Linux FS Devel,
Linux Security Module, Akinobu Mita, Alexander Viro,
Alexey Dobriyan, Andrew Morton, Andy Lutomirski, Daniel Micay,
Djalal Harouni, Dmitry V . Levin, Eric W . Biederman,
Greg Kroah-Hartman, Ingo Molnar, J . Bruce Fields, Jeff Layton,
Jonathan Corbet, Kees Cook, Linus Torvalds, Solar Designer,
Stephen Rothwell
In-Reply-To: <20200128134337.GC17943@redhat.com>
On 01/28, Oleg Nesterov wrote:
>
> On 01/25, Alexey Gladkov wrote:
> >
> > static int proc_init_fs_context(struct fs_context *fc)
> > {
> > struct proc_fs_context *ctx;
> > + struct pid_namespace *pid_ns;
> >
> > ctx = kzalloc(sizeof(struct proc_fs_context), GFP_KERNEL);
> > if (!ctx)
> > return -ENOMEM;
> >
> > - ctx->pid_ns = get_pid_ns(task_active_pid_ns(current));
> > + pid_ns = get_pid_ns(task_active_pid_ns(current));
> > +
> > + if (!pid_ns->proc_mnt) {
> > + ctx->fs_info = kzalloc(sizeof(struct proc_fs_info), GFP_KERNEL);
> > + if (!ctx->fs_info) {
> > + kfree(ctx);
> > + return -ENOMEM;
> > + }
> > + ctx->fs_info->pid_ns = pid_ns;
> > + } else {
> > + ctx->fs_info = proc_sb_info(pid_ns->proc_mnt->mnt_sb);
> > + }
> > +
>
> it seems that this code lacks put_pid_ns() if pid_ns->proc_mnt != NULL
> or if kzalloc() fails?
OK, this is fixed in 6/11.
Oleg.
^ permalink raw reply
* Re: [PATCH v6 01/10] capabilities: introduce CAP_PERFMON to kernel and user space
From: James Morris @ 2020-01-28 21:16 UTC (permalink / raw)
To: Alexey Budankov
Cc: Peter Zijlstra, Arnaldo Carvalho de Melo, Ingo Molnar,
benh@kernel.crashing.org, Paul Mackerras, Michael Ellerman,
james.bottomley@hansenpartnership.com, Serge Hallyn, Will Deacon,
Robert Richter, Alexei Starovoitov,
intel-gfx@lists.freedesktop.org, Jiri Olsa, Andi Kleen,
Stephane Eranian, Igor Lubashev, Alexander Shishkin, Namhyung Kim,
Song Liu, Lionel Landwerlin, linux-kernel,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, linux-perf-users@vger.kernel.org,
oprofile-list
In-Reply-To: <62274abc-6067-9121-9397-c9b626ca5f7a@linux.intel.com>
On Tue, 28 Jan 2020, Alexey Budankov wrote:
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
> ---
> include/linux/capability.h | 4 ++++
> include/uapi/linux/capability.h | 8 +++++++-
> security/selinux/include/classmap.h | 4 ++--
> 3 files changed, 13 insertions(+), 3 deletions(-)
Acked-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v6 03/10] perf/core: open access to probes for CAP_PERFMON privileged process
From: James Morris @ 2020-01-28 21:16 UTC (permalink / raw)
To: Alexey Budankov
Cc: Peter Zijlstra, Arnaldo Carvalho de Melo, Ingo Molnar,
benh@kernel.crashing.org, Paul Mackerras, Michael Ellerman,
james.bottomley@hansenpartnership.com, Serge Hallyn, Will Deacon,
Robert Richter, Alexei Starovoitov,
intel-gfx@lists.freedesktop.org, Jiri Olsa, Andi Kleen,
Stephane Eranian, Igor Lubashev, Alexander Shishkin, Namhyung Kim,
Song Liu, Lionel Landwerlin, linux-kernel,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, linux-perf-users@vger.kernel.org,
oprofile-list
In-Reply-To: <6cdc10f2-31e5-6d71-7d71-c6b5250b74f1@linux.intel.com>
On Tue, 28 Jan 2020, Alexey Budankov wrote:
>
> Open access to monitoring via kprobes and uprobes and eBPF tracing for
> CAP_PERFMON privileged process. Providing the access under CAP_PERFMON
> capability singly, without the rest of CAP_SYS_ADMIN credentials, excludes
> chances to misuse the credentials and makes operation more secure.
>
> perf kprobes and uprobes are used by ftrace and eBPF. perf probe uses
> ftrace to define new kprobe events, and those events are treated as
> tracepoint events. eBPF defines new probes via perf_event_open interface
> and then the probes are used in eBPF tracing.
>
> CAP_PERFMON implements the principal of least privilege for performance
> monitoring and observability operations (POSIX IEEE 1003.1e 2.2.2.39 principle
> of least privilege: A security design principle that states that a process or
> program be granted only those privileges (e.g., capabilities) necessary to
> accomplish its legitimate function, and only for the time that such privileges
> are actually required)
>
> For backward compatibility reasons access to perf_events subsystem remains
> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for
> secure perf_events monitoring is discouraged with respect to CAP_PERFMON
> capability.
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
> ---
> kernel/events/core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v6 06/10] trace/bpf_trace: open access for CAP_PERFMON privileged process
From: James Morris @ 2020-01-28 21:17 UTC (permalink / raw)
To: Alexey Budankov
Cc: Peter Zijlstra, Arnaldo Carvalho de Melo, Ingo Molnar,
benh@kernel.crashing.org, Paul Mackerras, Michael Ellerman,
james.bottomley@hansenpartnership.com, Serge Hallyn, Will Deacon,
Robert Richter, Alexei Starovoitov,
intel-gfx@lists.freedesktop.org, Jiri Olsa, Andi Kleen,
Stephane Eranian, Igor Lubashev, Alexander Shishkin, Namhyung Kim,
Song Liu, Lionel Landwerlin, linux-kernel,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, linux-perf-users@vger.kernel.org,
oprofile-list
In-Reply-To: <4fdbe164-d83d-a52f-4e8c-fe8bd15c6f8c@linux.intel.com>
On Tue, 28 Jan 2020, Alexey Budankov wrote:
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
> ---
> kernel/trace/bpf_trace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index e5ef4ae9edb5..334f1d71ebb1 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -1395,7 +1395,7 @@ int perf_event_query_prog_array(struct perf_event *event, void __user *info)
> u32 *ids, prog_cnt, ids_len;
> int ret;
>
> - if (!capable(CAP_SYS_ADMIN))
> + if (!perfmon_capable())
> return -EPERM;
> if (event->attr.type != PERF_TYPE_TRACEPOINT)
> return -EINVAL;
>
Acked-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v6 07/10] powerpc/perf: open access for CAP_PERFMON privileged process
From: James Morris @ 2020-01-28 21:17 UTC (permalink / raw)
To: Alexey Budankov
Cc: Peter Zijlstra, Arnaldo Carvalho de Melo, Ingo Molnar,
benh@kernel.crashing.org, Paul Mackerras, Michael Ellerman,
james.bottomley@hansenpartnership.com, Serge Hallyn, Will Deacon,
Robert Richter, Alexei Starovoitov,
intel-gfx@lists.freedesktop.org, Jiri Olsa, Andi Kleen,
Stephane Eranian, Igor Lubashev, Alexander Shishkin, Namhyung Kim,
Song Liu, Lionel Landwerlin, linux-kernel,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, linux-perf-users@vger.kernel.org,
oprofile-list
In-Reply-To: <3ce8fc61-a61f-5efc-9167-94f5d39b6f1b@linux.intel.com>
On Tue, 28 Jan 2020, Alexey Budankov wrote:
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
> ---
> arch/powerpc/perf/imc-pmu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
> index cb50a9e1fd2d..e837717492e4 100644
> --- a/arch/powerpc/perf/imc-pmu.c
> +++ b/arch/powerpc/perf/imc-pmu.c
> @@ -898,7 +898,7 @@ static int thread_imc_event_init(struct perf_event *event)
> if (event->attr.type != event->pmu->type)
> return -ENOENT;
>
> - if (!capable(CAP_SYS_ADMIN))
> + if (!perfmon_capable())
> return -EACCES;
>
> /* Sampling not supported */
> @@ -1307,7 +1307,7 @@ static int trace_imc_event_init(struct perf_event *event)
> if (event->attr.type != event->pmu->type)
> return -ENOENT;
>
> - if (!capable(CAP_SYS_ADMIN))
> + if (!perfmon_capable())
> return -EACCES;
>
> /* Return if this is a couting event */
>
Acked-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v6 08/10] parisc/perf: open access for CAP_PERFMON privileged process
From: James Morris @ 2020-01-28 21:17 UTC (permalink / raw)
To: Alexey Budankov
Cc: Peter Zijlstra, Arnaldo Carvalho de Melo, Ingo Molnar,
benh@kernel.crashing.org, Paul Mackerras, Michael Ellerman,
james.bottomley@hansenpartnership.com, Serge Hallyn, Will Deacon,
Robert Richter, Alexei Starovoitov,
intel-gfx@lists.freedesktop.org, Jiri Olsa, Andi Kleen,
Stephane Eranian, Igor Lubashev, Alexander Shishkin, Namhyung Kim,
Song Liu, Lionel Landwerlin, linux-kernel,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, linux-perf-users@vger.kernel.org,
oprofile-list
In-Reply-To: <17be72ff-dc52-72ef-fbcc-0e9ec8b61604@linux.intel.com>
On Tue, 28 Jan 2020, Alexey Budankov wrote:
>
> Open access to monitoring for CAP_PERFMON privileged process.
> Providing the access under CAP_PERFMON capability singly, without the
> rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
> credentials and makes operation more secure.
>
> CAP_PERFMON implements the principal of least privilege for performance
> monitoring and observability operations (POSIX IEEE 1003.1e 2.2.2.39 principle
> of least privilege: A security design principle that states that a process
> or program be granted only those privileges (e.g., capabilities) necessary
> to accomplish its legitimate function, and only for the time that such
> privileges are actually required)
>
> For backward compatibility reasons access to the monitoring remains open
> for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure
> monitoring is discouraged with respect to CAP_PERFMON capability.
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
> ---
> arch/parisc/kernel/perf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/parisc/kernel/perf.c b/arch/parisc/kernel/perf.c
> index 676683641d00..c4208d027794 100644
> --- a/arch/parisc/kernel/perf.c
> +++ b/arch/parisc/kernel/perf.c
> @@ -300,7 +300,7 @@ static ssize_t perf_write(struct file *file, const char __user *buf,
> else
> return -EFAULT;
>
> - if (!capable(CAP_SYS_ADMIN))
> + if (!perfmon_capable())
> return -EACCES;
>
> if (count != sizeof(uint32_t))
>
Acked-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v6 09/10] drivers/perf: open access for CAP_PERFMON privileged process
From: James Morris @ 2020-01-28 21:18 UTC (permalink / raw)
To: Alexey Budankov
Cc: Peter Zijlstra, Arnaldo Carvalho de Melo, Ingo Molnar,
benh@kernel.crashing.org, Paul Mackerras, Michael Ellerman,
james.bottomley@hansenpartnership.com, Serge Hallyn, Will Deacon,
Robert Richter, Alexei Starovoitov,
intel-gfx@lists.freedesktop.org, Jiri Olsa, Andi Kleen,
Stephane Eranian, Igor Lubashev, Alexander Shishkin, Namhyung Kim,
Song Liu, Lionel Landwerlin, linux-kernel,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, linux-perf-users@vger.kernel.org,
oprofile-list
In-Reply-To: <f2877038-da53-f981-4ddb-4e6c1c27c60f@linux.intel.com>
On Tue, 28 Jan 2020, Alexey Budankov wrote:
>
> Open access to monitoring for CAP_PERFMON privileged process.
> Providing the access under CAP_PERFMON capability singly, without the
> rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
> credentials and makes operation more secure.
>
> CAP_PERFMON implements the principal of least privilege for performance
> monitoring and observability operations (POSIX IEEE 1003.1e 2.2.2.39 principle
> of least privilege: A security design principle that states that a process
> or program be granted only those privileges (e.g., capabilities) necessary
> to accomplish its legitimate function, and only for the time that such
> privileges are actually required)
>
> For backward compatibility reasons access to the monitoring remains open
> for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure
> monitoring is discouraged with respect to CAP_PERFMON capability.
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
> ---
> drivers/perf/arm_spe_pmu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Acked-by: James Morris <jamorris@linux.microsoft.com>
> diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
> index 4e4984a55cd1..5dff81bc3324 100644
> --- a/drivers/perf/arm_spe_pmu.c
> +++ b/drivers/perf/arm_spe_pmu.c
> @@ -274,7 +274,7 @@ static u64 arm_spe_event_to_pmscr(struct perf_event *event)
> if (!attr->exclude_kernel)
> reg |= BIT(SYS_PMSCR_EL1_E1SPE_SHIFT);
>
> - if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && capable(CAP_SYS_ADMIN))
> + if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && perfmon_capable())
> reg |= BIT(SYS_PMSCR_EL1_CX_SHIFT);
>
> return reg;
> @@ -700,7 +700,7 @@ static int arm_spe_pmu_event_init(struct perf_event *event)
> return -EOPNOTSUPP;
>
> reg = arm_spe_event_to_pmscr(event);
> - if (!capable(CAP_SYS_ADMIN) &&
> + if (!perfmon_capable() &&
> (reg & (BIT(SYS_PMSCR_EL1_PA_SHIFT) |
> BIT(SYS_PMSCR_EL1_CX_SHIFT) |
> BIT(SYS_PMSCR_EL1_PCT_SHIFT))))
>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v6 10/10] drivers/oprofile: open access for CAP_PERFMON privileged process
From: James Morris @ 2020-01-28 21:18 UTC (permalink / raw)
To: Alexey Budankov
Cc: Peter Zijlstra, Arnaldo Carvalho de Melo, Ingo Molnar,
benh@kernel.crashing.org, Paul Mackerras, Michael Ellerman,
james.bottomley@hansenpartnership.com, Serge Hallyn, Will Deacon,
Robert Richter, Alexei Starovoitov,
intel-gfx@lists.freedesktop.org, Jiri Olsa, Andi Kleen,
Stephane Eranian, Igor Lubashev, Alexander Shishkin, Namhyung Kim,
Song Liu, Lionel Landwerlin, linux-kernel,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, linux-perf-users@vger.kernel.org,
oprofile-list
In-Reply-To: <eff5e211-7114-f854-f53f-08491f9dcc26@linux.intel.com>
On Tue, 28 Jan 2020, Alexey Budankov wrote:
>
> Open access to monitoring for CAP_PERFMON privileged process. Providing
> the access under CAP_PERFMON capability singly, without the rest of
> CAP_SYS_ADMIN credentials, excludes chances to misuse the credentials and
> makes operation more secure.
>
> CAP_PERFMON implements the principal of least privilege for performance
> monitoring and observability operations (POSIX IEEE 1003.1e 2.2.2.39 principle
> of least privilege: A security design principle that states that a process
> or program be granted only those privileges (e.g., capabilities) necessary
> to accomplish its legitimate function, and only for the time that such
> privileges are actually required)
>
> For backward compatibility reasons access to the monitoring remains open
> for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure
> monitoring is discouraged with respect to CAP_PERFMON capability.
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
> ---
> drivers/oprofile/event_buffer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: James Morris <jamorris@linux.microsoft.com>
>
> diff --git a/drivers/oprofile/event_buffer.c b/drivers/oprofile/event_buffer.c
> index 12ea4a4ad607..6c9edc8bbc95 100644
> --- a/drivers/oprofile/event_buffer.c
> +++ b/drivers/oprofile/event_buffer.c
> @@ -113,7 +113,7 @@ static int event_buffer_open(struct inode *inode, struct file *file)
> {
> int err = -EPERM;
>
> - if (!capable(CAP_SYS_ADMIN))
> + if (!perfmon_capable())
> return -EPERM;
>
> if (test_and_set_bit_lock(0, &buffer_opened))
>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [GIT PULL] Security subsystem changes for v5.6
From: James Morris @ 2020-01-28 21:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-security-module, linux-kernel
Just one minor fix this time. Please pull.
The following changes since commit 219d54332a09e8d8741c1e1982f5eae56099de85:
Linux 5.4 (2019-11-24 16:32:01 -0800)
are available in the Git repository at:
git://git.kernel.org:/pub/scm/linux/kernel/git/jmorris/linux-security for-v5.6
for you to fetch changes up to 10c2d111c906599942efd13109061885631c4a0c:
security: remove EARLY_LSM_COUNT which never used (2020-01-27 11:19:41 -0800)
----------------------------------------------------------------
Alex Shi (1):
security: remove EARLY_LSM_COUNT which never used
security/security.c | 1 -
1 file changed, 1 deletion(-)
---
commit 10c2d111c906599942efd13109061885631c4a0c
Author: Alex Shi <alex.shi@linux.alibaba.com>
Date: Tue Jan 21 16:50:03 2020 +0800
security: remove EARLY_LSM_COUNT which never used
This macro is never used from it was introduced in commit e6b1db98cf4d5
("security: Support early LSMs"), better to remove it.
Signed-off-by: Alex Shi <alex.shi@linux.alibaba.com>
Acked-by: Serge Hallyn <serge@hallyn.com>
Signed-off-by: James Morris <jmorris@namei.org>
diff --git a/security/security.c b/security/security.c
index 1bc000f834e2..344bf1327d7e 100644
--- a/security/security.c
+++ b/security/security.c
@@ -33,7 +33,6 @@
/* How many LSMs were built into the kernel? */
#define LSM_COUNT (__end_lsm_info - __start_lsm_info)
-#define EARLY_LSM_COUNT (__end_early_lsm_info - __start_early_lsm_info)
struct security_hook_heads security_hook_heads __lsm_ro_after_init;
static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain);
^ permalink raw reply related
* Re: [GIT PULL] TOMOYO patches for v5.6
From: Linus Torvalds @ 2020-01-29 2:51 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: linux-security-module
In-Reply-To: <cdf30cd3-8b0e-9014-0474-ce978e6bcc3b@i-love.sakura.ne.jp>
On Mon, Jan 27, 2020 at 8:17 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> One "int -> atomic_t" conversion patch for suppressing KCSAN's warning.
The git tree looks fine, and I've pulled, but your pull request was
missing the shortlog and diffstat that I expect (and that "git
request-pull" generates).
Linus
^ permalink raw reply
* Re: [GIT PULL] Security subsystem changes for v5.6
From: pr-tracker-bot @ 2020-01-29 3:00 UTC (permalink / raw)
To: James Morris; +Cc: Linus Torvalds, linux-security-module, linux-kernel
In-Reply-To: <alpine.LRH.2.21.2001290823510.4816@namei.org>
The pull request you sent on Wed, 29 Jan 2020 08:24:55 +1100 (AEDT):
> git://git.kernel.org:/pub/scm/linux/kernel/git/jmorris/linux-security for-v5.6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b3a6082223369203d7e7db7e81253ac761377644
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [GIT PULL] TOMOYO patches for v5.6
From: pr-tracker-bot @ 2020-01-29 3:00 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: Linus Torvalds, linux-security-module
In-Reply-To: <cdf30cd3-8b0e-9014-0474-ce978e6bcc3b@i-love.sakura.ne.jp>
The pull request you sent on Tue, 28 Jan 2020 13:17:03 +0900:
> git://git.osdn.net/gitroot/tomoyo/tomoyo-test1.git tags/tomoyo-pr-20200128
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2cf64d7cb20b04cf25e4ebffc37833298f1d4bde
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: mmotm 2020-01-28-20-05 uploaded (security/security.c)
From: Randy Dunlap @ 2020-01-29 4:52 UTC (permalink / raw)
To: akpm, broonie, linux-fsdevel, linux-kernel, linux-mm, linux-next,
mhocko, mm-commits, sfr, linux-security-module, James Morris,
Serge E. Hallyn
In-Reply-To: <20200129040640.6PNuz0vcp%akpm@linux-foundation.org>
On 1/28/20 8:06 PM, akpm@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2020-01-28-20-05 has been uploaded to
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my -mm patch queue. Uploaded at random hopefully
> more than once a week.
>
security/security.c contains duplicate lines for <lockdown_reasons> array:
/*
* These are descriptions of the reasons that can be passed to the
* security_locked_down() LSM hook. Placing this array here allows
* all security modules to use the same descriptions for auditing
* purposes.
*/
const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
[LOCKDOWN_NONE] = "none",
[LOCKDOWN_MODULE_SIGNATURE] = "unsigned module loading",
[LOCKDOWN_DEV_MEM] = "/dev/mem,kmem,port",
[LOCKDOWN_EFI_TEST] = "/dev/efi_test access",
[LOCKDOWN_KEXEC] = "kexec of unsigned images",
[LOCKDOWN_HIBERNATION] = "hibernation",
[LOCKDOWN_PCI_ACCESS] = "direct PCI access",
[LOCKDOWN_IOPORT] = "raw io port access",
[LOCKDOWN_MSR] = "raw MSR access",
[LOCKDOWN_ACPI_TABLES] = "modifying ACPI tables",
[LOCKDOWN_PCMCIA_CIS] = "direct PCMCIA CIS storage",
[LOCKDOWN_TIOCSSERIAL] = "reconfiguration of serial port IO",
[LOCKDOWN_MODULE_PARAMETERS] = "unsafe module parameters",
[LOCKDOWN_MMIOTRACE] = "unsafe mmio",
[LOCKDOWN_DEBUGFS] = "debugfs access",
[LOCKDOWN_XMON_WR] = "xmon write access",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_KCORE] = "/proc/kcore access",
[LOCKDOWN_KPROBES] = "use of kprobes",
[LOCKDOWN_BPF_READ] = "use of bpf to read kernel RAM",
[LOCKDOWN_PERF] = "unsafe use of perf",
[LOCKDOWN_TRACEFS] = "use of tracefs",
[LOCKDOWN_XMON_RW] = "xmon read and write access",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
};
/*
* These are descriptions of the reasons that can be passed to the
* security_locked_down() LSM hook. Placing this array here allows
* all security modules to use the same descriptions for auditing
* purposes.
*/
const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
[LOCKDOWN_NONE] = "none",
[LOCKDOWN_MODULE_SIGNATURE] = "unsigned module loading",
[LOCKDOWN_DEV_MEM] = "/dev/mem,kmem,port",
[LOCKDOWN_EFI_TEST] = "/dev/efi_test access",
[LOCKDOWN_KEXEC] = "kexec of unsigned images",
[LOCKDOWN_HIBERNATION] = "hibernation",
[LOCKDOWN_PCI_ACCESS] = "direct PCI access",
[LOCKDOWN_IOPORT] = "raw io port access",
[LOCKDOWN_MSR] = "raw MSR access",
[LOCKDOWN_ACPI_TABLES] = "modifying ACPI tables",
[LOCKDOWN_PCMCIA_CIS] = "direct PCMCIA CIS storage",
[LOCKDOWN_TIOCSSERIAL] = "reconfiguration of serial port IO",
[LOCKDOWN_MODULE_PARAMETERS] = "unsafe module parameters",
[LOCKDOWN_MMIOTRACE] = "unsafe mmio",
[LOCKDOWN_DEBUGFS] = "debugfs access",
[LOCKDOWN_XMON_WR] = "xmon write access",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_KCORE] = "/proc/kcore access",
[LOCKDOWN_KPROBES] = "use of kprobes",
[LOCKDOWN_BPF_READ] = "use of bpf to read kernel RAM",
[LOCKDOWN_PERF] = "unsafe use of perf",
[LOCKDOWN_TRACEFS] = "use of tracefs",
[LOCKDOWN_XMON_RW] = "xmon read and write access",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
};
Stephen, you might delete half of those for linux-next....
--
~Randy
^ permalink raw reply
* Re: [PATCH 1/8] tpm: initialize crypto_id of allocated_banks to HASH_ALGO__LAST
From: Petr Vorel @ 2020-01-29 8:39 UTC (permalink / raw)
To: Roberto Sassu
Cc: zohar, jarkko.sakkinen, james.bottomley, linux-integrity,
linux-security-module, linux-kernel, silviu.vlasceanu
In-Reply-To: <20200127170443.21538-2-roberto.sassu@huawei.com>
Hi Roberto,
> chip->allocated_banks contains the list of TPM algorithm IDs of allocated
> PCR banks. It also contains the corresponding ID of the crypto subsystem,
> so that users of the TPM driver can calculate a digest for a PCR extend
> operation.
> However, if there is no mapping between TPM algorithm ID and crypto ID, the
> crypto_id field in chip->allocated_banks remains set to zero (the array is
> allocated and initialized with kcalloc() in tpm2_get_pcr_allocation()).
> Zero should not be used as value for unknown mappings, as it is a valid
> crypto ID (HASH_ALGO_MD4).
> This patch initializes crypto_id to HASH_ALGO__LAST.
Make sense.
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Kind regards,
Petr
^ permalink raw reply
* Re: mmotm 2020-01-28-20-05 uploaded (security/security.c)
From: Paul Moore @ 2020-01-29 13:51 UTC (permalink / raw)
To: Randy Dunlap
Cc: akpm, broonie, linux-fsdevel, linux-kernel, linux-mm, linux-next,
mhocko, mm-commits, sfr, linux-security-module, James Morris,
Serge E. Hallyn
In-Reply-To: <56177bc4-441d-36f4-fe73-4e86edf02899@infradead.org>
On Tue, Jan 28, 2020 at 11:52 PM Randy Dunlap <rdunlap@infradead.org> wrote:
> On 1/28/20 8:06 PM, akpm@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2020-01-28-20-05 has been uploaded to
> >
> > http://www.ozlabs.org/~akpm/mmotm/
> >
> > mmotm-readme.txt says
> >
> > README for mm-of-the-moment:
> >
> > http://www.ozlabs.org/~akpm/mmotm/
> >
> > This is a snapshot of my -mm patch queue. Uploaded at random hopefully
> > more than once a week.
> >
>
> security/security.c contains duplicate lines for <lockdown_reasons> array:
Hmmm. Commit 59438b46471a ("security,lockdown,selinux: implement
SELinux lockdown"), which was merged into Linus' tree during the
current merge window, moved the lockdown_reasons array from
security/lockdown/lockdown.c to security/security.c; is there another
tree in linux-next which is moving lockdown_reasons into
security/security.c?
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: mmotm 2020-01-28-20-05 uploaded (security/security.c)
From: Randy Dunlap @ 2020-01-29 16:02 UTC (permalink / raw)
To: Paul Moore
Cc: akpm, broonie, linux-fsdevel, linux-kernel, linux-mm, linux-next,
mhocko, mm-commits, sfr, linux-security-module, James Morris,
Serge E. Hallyn
In-Reply-To: <CAHC9VhRW68ccE_8HJnv4anFdSgkY2Yk3612LPCT5o4+vXQGqQA@mail.gmail.com>
On 1/29/20 5:51 AM, Paul Moore wrote:
> On Tue, Jan 28, 2020 at 11:52 PM Randy Dunlap <rdunlap@infradead.org> wrote:
>> On 1/28/20 8:06 PM, akpm@linux-foundation.org wrote:
>>> The mm-of-the-moment snapshot 2020-01-28-20-05 has been uploaded to
>>>
>>> http://www.ozlabs.org/~akpm/mmotm/
>>>
>>> mmotm-readme.txt says
>>>
>>> README for mm-of-the-moment:
>>>
>>> http://www.ozlabs.org/~akpm/mmotm/
>>>
>>> This is a snapshot of my -mm patch queue. Uploaded at random hopefully
>>> more than once a week.
>>>
>>
>> security/security.c contains duplicate lines for <lockdown_reasons> array:
>
> Hmmm. Commit 59438b46471a ("security,lockdown,selinux: implement
> SELinux lockdown"), which was merged into Linus' tree during the
> current merge window, moved the lockdown_reasons array from
> security/lockdown/lockdown.c to security/security.c; is there another
> tree in linux-next which is moving lockdown_reasons into
> security/security.c?
>
Somehow in mmotm those lines of code were merged 2x:
once from origin.patch and once from linux-next.patch.
Looks more like a mmotm merge issue, not a security/ issue.
--
~Randy
^ permalink raw reply
* [PATCH] security, keys: Optimize barrier usage for Rmw atomic bitops
From: Davidlohr Bueso @ 2020-01-29 18:06 UTC (permalink / raw)
To: dhowells; +Cc: linux-security-module, linux-kernel, dave, Davidlohr Bueso
For both set and clear_bit, we can avoid the unnecessary barriers
on non LL/SC architectures, such as x86. Instead, use the
smp_mb__{before,after}_atomic() calls.
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
---
security/keys/gc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/keys/gc.c b/security/keys/gc.c
index 671dd730ecfc..ce7b4c22e3c4 100644
--- a/security/keys/gc.c
+++ b/security/keys/gc.c
@@ -102,7 +102,7 @@ void key_gc_keytype(struct key_type *ktype)
key_gc_dead_keytype = ktype;
set_bit(KEY_GC_REAPING_KEYTYPE, &key_gc_flags);
- smp_mb();
+ smp_mb__after_atomic();
set_bit(KEY_GC_REAP_KEYTYPE, &key_gc_flags);
kdebug("schedule");
@@ -308,7 +308,7 @@ static void key_garbage_collector(struct work_struct *work)
if (unlikely(gc_state & KEY_GC_REAPING_DEAD_3)) {
kdebug("dead wake");
- smp_mb();
+ smp_mb__before_atomic();
clear_bit(KEY_GC_REAPING_KEYTYPE, &key_gc_flags);
wake_up_bit(&key_gc_flags, KEY_GC_REAPING_KEYTYPE);
}
--
2.16.4
^ permalink raw reply related
* Re: linux-next: Tree for Jan 29 (security/smack/)
From: Randy Dunlap @ 2020-01-29 22:18 UTC (permalink / raw)
To: Stephen Rothwell, Linux Next Mailing List
Cc: Linux Kernel Mailing List, Casey Schaufler, linux-security-module
In-Reply-To: <20200129155431.76bd7f25@canb.auug.org.au>
On 1/28/20 8:54 PM, Stephen Rothwell wrote:
> Hi all,
>
> Please do not add any v5.7 material to your linux-next included
> branches until after v5.6-rc1 has been released.
>
> Changes since 20200128:
>
../security/smack/smack_lsm.c: In function ‘smack_post_notification’:
../security/smack/smack_lsm.c:4383:7: error: dereferencing pointer to incomplete type ‘struct watch_notification’
if (n->type == WATCH_TYPE_META)
^~
CC kernel/time/hrtimer.o
../security/smack/smack_lsm.c:4383:17: error: ‘WATCH_TYPE_META’ undeclared (first use in this function); did you mean ‘TCA_PIE_BETA’?
if (n->type == WATCH_TYPE_META)
^~~~~~~~~~~~~~~
TCA_PIE_BETA
Probably just missing
#include <linux/watch_queue.h>
--
~Randy
Reported-by: Randy Dunlap <rdunlap@infradead.org>
^ permalink raw reply
* Re: mmotm 2020-01-28-20-05 uploaded (security/security.c)
From: Stephen Rothwell @ 2020-01-29 22:32 UTC (permalink / raw)
To: Randy Dunlap
Cc: akpm, broonie, linux-fsdevel, linux-kernel, linux-mm, linux-next,
mhocko, mm-commits, linux-security-module, James Morris,
Serge E. Hallyn
In-Reply-To: <56177bc4-441d-36f4-fe73-4e86edf02899@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 478 bytes --]
Hi Randy,
On Tue, 28 Jan 2020 20:52:28 -0800 Randy Dunlap <rdunlap@infradead.org> wrote:
>
> security/security.c contains duplicate lines for <lockdown_reasons> array:
>
> Stephen, you might delete half of those for linux-next....
I did not get that in my import of mmotm today. But I actually git
merge the appropriate part of linux-next rather than applying the
linux-next.patch from mmotm - so that may have taken care of it.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for Jan 29 (security/smack/)
From: Casey Schaufler @ 2020-01-29 22:54 UTC (permalink / raw)
To: Randy Dunlap, Stephen Rothwell, Linux Next Mailing List,
David Howells
Cc: Linux Kernel Mailing List, linux-security-module, Casey Schaufler
In-Reply-To: <e66a563e-b612-c5b6-7bdd-b55113a9b822@infradead.org>
On 1/29/2020 2:18 PM, Randy Dunlap wrote:
> On 1/28/20 8:54 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Please do not add any v5.7 material to your linux-next included
>> branches until after v5.6-rc1 has been released.
>>
>> Changes since 20200128:
>>
This keeps coming up. It's in David Howells' watch queue changes.
David, could you please fix this?
> ../security/smack/smack_lsm.c: In function �smack_post_notification�:
> ../security/smack/smack_lsm.c:4383:7: error: dereferencing pointer to incomplete type �struct watch_notification�
> if (n->type == WATCH_TYPE_META)
> ^~
> CC kernel/time/hrtimer.o
> ../security/smack/smack_lsm.c:4383:17: error: �WATCH_TYPE_META� undeclared (first use in this function); did you mean �TCA_PIE_BETA�?
> if (n->type == WATCH_TYPE_META)
> ^~~~~~~~~~~~~~~
> TCA_PIE_BETA
>
>
> Probably just missing
> #include <linux/watch_queue.h>
>
>
^ permalink raw reply
* [PATCH] security/integrity: Include __func__ in messages for easier debug
From: Shuah Khan @ 2020-01-30 2:01 UTC (permalink / raw)
To: jmorris, serge, mpe, zohar, erichte, nayna, yuehaibing
Cc: Shuah Khan, linux-security-module, linux-kernel
Change messages to messages to make it easier to debug. The following
error message isn't informative enough to figure out what failed.
Couldn't get size: 0x800000000000000e
Change messages to include function information.
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
---
.../integrity/platform_certs/load_powerpc.c | 14 ++++++++------
security/integrity/platform_certs/load_uefi.c | 17 ++++++++++-------
2 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/security/integrity/platform_certs/load_powerpc.c b/security/integrity/platform_certs/load_powerpc.c
index a2900cb85357..621454148fbc 100644
--- a/security/integrity/platform_certs/load_powerpc.c
+++ b/security/integrity/platform_certs/load_powerpc.c
@@ -25,7 +25,7 @@ static __init void *get_cert_list(u8 *key, unsigned long keylen, uint64_t *size)
rc = secvar_ops->get(key, keylen, NULL, size);
if (rc) {
- pr_err("Couldn't get size: %d\n", rc);
+ pr_err("%s: Couldn't get size: %d\n", __func__, rc);
return NULL;
}
@@ -36,7 +36,7 @@ static __init void *get_cert_list(u8 *key, unsigned long keylen, uint64_t *size)
rc = secvar_ops->get(key, keylen, db, size);
if (rc) {
kfree(db);
- pr_err("Error reading %s var: %d\n", key, rc);
+ pr_err("%s: Error reading %s var: %d\n", __func__, key, rc);
return NULL;
}
@@ -69,23 +69,25 @@ static int __init load_powerpc_certs(void)
*/
db = get_cert_list("db", 3, &dbsize);
if (!db) {
- pr_err("Couldn't get db list from firmware\n");
+ pr_err("%s: Couldn't get db list from firmware\n", __func__);
} else {
rc = parse_efi_signature_list("powerpc:db", db, dbsize,
get_handler_for_db);
if (rc)
- pr_err("Couldn't parse db signatures: %d\n", rc);
+ pr_err("%s: Couldn't parse db signatures: %d\n",
+ __func__, rc);
kfree(db);
}
dbx = get_cert_list("dbx", 4, &dbxsize);
if (!dbx) {
- pr_info("Couldn't get dbx list from firmware\n");
+ pr_info("%s: Couldn't get dbx list from firmware\n", __func__);
} else {
rc = parse_efi_signature_list("powerpc:dbx", dbx, dbxsize,
get_handler_for_dbx);
if (rc)
- pr_err("Couldn't parse dbx signatures: %d\n", rc);
+ pr_err("%s: Couldn't parse dbx signatures: %d\n",
+ __func__, rc);
kfree(dbx);
}
diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
index 111898aad56e..c3cf6575abc1 100644
--- a/security/integrity/platform_certs/load_uefi.c
+++ b/security/integrity/platform_certs/load_uefi.c
@@ -44,7 +44,7 @@ static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid,
status = efi.get_variable(name, guid, NULL, &lsize, &tmpdb);
if (status != EFI_BUFFER_TOO_SMALL) {
- pr_err("Couldn't get size: 0x%lx\n", status);
+ pr_err("%s: Couldn't get size: 0x%lx\n", __func__, status);
return NULL;
}
@@ -55,7 +55,7 @@ static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid,
status = efi.get_variable(name, guid, NULL, &lsize, db);
if (status != EFI_SUCCESS) {
kfree(db);
- pr_err("Error reading db var: 0x%lx\n", status);
+ pr_err("%s: Error reading db var: 0x%lx\n", __func__, status);
return NULL;
}
@@ -85,13 +85,14 @@ static int __init load_uefi_certs(void)
if (!uefi_check_ignore_db()) {
db = get_cert_list(L"db", &secure_var, &dbsize);
if (!db) {
- pr_err("MODSIGN: Couldn't get UEFI db list\n");
+ pr_err("%s: MODSIGN: Couldn't get UEFI db list\n",
+ __func__);
} else {
rc = parse_efi_signature_list("UEFI:db",
db, dbsize, get_handler_for_db);
if (rc)
- pr_err("Couldn't parse db signatures: %d\n",
- rc);
+ pr_err("%s: Couldn't parse db signatures: %d\n",
+ __func__, rc);
kfree(db);
}
}
@@ -103,7 +104,8 @@ static int __init load_uefi_certs(void)
rc = parse_efi_signature_list("UEFI:MokListRT",
mok, moksize, get_handler_for_db);
if (rc)
- pr_err("Couldn't parse MokListRT signatures: %d\n", rc);
+ pr_err("%s: Couldn't parse MokListRT signatures: %d\n",
+ __func__, rc);
kfree(mok);
}
@@ -115,7 +117,8 @@ static int __init load_uefi_certs(void)
dbx, dbxsize,
get_handler_for_dbx);
if (rc)
- pr_err("Couldn't parse dbx signatures: %d\n", rc);
+ pr_err("%s: Couldn't parse dbx signatures: %d\n",
+ __func__, rc);
kfree(dbx);
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] security/integrity: Include __func__ in messages for easier debug
From: Joe Perches @ 2020-01-30 3:08 UTC (permalink / raw)
To: Shuah Khan, jmorris, serge, mpe, zohar, erichte, nayna,
yuehaibing
Cc: linux-security-module, linux-kernel
In-Reply-To: <20200130020129.15328-1-skhan@linuxfoundation.org>
On Wed, 2020-01-29 at 19:01 -0700, Shuah Khan wrote:
> Change messages to messages to make it easier to debug. The following
> error message isn't informative enough to figure out what failed.
> Change messages to include function information.
>
> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
> ---
> .../integrity/platform_certs/load_powerpc.c | 14 ++++++++------
> security/integrity/platform_certs/load_uefi.c | 17 ++++++++++-------
> 2 files changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/security/integrity/platform_certs/load_powerpc.c b/security/integrity/platform_certs/load_powerpc.c
perhaps instead add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
so all the pr_<level> logging is more specific.
This would prefix all pr_<level> output with "integrity: "
3integrity: Couldn't get size: 0x%lx
3integrity: Error reading db var: 0x%lx
3integrity: MODSIGN: Couldn't get UEFI db list
3integrity: Couldn't parse db signatures: %d
6integrity: Couldn't get UEFI MokListRT
3integrity: Couldn't parse MokListRT signatures: %d
6integrity: Couldn't get UEFI dbx list
3integrity: Couldn't parse dbx signatures: %d
5integrity: Platform Keyring initialized
6integrity: Error adding keys to platform keyring %s
---
security/integrity/platform_certs/load_powerpc.c | 3 +++
security/integrity/platform_certs/load_uefi.c | 2 ++
security/integrity/platform_certs/platform_keyring.c | 2 ++
3 files changed, 7 insertions(+)
diff --git a/security/integrity/platform_certs/load_powerpc.c b/security/integrity/platform_certs/load_powerpc.c
index a2900c..5cfbd0 100644
--- a/security/integrity/platform_certs/load_powerpc.c
+++ b/security/integrity/platform_certs/load_powerpc.c
@@ -5,6 +5,9 @@
*
* - loads keys and hashes stored and controlled by the firmware.
*/
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/cred.h>
diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
index 111898a..480450a 100644
--- a/security/integrity/platform_certs/load_uefi.c
+++ b/security/integrity/platform_certs/load_uefi.c
@@ -1,5 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/cred.h>
diff --git a/security/integrity/platform_certs/platform_keyring.c b/security/integrity/platform_certs/platform_keyring.c
index 7646e35..9bd2846 100644
--- a/security/integrity/platform_certs/platform_keyring.c
+++ b/security/integrity/platform_certs/platform_keyring.c
@@ -6,6 +6,8 @@
* Author(s): Nayna Jain <nayna@linux.ibm.com>
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/export.h>
#include <linux/kernel.h>
#include <linux/sched.h>
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox