Re: [Intel-gfx] [PATCH v7 00/12] Introduce CAP_PERFMON to secure system performance monitoring and observability

0 > > > CapPrm: 00440008 > > > CapEff: 00440008 => 01000100 1000 > > > cap_perfmon,cap_sys_ptrace,cap_syslog > > > CapBnd: 007f > > > CapAmb: > > > NoNewPrivs: 0 > > > Seccomp:0 > > > Speculation_Store_Bypass: thread vulnerable > > > Cpus_allowed: ff > > > Cpus_allowed_list: 0-7 > > > ... > > > > > > Usage of cap_perfmon effectively avoids unused credentials excess: > > > > > > - with cap_sys_admin: > > > CapEff: 007f => 0111 > > > > > > - with cap_perfmon: > > > CapEff: 00440008 => 01000100 1000 > > > 38 34 19 > > >perfmon syslog sys_ptrace > > > > > > --- > > > [1] https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html > > > [2] http://man7.org/linux/man-pages/man7/capabilities.7.html > > > [3] > > > https://www.kernel.org/doc/html/latest/process/embargoed-hardware-issues.html > > > [4] https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html > > > [5] > > > https://www.kernel.org/doc/html/latest/process/management-style.html#decisions > > > [6] http://man7.org/linux/man-pages/man8/setcap.8.html > > > [7] https://git.kernel.org/pub/scm/libs/libcap/libcap.git > > > [8] https://sites.google.com/site/fullycapable/, posix_1003.1e-990310.pdf > > > [9] http://man7.org/linux/man-pages/man2/perf_event_open.2.html > > > > > ___ > > Intel-gfx mailing list > > intel-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > -- James Morris

Re: [Intel-gfx] [PATCH v7 00/12] Introduce CAP_PERFMON to secure system performance monitoring and observability

please share you mind? Alexey, It seems some of the previous Acks are not included in this patchset, e.g. https://lkml.org/lkml/2020/1/22/655 Every patch needs a Reviewed-by or Acked-by from maintainers of the code being changed. You have enough from the security folk, but I can't see any included from the perf folk. -- James Morris

Re: [PATCH v2 2/7] libfs: wrap simple_pin_fs/simple_release_fs arguments in a struct

al change intended. > > Signed-off-by: Emanuele Giuseppe Esposito Reviewed-by: James Morris -- James Morris

Re: [PATCH v8 00/14] Appended signatures support for IMA appraisal

rs at all, and this will work with existing signed modules? -- James Morris

Re: [PATCH v9 4/6] init: allow initcall tables to be emitted using relative references

y > Cc: Steven Rostedt > Cc: James Morris > Cc: "Serge E. Hallyn" > Signed-off-by: Ard Biesheuvel > --- > include/linux/init.h | 44 +++- > init/main.c| 32 +++--- > kernel/printk/printk.c | 16 +++ > security/s

Re: [PATCH v6 08/10] parisc/perf: open access for CAP_PERFMON privileged process

if (!capable(CAP_SYS_ADMIN)) > + if (!perfmon_capable()) > return -EACCES; > > if (count != sizeof(uint32_t)) > Acked-by: James Morris -- James Morris

Re: [PATCH v6 09/10] drivers/perf: open access for CAP_PERFMON privileged process

AP_SYS_ADMIN usage for secure > monitoring is discouraged with respect to CAP_PERFMON capability. > > Signed-off-by: Alexey Budankov > --- > drivers/perf/arm_spe_pmu.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Acked-by: James Morris > diff --git a/drivers

Re: [PATCH v6 10/10] drivers/oprofile: open access for CAP_PERFMON privileged process

AP_SYS_ADMIN usage for secure > monitoring is discouraged with respect to CAP_PERFMON capability. > > Signed-off-by: Alexey Budankov > --- > drivers/oprofile/event_buffer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: James Morris > > diff --git a/driv

Re: [PATCH v6 01/10] capabilities: introduce CAP_PERFMON to kernel and user space

deletions(-) Acked-by: James Morris -- James Morris

Re: [PATCH v6 06/10] trace/bpf_trace: open access for CAP_PERFMON privileged process

ble(CAP_SYS_ADMIN)) > + if (!perfmon_capable()) > return -EPERM; > if (event->attr.type != PERF_TYPE_TRACEPOINT) > return -EINVAL; > Acked-by: James Morris -- James Morris

Re: [PATCH v6 07/10] powerpc/perf: open access for CAP_PERFMON privileged process

t; return -ENOENT; > > - if (!capable(CAP_SYS_ADMIN)) > + if (!perfmon_capable()) > return -EACCES; > > /* Return if this is a couting event */ > Acked-by: James Morris -- James Morris

Re: [PATCH v6 03/10] perf/core: open access to probes for CAP_PERFMON privileged process

IN 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 > --- > kernel/events/core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Acked-by: James Morris -- James Morris

Re: [PATCH v7 01/12] capabilities: introduce CAP_PERFMON to kernel and user space

d observability subsystems. Acked-by: James Morris -- James Morris

Re: [PATCH v7 02/12] perf/core: open access to the core for CAP_PERFMON privileged process

