linux-kernel - Re: [PATCH v3 2/2] livepatch: add 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]

Message-ID: <20171020074421.GC29163@pathway.suse.cz>
Date:   Fri, 20 Oct 2017 09:44:21 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Jason Baron <jbaron@...mai.com>
Cc:     Miroslav Benes <mbenes@...e.cz>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        linux-kernel@...r.kernel.org, live-patching@...r.kernel.org,
        jeyu@...nel.org, jikos@...nel.org
Subject: Re: [PATCH v3 2/2] livepatch: add atomic replace

On Thu 2017-10-19 17:44:32, Jason Baron wrote:
> So for atomic replace, it seems as if we don't want to allow replaced
> patches to be re-enabled but instead, allow them to rmmod/insmod'ed to
> allow revert.
>
> In your above proposed model around immediate, if all patches are
> immediate then the atomic replace doesn't allow any of the previous
> patches to be removed from the kernel via rmmod, while if all patches
> are handled using the consistency model then all patches previous to the
> atomic replace patch could be removed via rmmod. So this would simplify
> the logic around when replaced patches could removed.

yes

> I was thinking in the current model to only allow the one preceding
> patch to the atomic replace patch to be rmmod'able, if the atomic
> replace patch was using the consistency model (to avoid complications
> with immediate functions/patches). And this could be extended to all
> *all* patches previous to the atomic replace patch to be rmmod'able when
> we move to the proposed model around immediates. So I don't think this
> should hold up the atomic replace patches?

Yes, this sounds reasonable from the atomic replace patch point of view.

Well, the consistency model is broken at the moment when immediate
flag is used. We should fix this ASAP. IMHO, the fix might need to go
upstream before the atomic replace feature. It might be even stable
material.

Best Regards,
Petr

PS: One problem is that there are some conferences (Kernel Summit,
Open Source Summit) next week. At least all livepatch-related SUSE
people will be less reachable.