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  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, 17 Jan 2019 18:07:03 +0000
From:   Nadav Amit <>
To:     Masami Hiramatsu <>
CC:     Rick Edgecombe <>,
        Andy Lutomirski <>,
        Ingo Molnar <>,
        Linux List Kernel Mailing <>,
        the arch/x86 maintainers <>,
        "H. Peter Anvin" <>,
        Thomas Gleixner <>,
        Borislav Petkov <>,
        Dave Hansen <>,
        Peter Zijlstra <>,
        Damian Tometzki <>,
        linux-integrity <>,
        LSM List <>,
        Andrew Morton <>,
        Kernel Hardening <>,
        Linux-MM <>, Will Deacon <>,
        Ard Biesheuvel <>,
        "" <>,
        "" <>
Subject: Re: [PATCH 17/17] module: Prevent module removal racing with

> On Jan 16, 2019, at 11:54 PM, Masami Hiramatsu <> wrote:
> On Wed, 16 Jan 2019 16:32:59 -0800
> Rick Edgecombe <> wrote:
>> From: Nadav Amit <>
>> It seems dangerous to allow code modifications to take place
>> concurrently with module unloading. So take the text_mutex while the
>> memory of the module is freed.
> At that point, since the module itself is removed from module list,
> it seems no actual harm. Or would you have any concern?

So it appears that you are right and all the users of text_poke() and
text_poke_bp() do install module notifiers, and remove the module from their
internal data structure when they are done (*). As long as they prevent
text_poke*() to be called concurrently (e.g., using jump_label_lock()),
everything is fine.

Having said that, the question is whether you “trust” text_poke*() users to
do so. text_poke() description does not day explicitly that you need to
prevent modules from being removed.

What do you say?

(*) I am not sure about kgdb, but it probably does not matter much

Powered by blists - more mailing lists