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


Groups > linux.kernel > #1562324

Re: [RFC][PATCH] x86: Verify access_ok() context

From Andy Lutomirski <luto@amacapital.net>
Newsgroups linux.kernel
Subject Re: [RFC][PATCH] x86: Verify access_ok() context
Date 2017-01-19 01:30 +0100
Message-ID <t18M1-2Gh-1@gated-at.bofh.it> (permalink)
References (3 earlier) <sGpeN-365-23@gated-at.bofh.it> <sKYQF-3mX-9@gated-at.bofh.it> <t0m4G-5H7-13@gated-at.bofh.it> <t0nk6-6qK-11@gated-at.bofh.it> <t16Kd-1su-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Jan 18, 2017 at 2:16 PM, David Smith <dsmith@redhat.com> wrote:
> On 01/16/2017 03:14 PM, Thomas Gleixner wrote:
>> On Mon, 16 Jan 2017, David Smith wrote:
>>
>>> If you call access_ok() with page faulting disabled, you'll still see
>>> this new warning.
>>
>> And how so? It's just checking for task context. page fault disable/enable
>> has absolutely nothing to do with that.
>
> True, task context and page fault disable/enable have nothing to do with each other. However, the access_ok() comment states:
>
>  * Context: User context only. This function may sleep if pagefaults are
>  *          enabled.
>
> That seems to indicate that the function won't sleep if pagefaults are disabled, and thus there is no need for a CONFIG_DEBUG_ATOMIC_SLEEP warning if pagefaults are disabled.

ISTM even with pagefault_disable() in play, using access_ok() from,
say, interrupt context is dangerous unless you've first checked that
you're in a task.  But I guess that in_task() would still return
false, e.g. in perf.

>
>>> If you put that new access_ok() call in a module that gets
>>> loaded/unloaded, you see one warning for every module load, which gets a
>>> bit annoying.
>>
>> Can you please elaborate where this access_ok() is placed in the module
>> code?
>
> It doesn't really matter where you place the access_ok() call in the module code. If you call access_ok() in a module, then that module has its own WARN_ON_ONCE() static variable. If access_ok() was a function exported from the kernel, then there would be only one copy of the WARN_ON_ONCE() static variable.

That doesn't seem like such a big deal to me.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [RFC][PATCH] x86: Verify access_ok() context David Smith <dsmith@redhat.com> - 2017-01-16 21:30 +0100
  Re: [RFC][PATCH] x86: Verify access_ok() context Thomas Gleixner <tglx@linutronix.de> - 2017-01-16 22:50 +0100
    Re: [RFC][PATCH] x86: Verify access_ok() context David Smith <dsmith@redhat.com> - 2017-01-18 23:20 +0100
      Re: [RFC][PATCH] x86: Verify access_ok() context Andy Lutomirski <luto@amacapital.net> - 2017-01-19 01:30 +0100
        Re: [RFC][PATCH] x86: Verify access_ok() context David Smith <dsmith@redhat.com> - 2017-01-19 16:40 +0100
        Re: [RFC][PATCH] x86: Verify access_ok() context Peter Zijlstra <peterz@infradead.org> - 2017-01-20 09:30 +0100
          Re: [RFC][PATCH] x86: Verify access_ok() context Thomas Gleixner <tglx@linutronix.de> - 2017-01-20 10:00 +0100
      Re: [RFC][PATCH] x86: Verify access_ok() context Thomas Gleixner <tglx@linutronix.de> - 2017-01-19 19:50 +0100
        Re: [RFC][PATCH] x86: Verify access_ok() context "Frank Ch. Eigler" <fche@redhat.com> - 2017-01-19 21:30 +0100
          Re: [RFC][PATCH] x86: Verify access_ok() context Thomas Gleixner <tglx@linutronix.de> - 2017-01-19 22:20 +0100
            Re: [RFC][PATCH] x86: Verify access_ok() context "Frank Ch. Eigler" <fche@redhat.com> - 2017-01-19 22:30 +0100
              Re: [RFC][PATCH] x86: Verify access_ok() context Peter Zijlstra <peterz@infradead.org> - 2017-01-19 23:30 +0100
              Re: [RFC][PATCH] x86: Verify access_ok() context Thomas Gleixner <tglx@linutronix.de> - 2017-01-20 00:50 +0100

csiph-web