linux-kernel - Re: [PATCH 0/3] livepatch: introduce atomic replace

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:   Thu, 10 Aug 2017 13:12:25 +0200 (CEST)
From:   Miroslav Benes <mbenes@...e.cz>
To:     Jason Baron <jbaron@...mai.com>
cc:     linux-kernel@...r.kernel.org, live-patching@...r.kernel.org,
        jpoimboe@...hat.com, jeyu@...nel.org, jikos@...nel.org,
        pmladek@...e.com
Subject: Re: [PATCH 0/3] livepatch: introduce atomic replace

> Ok - associating the "atomic replace" with the patch itself makes sense to me.
> It would also basically work, I think with the patch I proposed except for the
> case where the the "atomic replace" was on top of several non-"atomic replace"
> patches. The reason is that the "atomic replace" I posted looks back 1 patch
> to see what it needs to replace (assuming all patches are in atomic replace
> mode). So instead of just looking back 1 patch, it could 'look back' and make
> sure it was replacing all previously loaded patches.

Yes, this should not be a problem to implement with the current code.

But I must say I am not entirely happy with the code as it is. The big 
advantage is that there are almost no changes to the consistency model. 
Almost everything is created and allocated during the initialization and 
the patch then looks ordinary. The current code can handle it smoothly. 
"Dynamic" superstructure is what I am not happy with. It is too 
complicated in my opinion. On the other hand I don't see a simple way out 
now.

1. We can try to make your code "nicer".

2. The main problem is that all user structures (klp_func, klp_object, 
klp_patch) are statically allocated in a kernel module. You need to add 
dynamically allocated structures, which is not easy. We can either change 
everything to dynamic allocation, or make everything static. As far as the 
former is concerned, we've been down that road IIRC. It didn't end up 
well. Is the latter even possible?

3. We could bypass everything and register special no-op fops to each 
reverted function. Those could be held and handled separately. It could be 
simpler, but it might be problematic to deal with the consistency model 
interaction.

Thoughts?

Regards,
Miroslav