Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [RFC PATCH 04/10 v2 ] x86/fpu: eager switch PKRU state
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <099b9f82-e162-c91a-bc51-aa1ac0cd50aa@redhat.com>
Date:   Wed, 19 Sep 2018 12:49:35 -0700
Cc:     Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Rik van Riel <riel@surriel.com>,
        linux-kernel@vger.kernel.org, x86@kernel.org,
        Andy Lutomirski <luto@kernel.org>,
        =?utf-8?Q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= <rkrcmar@redhat.com>,
        kvm@vger.kernel.org, "Jason A. Donenfeld" <Jason@zx2c4.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <27496B23-92A0-462C-A198-6A4413634488@amacapital.net>
References: <8e5b64e4-b3e6-f884-beb6-b7b69ab2d8c1@redhat.com> <20180914203501.qibhpmueosvkr74w@linutronix.de> <a239e97a-d1a1-388e-5db9-10758c33d702@redhat.com> <20180918142701.atfb4ul45k7tl6ew@linutronix.de> <7e9a13f3-93f5-fe4a-20d2-f4f9407bd43b@redhat.com> <83e271e1298d603c1105dd0dbea32d67da9cf1fa.camel@surriel.com> <36e8493f-f994-e885-8fe6-2f0d4a9904a1@redhat.com> <20180918160419.2zeru6xnufxixcax@linutronix.de> <11aa7d0f4ba36eff8b61a5dc1bd35ee5195fd576.camel@surriel.com> <c3492a53-74cd-4474-b664-f227ef37b7de@redhat.com> <20180919165719.iepvc7tg6aabp5mm@linutronix.de> <099b9f82-e162-c91a-bc51-aa1ac0cd50aa@redhat.com>
To:     Paolo Bonzini <pbonzini@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Sep 19, 2018, at 10:00 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>=20
>> On 19/09/2018 18:57, Sebastian Andrzej Siewior wrote:
>>> On 2018-09-19 07:55:51 [+0200], Paolo Bonzini wrote:
>>> A kthread can do use_mm/unuse_mm.
>>=20
>> indeed. The FPU struct for the kernel thread isn't valid / does not
>> contain the expected PKRU value. So loading the pkru value from the
>> struct FPU does not work as expected. We could set it to 0 for a kernel
>> thread so we don't end up with a random value.
>> If we want to get this usecase working then we would have to move pkru
>> value from FPU to mm_struct and consider it in use_mm(). Do we want
>> this?
>=20
> As a start, I think keeping it in the FPU struct but loading it
> unconditionally will work.  kthreads will not obey PKU but it will be
> better already.
>=20
> I honestly don't know if PKRU should be per-mm, I don't know mm very
> well despite my brilliant observation above. :)
>=20
>=20

It must be per thread.  I don=E2=80=99t think it=E2=80=99s possible to have s=
ane semantics per mm.

I also think that use_mm should set PKRU to the same value that signal handl=
ers use.  If we use 0, it=E2=80=99s a recipe for accidental PK bypass.=