[PATCH 1/2] power: reset: reboot-mode: Add managed resource API

Provide managed resource version of reboot_mode_register() and reboot_mode_unregister() to simplify implementations. Cc: John Stultz Signed-off-by: Bjorn Andersson --- John, here's a "pointer" to what I meant with my comment on your

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

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 would be a better way to > >> provide a mechanism for

Re: [PATCH 1/1] Documenation: update cgroup's document path

On Tue, 2 Aug 2016 23:23:57 +0900 "seokhoon.yoon" wrote: > cgroup's document path is changed to "cgroup-v1". update it. Seems worthy to me, applied to the docs tree. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a

Re: [PATCH 1/1] Documenation: update cgroup's document path

On Wed, Aug 03, 2016 at 03:44:17PM -0600, Jonathan Corbet wrote: > On Tue, 2 Aug 2016 23:23:57 +0900 > "seokhoon.yoon" wrote: > > > cgroup's document path is changed to "cgroup-v1". update it. > > Seems worthy to me, applied to the docs tree. Acked-late-by: Tejun Heo

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: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

> One of the strengths of linux is applications of features the authors > of > the software had not imagined.  Your proposals seem to be trying to > put > the world a tiny little box where if someone had not imagined and > preapproved a use of a feature it should not happen.   Let's please > avoid

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

On Wed, Aug 3, 2016 at 10:25 AM, Eric W. Biederman wrote: > > Sigh. > > Kees we have already had this conversation about user namespaces and > apparently you missed the point. Well, I didn't miss the point: that's why I CCed you. :) This is nearly the same discussion

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

> -Original Message- > From: Peter Zijlstra [mailto:pet...@infradead.org] > Sent: Wednesday, August 03, 2016 7:41 AM > To: Kees Cook > Cc: Jeff Vander Stoep ; Ingo Molnar ; > Arnaldo Carvalho de Melo ; Alexander

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

On Tue, Aug 02, 2016 at 01:51:47PM -0700, Kees Cook wrote: > Let me take this another way instead. What would be a better way to > provide a mechanism for system owners to disable perf without an LSM? > (Since far fewer folks run with an enforcing "big" LSM: I'm seeking as > wide a coverage as

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

On Wed, Aug 03, 2016 at 08:28:10AM -0400, Daniel Micay wrote: > I don't think there are runtimes using this for JIT tracing. Perhaps it > doesn't actually suit their needs. It's a theoretical use case. I know there are compiler teams using perf for FDO, see for example:

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

Having this in Yama would also make it probable that there would be a security-centric default. It would end up wiping out unprivileged perf events access on distributions using Yama for ptrace_scope unless they make the explicit decision to disable it. Having the perf subsystem extend the

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

> The default has no impact on the "it's too coarse and limiting" > negative property  > of this patch, which is the show-stopper aspect. Please fix that > aspect instead of  > trying to argue around it. Disabling perf events in the kernel configuration is even more limiting, and is currently the

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

* Kees Cook wrote: > > I see 0 up-sides of this approach and, as per the above, a whole bunch of > > very > > serious downsides. > > > > A global (esp. default inhibited) knob is too coarse and limiting. > > I haven't suggested it be default inhibit in the upstream

Re: [PATCH v3 2/3] drm: Add API for capturing frame CRCs

On Wed, Aug 03, 2016 at 10:06:38AM +0300, Ville Syrjälä wrote: > On Fri, Jul 22, 2016 at 04:10:44PM +0200, Tomeu Vizoso wrote: > > Adds files and directories to debugfs for controlling and reading frame > > CRCs, per CRTC: > > > > dri/0/crtc-0/crc > > dri/0/crtc-0/crc/control > >

Re: [PATCH v3 2/3] drm: Add API for capturing frame CRCs

On Fri, Jul 22, 2016 at 04:10:44PM +0200, Tomeu Vizoso wrote: > Adds files and directories to debugfs for controlling and reading frame > CRCs, per CRTC: > > dri/0/crtc-0/crc > dri/0/crtc-0/crc/control > dri/0/crtc-0/crc/data > > Drivers can implement the set_crc_source callback() in