[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 19 Nov 2019 15:54:44 -0600
From: Tianlin Li <tli@...italocean.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: kernel-hardening@...ts.openwall.com,
Kees Cook <keescook@...omium.org>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...hat.com>,
Russell King <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Greentime Hu <green.hu@...il.com>,
Vincent Chen <deanbo422@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>,
"H . Peter Anvin" <hpa@...or.com>,
x86@...nel.org,
Jessica Yu <jeyu@...nel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Jiri Kosina <jikos@...nel.org>,
Miroslav Benes <mbenes@...e.cz>,
Petr Mladek <pmladek@...e.com>,
Joe Lawrence <joe.lawrence@...hat.com>
Subject: Re: [RFC PATCH] kernel/module: have the callers of set_memory_*()
check the return value
> On Nov 19, 2019, at 3:38 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Tue, Nov 19, 2019 at 09:51:49AM -0600, Tianlin Li wrote:
>> Right now several architectures allow their set_memory_*() family of
>> functions to fail, but callers may not be checking the return values. We
>> need to fix the callers and add the __must_check attribute. They also may
>> not provide any level of atomicity, in the sense that the memory
>> protections may be left incomplete on failure. This issue likely has a few
>> steps on effects architectures[1]:
>> 1)Have all callers of set_memory_*() helpers check the return value.
>> 2)Add __much_check to all set_memory_*() helpers so that new uses do not
>> ignore the return value.
>> 3)Add atomicity to the calls so that the memory protections aren't left in
>> a partial state.
>>
>> Ideally, the failure of set_memory_*() should be passed up the call stack,
>> and callers should examine the failure and deal with it. But currently,
>> some callers just have void return type.
>>
>> We need to fix the callers to handle the return all the way to the top of
>> stack, and it will require a large series of patches to finish all the three
>> steps mentioned above. I start with kernel/module, and will move onto other
>> subsystems. I am not entirely sure about the failure modes for each caller.
>> So I would like to get some comments before I move forward. This single
>> patch is just for fixing the return value of set_memory_*() function in
>> kernel/module, and also the related callers. Any feedback would be greatly
>> appreciated.
>
> Please have a look here:
>
> https://lkml.kernel.org/r/20191111131252.921588318@infradead.org <https://lkml.kernel.org/r/20191111131252.921588318@infradead.org>
>
> Much of the code you're patching is slated for removal.
>
> Josh also has patches reworking KLP and there's some ARM64 patches
> pending at which point we can also delete module_disable_ro().
Thanks for the information. I will check the code.
Content of type "text/html" skipped
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.
