linux-kernel - Re: ABI change for device drivers using future AVX instruction set

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: <48678CC5.5080504@firstfloor.org>
Date:	Sun, 29 Jun 2008 15:23:17 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Avi Kivity <avi@...ranet.com>
CC:	Agner Fog <agner@...er.org>,
	Arjan van de Ven <arjan@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: ABI change for device drivers using future AVX instruction set

Avi Kivity wrote:
> Andi Kleen wrote:
>>>>> We could change kernel_fpu_begin() not to disable
>>>>> preemption, but instead set a task flag.  When we get the "no device"
>>>>> fault, if the flag is set, save the fpu state into the kernel fpu save
>>>>> area             
>>>> What kernel fpu save area do you mean?
>>>>         
>>> A new one, of course.
>>>
>>>     
>>
>> With that we would be eventually in the mess Agner talked about.
>>
>>   
> 
> If you use xsave, I don't see how this is different to the user fpu save
> area.

For once there's no clear error handling path for allocation failures
on the (arbitarily sized) xsave state. On user code that can be barely
tolerated, but for the kernel it would be deadly.

-Andi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/