Re: [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks
On Wed, 26 May 2021, Ondrej Mosnacek wrote: > Thanks, Michael! > > James/Paul, is there anything blocking this patch from being merged? > Especially the BPF case is causing real trouble for people and the > only workaround is to broadly allow lockdown::confidentiality in the > 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
Re: [PATCH v2 2/7] libfs: wrap simple_pin_fs/simple_release_fs arguments in a struct
On Tue, 21 Apr 2020, Emanuele Giuseppe Esposito wrote: > Simplify passing the count and mount to simple_pin_fs and > simple_release_fs by wrapping them in the simple_fs struct, > in preparation for adding more high level operations to > fs/libfs.c > > There is no functional change intended. > > Signed-off-by: Emanuele Giuseppe Esposito Reviewed-by: James Morris -- James Morris
Re: [Intel-gfx] [PATCH v7 00/12] Introduce CAP_PERFMON to secure system performance monitoring and observability
On Sun, 1 Mar 2020, Serge Hallyn wrote: > Thanks, this looks good to me, in keeping with the CAP_SYSLOG break. > > Acked-by: Serge E. Hallyn > > for the set. > > James/Ingo/Peter, if noone has remaining objections, whose branch > should these go in through? > > thanks, > -serge > > On Tue, Feb 25, 2020 at 12:55:54PM +0300, Alexey Budankov wrote: > > > > Hi, > > > > Is there anything else I could do in order to move the changes forward > > or is something still missing from this patch set? > > Could you 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: [Intel-gfx] [PATCH v7 00/12] Introduce CAP_PERFMON to secure system performance monitoring and observability
> > > observability beyond the scope permitted by the system wide > > > perf_event_paranoid kernel setting [9] and below are the steps for > > > evaluation: > > > > > > - patch, build and boot the kernel > > > - patch, build Perf tool e.g. to /home/user/perf > > > ... > > > # git clone git://git.kernel.org/pub/scm/libs/libcap/libcap.git libcap > > > # pushd libcap > > > # patch libcap/include/uapi/linux/capabilities.h with [PATCH 1] > > > # make > > > # pushd progs > > > # ./setcap "cap_perfmon,cap_sys_ptrace,cap_syslog=ep" /home/user/perf > > > # ./setcap -v "cap_perfmon,cap_sys_ptrace,cap_syslog=ep" /home/user/perf > > > /home/user/perf: OK > > > # ./getcap /home/user/perf > > > /home/user/perf = cap_sys_ptrace,cap_syslog,cap_perfmon+ep > > > # echo 2 > /proc/sys/kernel/perf_event_paranoid > > > # cat /proc/sys/kernel/perf_event_paranoid > > > 2 > > > ... > > > $ /home/user/perf top > > > ... works as expected ... > > > $ cat /proc/`pidof perf`/status > > > Name: perf > > > Umask: 0002 > > > State: S (sleeping) > > > Tgid: 2958 > > > Ngid: 0 > > > Pid:2958 > > > PPid: 9847 > > > TracerPid: 0 > > > Uid:500 500 500 500 > > > Gid:500 500 500 500 > > > FDSize: 256 > > > ... > > > CapInh: > > > 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: [PATCH v7 10/12] drivers/oprofile: open access for CAP_PERFMON privileged process
On Mon, 17 Feb 2020, Alexey Budankov wrote: > 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 Reviewed-by: James Morris -- James Morris
Re: [PATCH v7 09/12] drivers/perf: open access for CAP_PERFMON privileged process
On Mon, 17 Feb 2020, Alexey Budankov wrote: > 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 Reviewed-by: James Morris -- James Morris
Re: [PATCH v7 08/12] parisc/perf: open access for CAP_PERFMON privileged process
On Mon, 17 Feb 2020, Alexey Budankov wrote: > 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 Reviewed-by: James Morris -- James Morris
Re: [PATCH v7 07/12] powerpc/perf: open access for CAP_PERFMON privileged process
On Mon, 17 Feb 2020, Alexey Budankov wrote: > 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 Reviewed-by: James Morris -- James Morris
Re: [PATCH v7 06/12] trace/bpf_trace: open access for CAP_PERFMON privileged process
On Mon, 17 Feb 2020, Alexey Budankov wrote: > > Open access to bpf_trace 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 bpf_trace monitoring > remains open for CAP_SYS_ADMIN privileged processes 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 05/12] drm/i915/perf: open access for CAP_PERFMON privileged process
On Mon, 17 Feb 2020, Alexey Budankov wrote: > > Open access to i915_perf 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 i915_events subsystem > remains open for CAP_SYS_ADMIN privileged processes 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 04/12] perf tool: extend Perf tool with CAP_PERFMON capability support
On Mon, 17 Feb 2020, Alexey Budankov wrote: > > Extend error messages to mention CAP_PERFMON capability as an option > to substitute CAP_SYS_ADMIN capability for secure system performance > monitoring and observability. Make perf_event_paranoid_check() and > __cmd_ftrace() to be aware of CAP_PERFMON capability. > > 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 Reviewed-by: James Morris -- James Morris
Re: [PATCH v7 03/12] perf/core: open access to probes for CAP_PERFMON privileged process
On Mon, 17 Feb 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 Reviewed-by: James Morris -- James Morris
Re: [PATCH v7 02/12] perf/core: open access to the core for CAP_PERFMON privileged process
On Mon, 17 Feb 2020, Alexey Budankov wrote: > > Open access to monitoring of kernel code, cpus, tracepoints and > namespaces data for a 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 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 Reviewed-by: James Morris -- James Morris
Re: [PATCH v7 01/12] capabilities: introduce CAP_PERFMON to kernel and user space
On Mon, 17 Feb 2020, Alexey Budankov wrote: > > Introduce CAP_PERFMON capability designed to secure system performance > monitoring and observability operations so that CAP_PERFMON would assist > CAP_SYS_ADMIN capability in its governing role for performance > monitoring and observability subsystems. Acked-by: James Morris -- James Morris
Re: [PATCH v6 03/10] perf/core: open access to probes for CAP_PERFMON privileged process
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 > --- > kernel/events/core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Acked-by: James Morris -- James Morris
Re: [PATCH v6 07/10] powerpc/perf: open access for CAP_PERFMON privileged process
On Tue, 28 Jan 2020, Alexey Budankov wrote: > Signed-off-by: Alexey Budankov > --- > 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 -- James Morris
Re: [PATCH v6 06/10] trace/bpf_trace: open access for CAP_PERFMON privileged process
On Tue, 28 Jan 2020, Alexey Budankov wrote: > > Signed-off-by: Alexey Budankov > --- > 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 -- James Morris
Re: [PATCH v6 01/10] capabilities: introduce CAP_PERFMON to kernel and user space
On Tue, 28 Jan 2020, Alexey Budankov wrote: > > Signed-off-by: Alexey Budankov > --- > 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 -- James Morris
Re: [PATCH v6 10/10] drivers/oprofile: open access for CAP_PERFMON privileged process
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
> ---
> drivers/oprofile/event_buffer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: James Morris
>
> 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
Re: [PATCH v6 09/10] drivers/perf: open access for CAP_PERFMON privileged process
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 > --- > drivers/perf/arm_spe_pmu.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Acked-by: James Morris > 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
Re: [PATCH v6 08/10] parisc/perf: open access for CAP_PERFMON privileged process
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 > --- > 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 -- James Morris
Re: [PATCH v8 00/14] Appended signatures support for IMA appraisal
On Fri, 16 Nov 2018, Thiago Jung Bauermann wrote: > On the OpenPOWER platform, secure boot and trusted boot are being > implemented using IMA for taking measurements and verifying signatures. > Since the kernel image on Power servers is an ELF binary, kernels are > signed using the scripts/sign-file tool and thus use the same signature > format as signed kernel modules. > > This patch series adds support in IMA for verifying those signatures. Are you saying you use IMA to verify kernels during boot? From a Linux bootloader? > It adds flexibility to OpenPOWER secure boot, because it allows it to boot > kernels with the signature appended to them as well as kernels where the > signature is stored in the IMA extended attribute. Just to clarify, with these patches, IMA will be able to verify the native form of signed kernel modules? i.e. without xattrs 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
On Tue, 26 Jun 2018, Ard Biesheuvel wrote: > Allow the initcall tables to be emitted using relative references that > are only half the size on 64-bit architectures and don't require fixups > at runtime on relocatable kernels. > > Cc: Petr Mladek > Cc: Sergey Senozhatsky > 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/security.c| 17 > 4 files changed, 68 insertions(+), 41 deletions(-) Acked-by: James Morris -- James Morris
Re: [PATCH 1/1] drivers/char/tpm: remove tasklet and cleanup
wake_up_interruptible(&wq);
> + /* len of the data in rtce buffer */
> + ibmvtpm->res_len = crq->len;
> + wake_up_interruptible(&ibmvtpm->wq);
> return;
> default:
> return;
> @@ -559,38 +556,19 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
> static irqreturn_t ibmvtpm_interrupt(int irq, void *vtpm_instance)
> {
> struct ibmvtpm_dev *ibmvtpm = (struct ibmvtpm_dev *) vtpm_instance;
> - unsigned long flags;
> -
> - spin_lock_irqsave(&ibmvtpm->lock, flags);
> - vio_disable_interrupts(ibmvtpm->vdev);
> - tasklet_schedule(&ibmvtpm->tasklet);
> - spin_unlock_irqrestore(&ibmvtpm->lock, flags);
> -
> - return IRQ_HANDLED;
> -}
> -
> -/**
> - * ibmvtpm_tasklet - Interrupt handler tasklet
> - * @data:ibm vtpm device struct
> - *
> - * Returns:
> - * Nothing
> - **/
> -static void ibmvtpm_tasklet(void *data)
> -{
> - struct ibmvtpm_dev *ibmvtpm = data;
> struct ibmvtpm_crq *crq;
> - unsigned long flags;
>
> - spin_lock_irqsave(&ibmvtpm->lock, flags);
> + /* while loop is needed for initial setup (get version and
> + * get rtce_size). There should be only one tpm request at any
> + * given time.
> + */
> while ((crq = ibmvtpm_crq_get_next(ibmvtpm)) != NULL) {
> ibmvtpm_crq_process(crq, ibmvtpm);
> crq->valid = 0;
> - wmb();
> + smp_wmb();
> }
>
> - vio_enable_interrupts(ibmvtpm->vdev);
> - spin_unlock_irqrestore(&ibmvtpm->lock, flags);
> + return IRQ_HANDLED;
> }
>
> /**
> @@ -650,9 +628,6 @@ static int __devinit tpm_ibmvtpm_probe(struct vio_dev
> *vio_dev,
> goto reg_crq_cleanup;
> }
>
> - tasklet_init(&ibmvtpm->tasklet, (void *)ibmvtpm_tasklet,
> - (unsigned long)ibmvtpm);
> -
> rc = request_irq(vio_dev->irq, ibmvtpm_interrupt, 0,
>tpm_ibmvtpm_driver_name, ibmvtpm);
> if (rc) {
> @@ -666,13 +641,14 @@ static int __devinit tpm_ibmvtpm_probe(struct vio_dev
> *vio_dev,
> goto init_irq_cleanup;
> }
>
> + init_waitqueue_head(&ibmvtpm->wq);
> +
> crq_q->index = 0;
>
> ibmvtpm->dev = dev;
> ibmvtpm->vdev = vio_dev;
> chip->vendor.data = (void *)ibmvtpm;
>
> - spin_lock_init(&ibmvtpm->lock);
> spin_lock_init(&ibmvtpm->rtce_lock);
>
> rc = ibmvtpm_crq_send_init(ibmvtpm);
> @@ -689,7 +665,6 @@ static int __devinit tpm_ibmvtpm_probe(struct vio_dev
> *vio_dev,
>
> return rc;
> init_irq_cleanup:
> - tasklet_kill(&ibmvtpm->tasklet);
> do {
> 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 V3 1/3] drivers/char/tpm: Add new device driver to support IBM vTPM
On Fri, 7 Sep 2012, Kent Yoder wrote: > > > James did accept my pull request, so these are already in > > > security-next... > > > > For the driver itself, it's not a big issue (though I did found issue > > while reviewing it so it will need another round of updates). For the > > code that changes arch/powerpc, especially prom_init.c, that stuff must > > at the very least be acked by me (or the acting powerpc person if I'm > > away) if it's going to go via a different tree. > > Sorry about that. Hopefully there 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? -- 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
On Tue, 17 May 2011, Ingo Molnar wrote: > I'm not sure i get your point. Your example was not complete as described. After an apparently simple specification, you've since added several qualifiers and assumptions, and I still doubt that it's complete. A higher level goal would look like "Allow a sandbox app access only to approved resources, to contain the effects of flaws in the app", or similar. Note that this includes a threat model (remote attacker taking control of the app) and a general and fully stated strategy for dealing with it. >From there, 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, but you asked... - 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
On Mon, 16 May 2011, Ingo Molnar wrote: > > Not really. > > > > Firstly, what is the security goal of these restrictions? [...] > > To do what i described above? Namely: > > " Sandboxed code should only be allowed to open files in /home/sandbox/, > /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 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
On Fri, 13 May 2011, Ingo Molnar wrote: > Say i'm a user-space sandbox developer who wants to enforce that sandboxed > code > should only be allowed to open files in /home/sandbox/, /lib/ and /usr/lib/. > > It is a simple and sensible security feature, agreed? It allows most code to > run well and link to countless libraries - but no access to other files is > allowed. Not really. Firstly, what is the security goal of these restrictions? Then, are the restrictions complete and unbypassable? How do you reason about the behavior of the system as a whole? > I argue that this is the LSM and audit subsystems designed right: in the long > run it could allow everything that LSM does at the moment - and so much more > ... Now you're proposing a redesign of the security subsystem. That's a significant undertaking. In the meantime, 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 ___ 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
On Thu, 12 May 2011, Ingo Molnar wrote: > Funnily enough, back then you wrote this: > > " I'm concerned that we're seeing yet another security scheme being > designed on > the fly, without a well-formed threat model, and without taking into > account > lessons learned from the seemingly endless parade of similar, failed > schemes. " > > so when and how did your opinion of this scheme turn from it being an > "endless > parade of failed schemes" to it being a "well-defined and readily > understandable 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
On Thu, 12 May 2011, Ingo Molnar wrote: > > 2) Why should this concept not be made available wider, to allow the >restriction of not just system calls but other security relevant > components >of the kernel as well? Because the aim of this is to reduce the attack surface of the syscall interface. LSM is the correct level of abstraction for general security mediation, because it allows you to take into account all relevant security information in a race-free context. >This too, if you approach the problem via the events code, will be a > natural >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 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
On Wed, 11 May 2011, Will Drewry wrote:
> +void seccomp_filter_log_failure(int syscall)
> +{
> + printk(KERN_INFO
> + "%s[%d]: system call %d (%s) blocked at ip:%lx\n",
> + current->comm, task_pid_nr(current), syscall,
> + 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] powerpc/ibmveth: fix multiple errors with dma_mapping_error conversion
On Mon, 28 Jul 2008, Stephen Rothwell wrote: > I hope that we all can discuss procedures for API changes at the Kernel > Summit ... "all" as in, whoever was invited (the only transparent aspect of was a silly count of # of commits for the initial shortlist), or was on the committee, 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.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
