linux-kernel - Re: [RFC] mips: Add MXU context switching support

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] [day] [month] [year] [list]

Message-ID: <CALCETrWio8FO2yJXdsRUYDNQFwuF-ihr=EbopM6bOkfXnsrWPg@mail.gmail.com>
Date:	Tue, 5 Jul 2016 09:17:49 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Paul Burton <paul.burton@...tec.com>
Cc:	Alex Thorlton <athorlton@....com>, zhaoxiu.zeng@...il.com,
	Ingo Molnar <mingo@...nel.org>,
	Markos Chandras <markos.chandras@...tec.com>,
	chenhc@...ote.com, Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Lameter <cl@...ux.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Zubair.Kakakhel@...tec.com, alex.smith@...tec.com,
	PrasannaKumar Muralidharan <prasannatsmkumar@...il.com>,
	Leonid Yegoshin <Leonid.Yegoshin@...tec.com>,
	f.fainelli@...il.com, Mateusz Guzik <mguzik@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Michal Hocko <mhocko@...e.com>,
	"Maciej W. Rozycki" <macro@...tec.com>,
	Kees Cook <keescook@...omium.org>,
	Linux MIPS Mailing List <linux-mips@...ux-mips.org>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	John Stultz <john.stultz@...aro.org>,
	James Hogan <james.hogan@...tec.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	David Daney <david.daney@...ium.com>,
	Jiri Slaby <jslaby@...e.cz>
Subject: Re: [RFC] mips: Add MXU context switching support

On Jul 5, 2016 5:35 AM, "Paul Burton" <paul.burton@...tec.com> wrote:
>
> Hi PrasannaKumar,
>
>
> On 25/06/16 13:14, PrasannaKumar Muralidharan wrote:
>>
>> From: PrasannaKumar Muralidharan <prasannatsmkumar@...il.com>
>>
>> This patch adds support for context switching Xburst MXU registers. The
>> registers are named xr0 to xr16. xr16 is the control register that can
>> be used to enable and disable MXU instruction set. Read and write to
>> these registers can be done without enabling MXU instruction set by user
>> space. Only when MXU instruction set is enabled any MXU instruction
>> (other than read or write to xr registers) can be done. xr0 is always 0.
>
>
> Do you have any examples of userland programs making use of MXU? They would be useful in allowing people to test this patch.
>
> How have you tested this?
>
>
>> Kernel does not know when MXU instruction is enabled or disabled. So
>> during context switch if MXU is enabled in xr16 register then MXU
>> registers are saved, restored when the task is run.
>
>
> I'm not convinced this is the right way to go. It seems complex & fragile vs the alternatives, the simplest of which could be to just always save & restore MXU context in kernels with MXU support. Is there a significant performance cost to just unconditionally saving & restoring the MXU context? That is after all what Ingenic's vendor kernel, which it looks like large parts of your patch are taken from, does.
>
>
>> When user space
>> application enables MXU, it is not reflected in other threads
>> immediately. So for convenience the applications can use prctl syscall
>> to let the MXU state propagate across threads running in different CPUs.
>
>
> Surely it wouldn't be reflected at all, since each thread has its own MXU context? Would you expect applications to actually want to enable MXU on one thread & make use of it from other already running threads? Off the top of my head I can't think of why that would be useful, so I'm wondering whether it would be better to just let each thread handle enabling MXU if it wants & leave the kernel out of it. If we just save & restore unconditionally then this becomes a non-issue anyway.
>

I don't know much about MIPS, but switching save/restore off depending
on a bit of *user* state sounds like a gaping security hole.