linux-kernel - Re: [PATCH v2 3/3] livepatch: force transition process to finish

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:   Wed, 30 Aug 2017 09:24:36 +0200
From:   Pavel Machek <pavel@....cz>
To:     Miroslav Benes <mbenes@...e.cz>
Cc:     jpoimboe@...hat.com, jeyu@...nel.org, jikos@...nel.org,
        pmladek@...e.com, lpechacek@...e.cz, live-patching@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/3] livepatch: force transition process to finish

On Thu 2017-08-10 12:48:15, Miroslav Benes wrote:
> If a task sleeps in a set of patched functions uninterruptibly, it could
> block the whole transition process indefinitely.  Thus it may be useful
> to clear its TIF_PATCH_PENDING to allow the process to finish.
> 
> Admin can do that now by writing to force sysfs attribute in livepatch
> sysfs directory. TIF_PATCH_PENDING is then cleared for all tasks and the
> transition can finish successfully.
> 
> Important note! Use wisely. Admin must be sure that it is safe to
> execute such action. This means that it must be checked that by doing so
> the consistency model guarantees are not violated.

Yes, that's what admins are good for. Magically determining what state
their machine is in, and deciding if all the processes are in the sane
state and what the consequences are. They have all the tools they need
to do that, like JTAG connection to the CPU and about 10 years of
time... do they?

This should taint the kernel at the very least.

It should also require capabilities beyond "normal root", because it
allows malicious admin to do "bad things (tm)" to the kernel.

								Pavel

> diff --git a/Documentation/livepatch/livepatch.txt b/Documentation/livepatch/livepatch.txt
> index 343b0bfa1b9f..7626d1b947c2 100644
> --- a/Documentation/livepatch/livepatch.txt
> +++ b/Documentation/livepatch/livepatch.txt
> @@ -183,7 +183,11 @@ attribute. Reading from the file returns all available operations. Writing one
>  of the strings to the file executes the operation. "signal" is available for
>  signalling all remaining blocking tasks. This is an alternative for
>  SIGSTOP/SIGCONT approach mentioned in the previous paragraph. It should also be
> -less harmful to the system.
> +less harmful to the system. "force" clears TIF_PATCH_PENDING flag of all tasks
> +and thus forces the tasks to the patched state. Important note! Use "force"
> +wisely. Administrator must be sure that it is safe to execute such action. This
> +means that it must be checked that by doing so the consistency model guarantees
> +are not violated.

You may want to elaborate here a lot. If you want to pretend
administrator can decide this, you need to describe what the model is,
and how administrator get enough information about the system state.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)