Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1451317 > unrolled thread

[PATCH 1/2] security, perf: allow further restriction of perf_event_open

Back to article view | Back to linux.kernel

Contents

  [PATCH 1/2] security, perf: allow further restriction of perf_event_open Jeff Vander Stoep <jeffv@google.com> - 2016-07-27 16:50 +0200
    Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Kees Cook <keescook@chromium.org> - 2016-07-27 22:50 +0200
    Re: [PATCH 1/2] security, perf: allow further restriction of  perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-02 12:50 +0200
      Re: [PATCH 1/2] security, perf: allow further restriction of  perf_event_open Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-08-02 15:20 +0200
        Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-02 16:20 +0200
      Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-02 15:30 +0200
      Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Kees Cook <keescook@chromium.org> - 2016-08-02 23:00 +0200
        Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Ingo Molnar <mingo@kernel.org> - 2016-08-03 10:30 +0200
          Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-03 14:30 +0200
            Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-03 15:00 +0200
            Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-03 15:40 +0200
        Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-03 16:50 +0200
          RE: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open "Schaufler, Casey" <casey.schaufler@intel.com> - 2016-08-03 17:50 +0200
        Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Kees Cook <keescook@chromium.org> - 2016-08-03 21:30 +0200
          Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-04 00:40 +0200
            Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open ebiederm@xmission.com (Eric W. Biederman) - 2016-08-04 05:40 +0200
              Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-04 11:20 +0200
                Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open ebiederm@xmission.com (Eric W. Biederman) - 2016-08-04 17:30 +0200
                  Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-04 17:40 +0200
        Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-03 22:00 +0200
          Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Mark Rutland <mark.rutland@arm.com> - 2016-08-04 12:40 +0200
            Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-04 15:50 +0200
              Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-04 16:20 +0200
                Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-04 17:50 +0200
                  Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-04 18:00 +0200
                  Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Mark Rutland <mark.rutland@arm.com> - 2016-08-04 18:20 +0200
                    Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-04 18:40 +0200
                      Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Mark Rutland <mark.rutland@arm.com> - 2016-08-04 19:20 +0200
                        Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-04 19:40 +0200
        Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open ebiederm@xmission.com (Eric W. Biederman) - 2016-08-04 01:50 +0200
      Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-02 23:00 +0200
        Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Jeffrey Vander Stoep <jeffv@google.com> - 2016-08-02 23:20 +0200
      Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Kees Cook <keescook@chromium.org> - 2016-08-02 23:40 +0200

Page 2 of 2 — ← Prev page 1 [2]

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

On Wed, Aug 03, 2016 at 03:36:16PM -0400, Daniel Micay wrote:
> There's a lot of architecture and vendor specific perf events code and
> lots of bleeding edge features. On Android, a lot of the perf events
> vulnerabilities have been specific to the Qualcomm SoC platform. Other
> platforms are likely just receiving a lot less attention.

Are the relevant perf drivers for those platforms upstream? I've seen no
patches addressing security issues in the ARMv7 krait+Scorpion PMU
driver since it was added, and there's no ARMv8 QCOM PMU driver.

If there are outstanding issues, please report them upstream.

FWIW, I've used Vince Weaver's perf fuzzer to test the ARM PMU code
(both the framework and drivers), so other platforms are seeing some
attention. That said, I haven't done that recently.

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2016-08-04 at 11:28 +0100, Mark Rutland wrote:
> On Wed, Aug 03, 2016 at 03:36:16PM -0400, Daniel Micay wrote:
> > 
> > There's a lot of architecture and vendor specific perf events code
> > and
> > lots of bleeding edge features. On Android, a lot of the perf events
> > vulnerabilities have been specific to the Qualcomm SoC platform.
> > Other
> > platforms are likely just receiving a lot less attention.
> 
> Are the relevant perf drivers for those platforms upstream? I've seen
> no
> patches addressing security issues in the ARMv7 krait+Scorpion PMU
> driver since it was added, and there's no ARMv8 QCOM PMU driver.
> 
> If there are outstanding issues, please report them upstream.
> 
> FWIW, I've used Vince Weaver's perf fuzzer to test the ARM PMU code
> (both the framework and drivers), so other platforms are seeing some
> attention. That said, I haven't done that recently.

