linux-kernel - Re: [PATCH v4] livepatch: Cleanup module page permission changes

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 04 Dec 2015 12:15:05 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Jiri Kosina <jikos@...nel.org>,
	Josh Poimboeuf <jpoimboe@...hat.com>
Cc:	Seth Jennings <sjenning@...hat.com>,
	Vojtech Pavlik <vojtech@...e.com>,
	linux-kernel@...r.kernel.org, live-patching@...r.kernel.org,
	Miroslav Benes <mbenes@...e.cz>
Subject: Re: [PATCH v4] livepatch: Cleanup module page permission changes

Jiri Kosina <jikos@...nel.org> writes:
> On Thu, 3 Dec 2015, Josh Poimboeuf wrote:
>
>> Calling set_memory_rw() and set_memory_ro() for every iteration of the
>> loop in klp_write_object_relocations() is messy, inefficient, and
>> error-prone.
>> 
>> Change all the read-only pages to read-write before the loop and convert
>> them back to read-only again afterwards.
>> 
>> Suggested-by: Miroslav Benes <mbenes@...e.cz>
>> Signed-off-by: Josh Poimboeuf <jpoimboe@...hat.com>
>> ---
>> Based on the following branches:
>> - git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching.git for-4.5/core
>> - git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git modules-next
>> 
>> - v4: rebase onto Chris's sympos changes
>> - v3: use new module_{disable,enable}_ro() functions (in linux-next)
>
> Rusty,
>
> how would you like to handle this cross-tree dependency?
>
> My proposals:
>
> (1) I pull your 'modules-next' branch, apply this patch on top, and wait 
>     for your merge with Linus and send merge request afterwards

Hmm, that's always a bit icky.

> (2) If you are okay with rebasing your tree (seems like this is 
>     ocassionally happening), how about you prepare a branch that'd have 
>     just b3212ec77 ("module: keep percpu symbols in module's symtab") on 
>     top of some common base, I merge it, and the cross-dependency is gone

I don't like to rebase, but I am *always* happy to give patches away :)

> (3) I cherry-pick b3212ec77 ("module: keep percpu symbols in 
>     module's symtab") from your tree, and apply this on top. git will 
>     handle duplicate commits when Linus merges both just fine

That's pretty ugly.

> (4) I sign this patch off and you merge it
>
> (4) seems really outside the regular process. (1) is really tricky wrt. 
> coordination of timing during the merge window. I'd prefer (2) (more 
> git-ish way of doing things, but would require you rebasing your tree) or 
> eventually (3) (git will handle this with grace).

The last won't work anyway, since I'd need to grab stuff from your
tree...

> What do you think?

Please cherry-pick my whole module-next tree.  They have my SOB already.
You can push them to Linus along with your livepatch stuff at your
convenience for the merge window.

Once you've done that, I'll rebase modules-next down to nothing.  If
something else comes in, I'll either add it there or toss it to you,
depending on whether it conflicts or not.

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/