linux-kernel - Re: Questions on the task isolation patches

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]

Date:   Fri, 16 Dec 2016 16:00:48 -0500
From:   Chris Metcalf <cmetcalf@...lanox.com>
To:     yunhong jiang <yunhong.jiang@...ux.intel.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: Questions on the task isolation patches

Sorry for the slow response - I have been busy with some other things.

On 12/6/2016 4:43 PM, yunhong jiang wrote:
> On Fri, 2 Dec 2016 13:58:08 -0500
> Chris Metcalf <cmetcalf@...lanox.com> wrote:
>
>> On 12/1/2016 5:28 PM, yunhong jiang wrote:
>>> a) If the task isolation need prctl to mark itself as isolated,
>>> possibly the vCPU thread can't achieve it. First, the vCPU thread
>>> may need system service during OS booting time, also it's the
>>> application, instead of the vCPU thread to decide if the vCPU
>>> thread should be isolated. So possibly we need a mechanism so that
>>> another process can set the vCPU thread's task isolation?
>> These are good questions.  I think that the we would probably want to
>> add a KVM mode that did the prctl() before transitioning back to the
> Would prctl() when back to guest be too heavy?

It's a good question; it can be heavy.  But the design for task isolation is that
the task isolated process is always running in userspace anyway.  If you are
transitioning in and out of the guest or host kernels frequently, you probably
should not be using task isolation, but just regular NOHZ_FULL.

>> guest.  But then, in the same way that we currently allow another
>> prctl() from a task-isolated userspace process, we'd probably need to
> You mean currently in your patch we alraedy can do the prctl from 3rd party
> process to task-isolate a userspace process? Sorry that I didn't notice that
> part.

Sorry, I think I wasn't clear.  Normally when you are running task isolated
and you enter the kernel, you will get a fatal signal.  The exception is if you
call prctl itself (or exit), the kernel tolerates it without a signal, since obviously
that's how you need to cleanly tell the kernel you are done with task isolation.

My point in the previous email was that we might need to similarly tolerate
a guest exit without causing a fatal signal to the userspace process.  But as
I think about it, that's probably not true; we probably would want to notify
the guest kernel of the task isolation violation and have it kill the userspace
process just as if it had entered the guest kernel.

Perhaps the way to drive this is to have task isolation be triggered from
the guest's prctl up to the host, so there's some kind of KVM exit to
the host that indicates that the guest has a userspace process that
wants to run task isolated, at which point qemu invokes task isolation
on behalf of the guest then returns to the guest to set up its own
virtualized task isolation.  It does get confusing!

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com