Qualcomm's perf driver is out-of-tree along with most of their other
drivers. Their drivers add up to a LOT of code shared across over a
billion mobile devices, leading to the focus on them. It also helps that
there are bounties for Nexus devices, so there are multi thousand dollar
rewards for bugs in the Qualcomm drivers compared to nothing for other
platforms / drivers. Now that perf is only available via ADB debugging,
further perf bugs no longer technically qualify for their bounties (but
they might still pay, I don't know).

[toc] | [prev] | [next] | [standalone]

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

On Thu, Aug 04, 2016 at 09:45:23AM -0400, Daniel Micay wrote:
> Qualcomm's perf driver is out-of-tree along with most of their other
> drivers. 


So you're asking us to maim upstream perf for some out of tree junk?
Srously? *plonk*

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2016-08-04 at 16:11 +0200, Peter Zijlstra wrote:
> On Thu, Aug 04, 2016 at 09:45:23AM -0400, Daniel Micay wrote:
> > 
> > Qualcomm's perf driver is out-of-tree along with most of their other
> > drivers. 
> 
> 
> So you're asking us to maim upstream perf for some out of tree junk?
> Srously? *plonk*

This feature doesn't come from Android. The perf events subsystem in the
mainline kernel is packed full of vulnerabilities too. The problem is so
bad that pointing one of the public fuzzers at it for a short period of
time is all that's required to start finding them.

Qualcomm's drivers might be lower quality than core kernel code, but
they're way above the baseline set by mainline kernel drivers...

Shining the same light on mainline drivers wouldn't be pretty. The work
going into hardening the Qualcomm drivers isn't happening upstream to
any comparable extent.

[toc] | [prev] | [next] | [standalone]

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

On Thu, Aug 04, 2016 at 11:44:28AM -0400, Daniel Micay wrote:

> This feature doesn't come from Android. The perf events subsystem in the
> mainline kernel is packed full of vulnerabilities too. 

Uhh, not so much. I spend a _lot_ of time a while back to get the core
and x86 solid. I could run the fuzzers for hours on end at some point.

> The problem is so bad that pointing one of the public fuzzers at it
> for a short period of time is all that's required to start finding
> them.

If you know of any that reproduce on x86 I'll go fix. For anything else
you need to complain elsewhere as I don't have hardware nor bandwidth.

[toc] | [prev] | [next] | [standalone]

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

On Thu, Aug 04, 2016 at 11:44:28AM -0400, Daniel Micay wrote:
> Qualcomm's drivers might be lower quality than core kernel code, but
> they're way above the baseline set by mainline kernel drivers...

I don't think that's true for the arm/arm64 perf code.

I think we've done a reasonable job of testing and fixing those, along
with core infrastructure issues. The perf fuzzer runs for a very long
time on a mainline kernel without issues, while on my Nexus 5x I get a
hard lockup after ~85 seconds (and prior to the last android update the
lockup was instantaneous).

> Shining the same light on mainline drivers wouldn't be pretty. The work
> going into hardening the Qualcomm drivers isn't happening upstream to
> any comparable extent.

From my personal experience (and as above), and talking specifically
about PMU drivers, I think that the opposite is true. This is not to say
there aren't issues; I would not be surprised if there are. But it's
disingenuous to say that mainline code is worse than that which exists
in a vendor kernel when the latter is demonstrably much easier to break
than the former.

If there are issues you are aware of, please report them. If those
issues only exist in non-upstream code, then the applicable concerns are
somewhat different (though certainly still exist).

But please, let's frame the argument to match reality.

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2016-08-04 at 17:10 +0100, Mark Rutland wrote:
> On Thu, Aug 04, 2016 at 11:44:28AM -0400, Daniel Micay wrote:
> > 
> > Qualcomm's drivers might be lower quality than core kernel code, but
> > they're way above the baseline set by mainline kernel drivers...
> 
> I don't think that's true for the arm/arm64 perf code.

The baseline architecture support is essentially core kernel code. I
agree it's much better than the SoC vendor code. You're spending a lot
of time auditing, fuzzing and improving the code in general, which is
not true for most drivers. They don't get that attention.

> I think we've done a reasonable job of testing and fixing those, along
> with core infrastructure issues. The perf fuzzer runs for a very long
> time on a mainline kernel without issues, while on my Nexus 5x I get a
> hard lockup after ~85 seconds (and prior to the last android update
> the
> lockup was instantaneous).
>
> From my personal experience (and as above), and talking specifically
> about PMU drivers, I think that the opposite is true. This is not to
> say
> there aren't issues; I would not be surprised if there are. But it's
> disingenuous to say that mainline code is worse than that which exists
> in a vendor kernel when the latter is demonstrably much easier to
> break
> than the former.

I wasn't talking specifically about perf.

> If there are issues you are aware of, please report them. If those
> issues only exist in non-upstream code, then the applicable concerns
> are
> somewhat different (though certainly still exist).

I'm not going to do volunteer work for a corporation. I've learned that
lesson after spending years doing it.

> But please, let's frame the argument to match reality.

The argument is framed in reality. Stating that it now often takes a few
hours to find a vulnerability with the unaltered, widely known public
perf fuzzer is not impressive. It's really an argument for claiming that
it's a significant security issue.

[toc] | [prev] | [next] | [standalone]

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

On Thu, Aug 04, 2016 at 12:32:32PM -0400, Daniel Micay wrote:
> On Thu, 2016-08-04 at 17:10 +0100, Mark Rutland wrote:
> I wasn't talking specifically about perf.

Then this is irrelevant to a discussion about limiting access to the
perf interface.

Hardening drivers in general is a very interesting topic, but it is a
different topic.

> > But please, let's frame the argument to match reality.
> 
> The argument is framed in reality. Stating that it now often takes a
> few hours to find a vulnerability with the unaltered, widely known
> public perf fuzzer is not impressive. It's really an argument for
> claiming that it's a significant security issue.

My claim was not that the mainline code was impressively perfect, but
rather that the vendor code was worse, countering a prior claim
otherwise. Hence, reality.

There is cetainly much that can be done to improve things, if we discuss
that which is actually applicable.

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

> My claim was not that the mainline code was impressively perfect, but
> rather that the vendor code was worse, countering a prior claim
> otherwise. Hence, reality.

You're arguing with a straw man.

I was responding to a comment about out-of-tree code, not generic
architecture perf drivers vs. alternative versions by SoC vendors.

Qualcomm and other vendors landing their drivers in mainline would be
nice, but it wouldn't make it inherently higher quality. I don't really
see what it has to do with this, which I why I responded...

[toc] | [prev] | [next] | [standalone]

#1456069 — 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 disappears.
That is very brittle design.

What I see as much more palatable is a design that allows for
features to be turned off in sandboxes.

So please if you are going to worry about disabling large swaths of
the kernel to reduce the attack surface please come up with designs
that are not brittle in allowing users to use a feature nor are they
brittle in keeping the feature disabled where you want it disabled.


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 implementing totalitarianism to avoid malicious code exploiting
bugs in the kernel.  I am not interested in that future.

Especially when dealing with disabling code to reduce attack surface,
when then are no known attacks what we are actually dealing with
is a small percentage probability reduction that a malicious attacker
will be able to exploit the attack.

Remember security is as much about availability as it is about
integrity.  You keep imagining features that are great big denial of
service attacks on legitimate users.

Kees Cook <keescook@chromium.org> writes:

> On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra <peterz@infradead.org> 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 possible.)

