Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 17 Jan 2019 15:58:31 -0800
From: "H. Peter Anvin" <>
To: Masami Hiramatsu <>,
        Rick Edgecombe <>
Cc: Andy Lutomirski <>, Ingo Molnar <>,,,
        Thomas Gleixner <>, Borislav Petkov <>,
        Nadav Amit <>,
        Dave Hansen
        Peter Zijlstra <>,,,,,,,,,,,
        Nadav Amit <>
Subject: Re: [PATCH 17/17] module: Prevent module removal racing with

On 1/16/19 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?

The issue isn't the module list, but rather when it is safe to free the
contents, so we don't clobber anything. We absolutely need to enforce
that we can't text_poke() something that might have already been freed.

That being said, we *also* really would prefer to enforce that we can't
text_poke() memory that doesn't actually contain code; as far as I can
tell we don't currently do that check.

This, again, is a good use for a separate mm context. We can enforce
that that context will only ever contain valid page mappings for actual
code pages.

(Note: in my proposed algorithm, with a separate mm, replace INVLPG with
switching CR3 if we have to do a rollback or roll forward in the
breakpoint handler.)


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.