Re: [PATCH v6 0/8] ipc: Clamp *mni to the real IPCMNI limit & increase that limit

Waiman Long <long...@redhat.com> writes: > On 05/01/2018 10:18 PM, Eric W. Biederman wrote: >> >>> The sysctl parameters msgmni, shmmni and semmni have an inherent limit >>> of IPC_MNI (32k). However, users may not be aware of that because they >>> can w

Re: [PATCH v6 0/8] ipc: Clamp *mni to the real IPCMNI limit & increase that limit

> The sysctl parameters msgmni, shmmni and semmni have an inherent limit > of IPC_MNI (32k). However, users may not be aware of that because they > can write a value much higher than that without getting any error or > notification. Reading the parameters back will show the newly written >

Re: [PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7

Khalid Aziz writes: > On 02/07/2018 12:38 AM, ebied...@xmission.com wrote: >> Khalid Aziz writes: >> >>> On 02/01/2018 07:29 PM, ebied...@xmission.com wrote: Khalid Aziz writes: > V11 changes: > This

Re: [PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7

Khalid Aziz writes: > On 02/01/2018 07:29 PM, ebied...@xmission.com wrote: >> Khalid Aziz writes: >> >>> V11 changes: >>> This series is same as v10 and was simply rebased on 4.15 kernel. Can >>> mm maintainers please review patches 2, 7, 8 and 9

Re: [PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7

Khalid Aziz writes: > V11 changes: > This series is same as v10 and was simply rebased on 4.15 kernel. Can > mm maintainers please review patches 2, 7, 8 and 9 which are arch > independent, and include/linux/mm.h and mm/ksm.c changes in patch 10 > and ack these if

Re: [PATCH v10 27/27] mm: display pkey in smaps if arch_pkeys_enabled() is true

Ram Pai <linux...@us.ibm.com> writes: > On Fri, Jan 19, 2018 at 10:09:41AM -0600, Eric W. Biederman wrote: >> Ram Pai <linux...@us.ibm.com> writes: >> >> > Currently the architecture specific code is expected to >> > display the protection keys

Re: [PATCH v10 27/27] mm: display pkey in smaps if arch_pkeys_enabled() is true

Ram Pai writes: > Currently the architecture specific code is expected to > display the protection keys in smap for a given vma. > This can lead to redundant code and possibly to divergent > formats in which the key gets displayed. > > This patch changes the

Re: [RFC v6 35/62] powerpc: Deliver SEGV signal on pkey violation

Ram Pai writes: > diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c > index d4e545d..fe1e7c7 100644 > --- a/arch/powerpc/kernel/traps.c > +++ b/arch/powerpc/kernel/traps.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include >

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

Peter Zijlstra <pet...@infradead.org> writes: > On Wed, Aug 03, 2016 at 09:50:37PM -0500, Eric W. Biederman wrote: > >> What this means in practice is user namespaces can be enabled by default >> on a system, and yet you can easily disable them in a sandbox that was >&g

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

Peter Zijlstra writes: > On Wed, Aug 03, 2016 at 11:53:41AM -0700, Kees Cook wrote: >> > Kees Cook writes: >> > >> >> On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra >> >> wrote: >> >> Let me take this another way instead. What

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

Sigh. Kees we have already had this conversation about user namespaces and apparently you missed the point. As I have said before the problem with a system wide off switch is what happens when you have a single application that needs to use the feature. Without care your system wide protection

Re: [PATCH] capabilities: add capability cgroup controller

Topi Miettinen <toiwo...@gmail.com> writes: > On 06/24/16 17:21, Eric W. Biederman wrote: >> "Serge E. Hallyn" <se...@hallyn.com> writes: >> >>> Quoting Tejun Heo (t...@kernel.org): >>>> Hello, >>>> >>>> On Fri, J

Re: [PATCH] capabilities: add capability cgroup controller

"Serge E. Hallyn" writes: > Quoting Tejun Heo (t...@kernel.org): >> Hello, >> >> On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote: >> > Quoting Tejun Heo (t...@kernel.org): >> > > But isn't being recursive orthogonal to using cgroup? Why not account >> > >

Re: [PATCH v2] sysctl: allow CLONE_NEWUSER to be disabled

Kees Cook writes: > + if (sysctl_userns_restrict && !(capable(CAP_SYS_ADMIN) && > + capable(CAP_SETUID) && > + capable(CAP_SETGID))) > + return -EPERM; > + I will also note that the

Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled

Kees Cook <keesc...@chromium.org> writes: > > Well, I don't know about less weird, but it would leave a unneeded > hole in the permission checks. To be clear the current patch has my: Nacked-by: "Eric W. Biederman" <ebied...@xmission.com> The code is buggy, an

Re: [kernel-hardening] Re: [PATCH 1/2] sysctl: expand use of proc_dointvec_minmax_sysadmin

Jann Horn <j...@thejh.net> writes: > On Sun, Jan 24, 2016 at 01:43:42AM +, Al Viro wrote: >> On Sat, Jan 23, 2016 at 07:20:17PM -0600, Eric W. Biederman wrote: >> >> > Yep. That is about the size of it. file * used to be passed to the >> > sysctl m

Re: [kernel-hardening] Re: [PATCH 1/2] sysctl: expand use of proc_dointvec_minmax_sysadmin

Jann Horn <j...@thejh.net> writes: > On Sun, Jan 24, 2016 at 12:02:41AM -0600, Eric W. Biederman wrote: >> Jann Horn <j...@thejh.net> writes: >> >> > On Sun, Jan 24, 2016 at 01:43:42AM +, Al Viro wrote: >> >> On Sat, Jan 23, 2

Re: [PATCH 1/2] sysctl: expand use of proc_dointvec_minmax_sysadmin

Kees Cook writes: > Several sysctls expect a state where the highest value (in extra2) is > locked once set for that boot. Yama does this, and kptr_restrict should > be doing it. This extracts Yama's logic and adds it to the existing > proc_dointvec_minmax_sysadmin, taking