I vote for sandboxes.  Perhaps seccomp.  Perhaps a per userns sysctl.
Perhaps something else.

Eric

[toc] | [prev] | [next] | [standalone]

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

On Tue, Aug 02, 2016 at 12:04:34PM -0700, Kees Cook wrote:

> Now, obviously, these API have huge value, otherwise they wouldn't
> exist in the first place, and they wouldn't be built into end-user
> kernels if they were universally undesirable. But that's not the
> situation: the APIs are needed, but they lack the appropriate knobs to
> control their availability.

So far so good, but I take exception with the suggestion that the
proposed knob is appropriate.

> And this isn't just about Android: regular
> distro kernels (like Debian, who also uses this patch) tend to build
> in everything so people can use whatever they want. But for admins
> that want to reduce their systems' attack surface, there needs to be
> ways to disable things like this.

And here I think you're overestimating the knowledge of most admins.

> > So the problem I have with this is that it will completely inhibit
> > development of things like JITs that self-profile to re-compile
> > frequently used code.
> 
> This is a good example of a use-case where this knob would be turned
> down. But for many many other use-cases, when presented with a
> pre-built kernel, there isn't a way to remove the attack surface.

No, quite the opposite. Having this knob will completely inhibit
development of such applications. Worse it will probably render perf
dead for quite a large body of developers.

The moment you frame it like: perf or sekjurity, and even default to
no-perf-because-sekjurity, a whole bunch of corporate IT departments
will not enable this, even for their developers.

Have you never had to 'root' your work machine to get work done? I have.
Luckily this was pre-secure-boot times so it was trivial since I had
physical access to the machine. But it still sucked I had to fight IT
over mostly 'trivial' crap.

> > I would much rather have an LSM hook where the security stuff can do
> > more fine grained control of things. Allowing some apps perf usage while
> > denying others.
> 
> I'm not against an LSM, but I think it's needless complexity when
> there is already a knob for this but it just doesn't go "high" enough.
> :)

So what will you to the moment the Google Dalvik guys come to you and
say: "Hey, we want to do active profiling to do better on-line code
generation?".

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.

[toc] | [prev] | [next] | [standalone]

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

Far from trying to kill perf, we want (and require) perf to be
available to developers on Android. All that this patch enables us to
do is gate it behind developer settings - just like we do with other
developer targeted features.

