linux-kernel - Re: module: save load_info for livepatch modules

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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.LNX.2.00.1511131338510.15073@pobox.suse.cz>
Date:	Fri, 13 Nov 2015 13:46:34 +0100 (CET)
From:	Miroslav Benes <mbenes@...e.cz>
To:	Jessica Yu <jeyu@...hat.com>
cc:	Josh Poimboeuf <jpoimboe@...hat.com>,
	Petr Mladek <pmladek@...e.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Seth Jennings <sjenning@...hat.com>,
	Jiri Kosina <jikos@...nel.org>,
	Vojtech Pavlik <vojtech@...e.com>, linux-api@...r.kernel.org,
	live-patching@...r.kernel.org, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: module: save load_info for livepatch modules

On Fri, 13 Nov 2015, Miroslav Benes wrote:

> As for load_info, I don't have a strong opinion whether to keep it for all 
> modules or for livepatch modules only.

I have. We cannot keep it, even for livepatch modules...

In info->hdr there is a temporary copy of the whole module (see 
init_module syscall and the first parts of load_module). In load_module 
a final struct module * is created with parts of info->hdr copied (I'll 
get to that later). So if we saved info->hdr for later purposes we would 
just have two copies of the same module in the memory. The original one 
with !SHF_ALLOC sections and everything in vmalloc area, and the new
final copy with SHF_ALLOC sections only. This is not good.

If this is correct (and I think it is after some staring into the code) we 
need to do something different. We should build the info we need for 
delayed relocations from the final copy (or refactor the existing 
module code).

The second problem... dynrela sections need to be marked with SHF_ALLOC 
flag, right? Perhaps it would be better not to do it and copy also 
SHF_RELA_LIVEPATCH sections. It is equivalent but not hidden somewhere 
else (in userspace "kpatch-build" tool).

Miroslav
--
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/