linux-kernel - Re: [PATCH v2 07/17] debugobjects: Move printk out of db lock critical sections

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 29 Nov 2018 14:09:28 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Waiman Long <longman@...hat.com>,
        Ingo Molnar <mingo@...hat.com>,
        Will Deacon <will.deacon@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org, kasan-dev@...glegroups.com,
        linux-mm@...ck.org, iommu@...ts.linux-foundation.org,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Tejun Heo <tj@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v2 07/17] debugobjects: Move printk out of db lock
 critical sections

On Mon 2018-11-26 13:57:09, Sergey Senozhatsky wrote:
> On (11/23/18 12:48), Petr Mladek wrote:
> [..]
> > > This should make serial consoles re-entrant.
> > > So printk->console_driver_write() hopefully will not deadlock.
> > 
> > Is the re-entrance safe? Some risk might be acceptable in Oops/panic
> > situations. It is much less acceptable for random warnings.
> 
> Good question.
> 
> But what's the alternative? A deadlock in a serial console driver; such
> that even panic() is not guaranteed to make through it (at least of now).
> debug objects are used from the code which cannot re-entrant console
> drivers.
> 
> bust_spinlock is called from various paths, not only panic.
> git grep bust_spinlocks | wc -l
> 62

bust_spinlocks() is followed by die() in several situations. The rests
seems to be Oops situations where we an invalid address is being accessed.
There is a nontrivial chance that the system would die anyway.

Now, if I look into Documentation/core-api/debug-objects.rst,
the API is used to detect:

  -  Activation of uninitialized objects
  -  Initialization of active objects
  -  Usage of freed/destroyed objects

Of course, all the above situations might lead to the system crash. But
even in the worst case, use-after-free, there is a non-trivial chance
that the data still would be valid and the system would survive.

There might be many other warnings of the same severity.

> So we already switch to re-entrant consoles (and accept the risks) in
> mm/fault.c, kernel/traps.c and so on. Which, I guess, makes us a little
> more confident, faults/traps happen often enough.

Where is the border line, please?
Do we want to have the kernel sources full of bust_spinlocks() callers?

> It seems, that, more or less, serial consoles are ready to handle it.
> UART consoles in ->write() callbacks just do a bunch of writel() [for
> every char + \r\n].

But oops_in_progress does not affect only serial (UART) consoles.

We want safe lockless consoles. We do not want to run
a most-of-the-time-safe code too often.

BTW: I have heard that someone from the RT people is working
on a big printk() rewrite. One part is a lockless buffer. Another
part should be a different handling of safe (lockless) and
more complicated consoles. It was presented on some recent
conference (I forgot which one). I do not know any details.
But the first version should be sent in a near future.

Best Regards,
Petr