(apologies for the dup, bounced due to non-plaintext)

On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, Aug 02, 2016 at 12:04:34PM -0700, Kees Cook wrote:
>
>> Now, obviously, these API have huge value, otherwise they wouldn't
>> exist in the first place, and they wouldn't be built into end-user
>> kernels if they were universally undesirable. But that's not the
>> situation: the APIs are needed, but they lack the appropriate knobs to
>> control their availability.
>
> So far so good, but I take exception with the suggestion that the
> proposed knob is appropriate.
>
>> And this isn't just about Android: regular
>> distro kernels (like Debian, who also uses this patch) tend to build
>> in everything so people can use whatever they want. But for admins
>> that want to reduce their systems' attack surface, there needs to be
>> ways to disable things like this.
>
> And here I think you're overestimating the knowledge of most admins.
>
>> > So the problem I have with this is that it will completely inhibit
>> > development of things like JITs that self-profile to re-compile
>> > frequently used code.
>>
>> This is a good example of a use-case where this knob would be turned
>> down. But for many many other use-cases, when presented with a
>> pre-built kernel, there isn't a way to remove the attack surface.
>
> No, quite the opposite. Having this knob will completely inhibit
> development of such applications. Worse it will probably render perf
> dead for quite a large body of developers.
>
> The moment you frame it like: perf or sekjurity, and even default to
> no-perf-because-sekjurity, a whole bunch of corporate IT departments
> will not enable this, even for their developers.
>
> Have you never had to 'root' your work machine to get work done? I have.
> Luckily this was pre-secure-boot times so it was trivial since I had
> physical access to the machine. But it still sucked I had to fight IT
> over mostly 'trivial' crap.
>
>> > I would much rather have an LSM hook where the security stuff can do
>> > more fine grained control of things. Allowing some apps perf usage while
>> > denying others.
>>
>> I'm not against an LSM, but I think it's needless complexity when
>> there is already a knob for this but it just doesn't go "high" enough.
>> :)
>
> So what will you to the moment the Google Dalvik guys come to you and
> say: "Hey, we want to do active profiling to do better on-line code
> generation?".
>
> 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.
>
>

[toc] | [prev] | [next] | [standalone]

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

On Tue, Aug 2, 2016 at 2:52 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote:
>> When kernel.perf_event_paranoid is set to 3 (or greater), disallow
>> all access to performance events by users without CAP_SYS_ADMIN.
>>
>> This new level of restriction is intended to reduce the attack
>> surface of the kernel. Perf is a valuable tool for developers but
>> is generally unnecessary and unused on production systems. Perf may
>> open up an attack vector to vulnerable device-specific drivers as
>> recently demonstrated in CVE-2016-0805, CVE-2016-0819,
>> CVE-2016-0843, CVE-2016-3768, and CVE-2016-3843.
>
> We have bugs we fix them, we don't kill complete infrastructure because
> of them.

I understand that point of view, but it isn't what things look like
for the average end-user of Linux. The lifetime on bugs is very long,
even in upstream (see both Jon Corbet and my talks about this: an
average of 5 years from introduction to fix), and gets drawn out even
further by vendors with slow (or missing) update processes. Being able
to remove attack surface is a fundamental first step of security
defense, and things like perf, user namespaces, and similar APIs,
expose a lot of attack surface when they are enabled. And the evidence
for this attack surface being a real-world risk is in the history of
security vulnerabilities (that we know about!) in these various APIs.

Now, obviously, these API have huge value, otherwise they wouldn't
exist in the first place, and they wouldn't be built into end-user
kernels if they were universally undesirable. But that's not the
situation: the APIs are needed, but they lack the appropriate knobs to
control their availability. And this isn't just about Android: regular
distro kernels (like Debian, who also uses this patch) tend to build
in everything so people can use whatever they want. But for admins
that want to reduce their systems' attack surface, there needs to be
ways to disable things like this.

>> This new level of
>> restriction allows for a safe default to be set on production systems
>> while leaving a simple means for developers to grant access [1].
>
> So the problem I have with this is that it will completely inhibit
> development of things like JITs that self-profile to re-compile
> frequently used code.

This is a good example of a use-case where this knob would be turned
down. But for many many other use-cases, when presented with a
pre-built kernel, there isn't a way to remove the attack surface.

> I would much rather have an LSM hook where the security stuff can do
> more fine grained control of things. Allowing some apps perf usage while
> denying others.

I'm not against an LSM, but I think it's needless complexity when
there is already a knob for this but it just doesn't go "high" enough.
:)

-Kees

-- 
Kees Cook
Brillo & Chrome OS Security

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web