m > 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 Reviewed-by: James Morris -- James Morris

Re: [PATCH v7 03/12] perf/core: open access to probes for CAP_PERFMON privileged process

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 Reviewed-by: James Morris -- James Morris

Re: [PATCH v7 04/12] perf tool: extend Perf tool with CAP_PERFMON capability support

rocesses but CAP_SYS_ADMIN > usage for secure perf_events monitoring is discouraged with respect to > CAP_PERFMON capability. > > Signed-off-by: Alexey Budankov Reviewed-by: James Morris -- James Morris

Re: [PATCH v7 05/12] drm/i915/perf: open access for CAP_PERFMON privileged process

rocesses but CAP_SYS_ADMIN > usage for secure i915_events monitoring is discouraged with respect to > CAP_PERFMON capability. > > Signed-off-by: Alexey Budankov Reviewed-by: James Morris -- James Morris

Re: [PATCH v7 06/12] trace/bpf_trace: open access for CAP_PERFMON privileged process

rocesses but CAP_SYS_ADMIN > usage for secure bpf_trace monitoring is discouraged with respect to > CAP_PERFMON capability. > > Signed-off-by: Alexey Budankov Reviewed-by: James Morris -- James Morris

Re: [PATCH v7 07/12] powerpc/perf: open access for CAP_PERFMON privileged process

ned-off-by: Alexey Budankov Reviewed-by: James Morris -- James Morris

Re: [PATCH v7 08/12] parisc/perf: open access for CAP_PERFMON privileged process

ned-off-by: Alexey Budankov Reviewed-by: James Morris -- James Morris

Re: [PATCH v7 09/12] drivers/perf: open access for CAP_PERFMON privileged process

ned-off-by: Alexey Budankov Reviewed-by: James Morris -- James Morris

Re: [PATCH v7 10/12] drivers/oprofile: open access for CAP_PERFMON privileged process

ned-off-by: Alexey Budankov Reviewed-by: James Morris -- James Morris

Re: [PATCH V3 1/3] drivers/char/tpm: Add new device driver to support IBM vTPM

here won't be any changes there and we > can amend with your ack. > > As for the driver updates, I'd hate to see everyone else's code in the > pull request get delayed yet again. James, will it be ok to apply the > update on top of security-next? I guess?

Re: [PATCH 1/1] drivers/char/tpm: remove tasklet and cleanup

> rc1 = plpar_hcall_norets(H_FREE_CRQ, vio_dev->unit_address); > } while (rc1 == H_BUSY || H_IS_LONG_BUSY(rc1)); > diff --git a/drivers/char/tpm/tpm_ibmvtpm.h b/drivers/char/tpm/tpm_ibmvtpm.h > index 4296eb4..bd82a79 100644 > --- a/drivers/char/tpm/tpm_ibmvtpm.h > +++ b/drivers/char/tpm/tpm_ibmvtpm.h > @@ -38,13 +38,12 @@ struct ibmvtpm_dev { > struct vio_dev *vdev; > struct ibmvtpm_crq_queue crq_queue; > dma_addr_t crq_dma_handle; > - spinlock_t lock; > - struct tasklet_struct tasklet; > u32 rtce_size; > void __iomem *rtce_buf; > dma_addr_t rtce_dma_handle; > spinlock_t rtce_lock; > - struct ibmvtpm_crq crq_res; > + wait_queue_head_t wq; > + u16 res_len; > u32 vtpm_version; > }; > > -- > 1.7.11.2 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- James Morris ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

syscall_nr_to_name(syscall), KSTK_EIP(current)); > +} I think it'd be a good idea to utilize the audit facility here. - James -- James Morris ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

ural >end result, while if you approach it from the seccomp prctl angle it will > be >a limited hack only. I'd say it's a well-defined and readily understandable feature. - James -- James Morris ___ Linuxppc-dev mailing

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

e feature"? :-) When it was defined in a way which limited its purpose to reducing the attack surface of the sycall interface. - James -- James Morris ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

we have a simple, well-defined enhancement to seccomp which will be very useful to current users in reducing their kernel attack surface. We should merge that, and the security subsystem discussion can carry on separately. - James -- James Morris _

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

/lib/ >and /usr/lib/ " These are access rules, they don't really describe a high-level security goal. How do you know it's ok to open everything in these directories? - James -- James Morris ___ Linuxppc-dev mailing list Linuxpp

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

e, you can start to analyze how to implement the goal, at which point you'd start thinking about configuration, assumptions, filesystem access, namespaces, indirect access (e.g. via sockets, rpc, ipc, shared memory, invocation). Anyway, this is getting off track from the main discussion, bu

Re: [PATCH] powerpc/ibmveth: fix multiple errors with dma_mapping_error conversion

ittee, or bought seats via sponsorship. - James (co- maintainer/author of several kernel subsystems over 8+ years and apparently not invited, because ?) -- James Morris <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.

Re: [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks

policy. It would be good to see more signoffs/reviews, especially from Paul, but he is busy with the io_uring stuff. Let's see if anyone else can look at this in the next couple of days. -- James Morris