| 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
| ||
|
Date: Tue, 13 Jan 2015 13:13:34 -0500 From: Rik van Riel <riel@...hat.com> To: Andy Lutomirski <luto@...capital.net> CC: Oleg Nesterov <oleg@...hat.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, Matt Fleming <matt.fleming@...el.com>, Borislav Petkov <bp@...e.de>, Paolo Bonzini <pbonzini@...hat.com>, Thomas Gleixner <tglx@...utronix.de> Subject: Re: [RFC PATCH 04/11] x86,fpu: defer FPU restore until return to userspace -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/13/2015 12:57 PM, Andy Lutomirski wrote: > On Tue, Jan 13, 2015 at 9:44 AM, Rik van Riel <riel@...hat.com> > wrote: On 01/13/2015 12:18 PM, Andy Lutomirski wrote: >>>> - Task is not current and FPU is in memory. - Task is not >>>> current and FPU is loaded into some cpu. > >> Same for this one. When the task is not current, the FPU state >> will have been saved to memory. If we try running the task >> somewhere else, it devolves to "FPU is in memory". > > > Isn't there a case where the FPU is in memory *and* in the cpu > regs? Isn't that how you can skip reloading the FPU after going > idle and returning? Is this what fpu_lazy_restore is for? > Confused. Indeed, if we end up running the task on the same CPU again, and the FPU still has the state loaded, we may skip restoring the FPU state. >>>> Am I missing anything? (In lazy mode, there are a few more >>>> involving CR0.TS.) >>>> >>>> That's five states, plus an optional cpu number. But we have >>>> tons of state variable that can express all kinds of nonsense >>>> things. >>>> >>>> If we asserted that we were in a sensible state and fixed >>>> the things that exited the sensible states, maybe this would >>>> be easier to understand and debug. > > Lets see what things we could test, at different points. > > 1) At context switch time, we need to make sure that the previous > task will no longer have __thread_has_fpu() > > 2) When loading the FPU state, we need to make sure that the > current task does not have __thread_has_fpu() > >> Examples, any of which may be wrong: > >> If !current, then !TIF_LOAD_FPU We set TIF_LOAD_CPU on the next task at context switch time, which is different from the current task. I suspect we can deal with that exception, though :) What we can test is that "new" does not already have TIF_LOAD_CPU set... >> If switching out a task with TIF_LOAD_FPU set, then !has_fpu ... and that old does not have both TIF_LOAD_FPU and has_fpu. >> If last_cpu == smp_processor_id(), then fpu_owner == fpu. Not necessarily, since the task may not have entered userspace in a very long time, so it may not have loaded its FPU context. >> If has_fpu, then the task must be current somewhere and last_cpu >> must be the cpu on which it's current. Indeed, if has_fpu, then last_cpu must match the current cpu. - -- All rights reversed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUtWBOAAoJEM553pKExN6DNwIH/2wzfLqqM1V/Asd29nidDUrw zD7HN//LyWTLjNMfAS4M/rOk3LsbphFBOo2L5BE7CYoNAGEWwKcQi7ld3dDAXeZL +AkRtzMNEU1NqzrtnpGhABBrn3wBXwr9ldKSlaVQhYUop3q5Hhg8lyo2v+wWKf7y ULi/RLiERS72tUomFXTE4RT021N2h+tl42jSREEyT0+VqEc7vqTlb5fctsF3VAhS g48fX/VOYit3rXFU9hPz9m9vnodsEGCapdRxsXaE4xA7lg8dZ5WsaAos2TUwPQYt EyCbS9z2Yzy1UpySwZudo6OGbQIaugOtgrcCS/cvdvlRb8K4mLe+807MPGmBOGA= =7wEX -----END PGP SIGNATURE----- -- 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/
Powered by blists - more mailing lists