Date: Thu, 17 Jan 2019 17:15:27 -0800 From: Nadav Amit <nadav.amit@...il.com> To: "H. Peter Anvin" <hpa@...or.com> Cc: Masami Hiramatsu <mhiramat@...nel.org>, Rick Edgecombe <rick.p.edgecombe@...el.com>, Andy Lutomirski <luto@...nel.org>, Ingo Molnar <mingo@...hat.com>, LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, Peter Zijlstra <peterz@...radead.org>, Damian Tometzki <linux_dti@...oud.com>, linux-integrity <linux-integrity@...r.kernel.org>, LSM List <linux-security-module@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org>, Kernel Hardening <kernel-hardening@...ts.openwall.com>, Linux-MM <linux-mm@...ck.org>, Will Deacon <will.deacon@....com>, ard.biesheuvel@...aro.org, kristen@...ux.intel.com, deneen.t.dock@...el.com Subject: Re: [PATCH 17/17] module: Prevent module removal racing with text_poke() > On Jan 17, 2019, at 3:58 PM, H. Peter Anvin <hpa@...or.com> wrote: > > On 1/16/19 11:54 PM, Masami Hiramatsu wrote: >> On Wed, 16 Jan 2019 16:32:59 -0800 >> Rick Edgecombe <rick.p.edgecombe@...el.com> wrote: >> >>> From: Nadav Amit <namit@...are.com> >>> >>> 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. Yes, that what the mutex was supposed to achieve. It’s not supposed just to check whether it is a code page, but also that it is the same code page that you wanted to patch. > 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. This will not tell you that you have the *right* code-page. The module notifiers help to do so, since they synchronize the text poking with the module removal. > (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.) I really need to read your patches more carefully to see what you mean. Anyhow, so what do you prefer? I’m ok with either one: 1. Keep this patch 2. Remove this patch and change into a comment on text_poke() 3. Just drop the patch
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.