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]
Message-ID: <alpine.LSU.2.20.1708101254540.7971@pobox.suse.cz>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