linux-kernel - Re: [PATCH] MIPS: MSA: misaligned 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <550A9C0F.6060505@imgtec.com>
Date:	Thu, 19 Mar 2015 09:51:11 +0000
From:	James Hogan <james.hogan@...tec.com>
To:	Leonid Yegoshin <Leonid.Yegoshin@...tec.com>
CC:	"linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
	"wangr@...ote.com" <wangr@...ote.com>,
	"peterz@...radead.org" <peterz@...radead.org>,
	Qais Yousef <Qais.Yousef@...tec.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ralf@...ux-mips.org" <ralf@...ux-mips.org>,
	"davidlohr@...com" <davidlohr@...com>,
	"chenhc@...ote.com" <chenhc@...ote.com>,
	"manuel.lauss@...il.com" <manuel.lauss@...il.com>,
	"mingo@...nel.org" <mingo@...nel.org>
Subject: Re: [PATCH] MIPS: MSA: misaligned support

On 18/03/15 23:25, Leonid Yegoshin wrote:
> On 03/18/2015 03:12 PM, James Hogan wrote:
>> Hi Leonid,
>>
>> On Wed, Mar 18, 2015 at 12:46:51PM -0700, Leonid Yegoshin wrote:
>>
>>> thread_msa_context_live() == check of TIF_MSA_CTX_LIVE == existence of
>>> MSA context for thread.
>>> It differs from MSA is owned by thread, it just says that thread has
>>> already initialized MSA.
>>>
>>> Unfortunate choice of function name, I believe.
>> Right (I mis-read when its cleared when i grepped). Still, that would
>> make it even harder to hit since lose_fpu wouldn't clear it, and you
>> already would've taken an MSA disabled exception first.
> No, lose_fpu disables MSA now, saves MSA context and switches off
> TIF_USEDMSA. See 33c771ba5c5d067f85a5a6c4b11047219b5b8f4e, "MIPS:
> save/disable MSA in lose_fpu".
> 
> However, a process still has MSA context initialized and it is indicated
> by TIF_MSA_CTX_LIVE.
> It should have it before it can get any AdE exception on MSA instruction.

Yes, exactly.

> 
>>
>> Anyway, my point was that there's nothing invalid about an unaligned
>> load being the first MSA instruction. You might use it to load the
>> initial vector state.
> 
> No, it is invalid. If MSA is disabled it should trigger "MSA Disabled"
> exception.

It's valid for the user to start their program with a ld.b.
As you say, it'll raise an MSA disabled exception first though. The
handler will own MSA, and set TIF_MSA_CTX_LIVE, which makes the check
pointless?

I suppose an AdE from a normal unaligned load could still race with
another thread modifying the instruction to an MSA ld.b, but even if it
did, I don't think it would do any harm?

> 
> Unfortunately, some HW versions had AdE first and it may be logical from
> some HW point (if access is done before instruction is completely
> decoded). But that is wrong.

Yes, MSA Disabled would clearly come under "Instruction Validity
Exceptions", which is very sensibly higher priority than "Address error
- Data access".

Anyway, at the very least it needs a comment to justify what it is
trying to catch and what harm it is trying to avoid, since it isn't
obvious, and tbh seems pointless.

Cheers
James


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