> On Oct 4, 2018, at 9:45 AM, Rik van Riel <r...@surriel.com> wrote: > > On Thu, 2018-10-04 at 16:05 +0200, Sebastian Andrzej Siewior wrote: > > >> In v3 I dropped that decouple idea. I also learned that the wrpkru >> instruction is not privileged and so caching it in kernel does not >> work. > > Wait, so any thread can bypass its memory protection > keys, even if there is a seccomp filter preventing > it from calling the PKRU syscalls? > > Is that intended? > > Is that simply a hardware limitation, or something > where we can set a flag somewhere to force tasks to > go through the kernel? > > Hardware limitation.
- [PATCH 10/11] x86/fpu: prepare copy_fpstate_to_s... Sebastian Andrzej Siewior
- [PATCH 09/11] x86/entry: add TIF_LOAD_FPU Sebastian Andrzej Siewior
- [PATCH 08/11] x86/fpu: Always store the register... Sebastian Andrzej Siewior
- [PATCH 07/11] x86/pkeys: Drop the preempt-disabl... Sebastian Andrzej Siewior
- [PATCH 05/11] x86/fpu: set PKRU state for kernel... Sebastian Andrzej Siewior
- [PATCH 06/11] x86/pkeys: make init_pkru_value st... Sebastian Andrzej Siewior
- [PATCH 03/11] x86/fpu: make __raw_xsave_addr() u... Sebastian Andrzej Siewior
- [PATCH 04/11] x86/fpu: eager switch PKRU state Sebastian Andrzej Siewior
- [PATCH 01/11] x86/entry: remove _TIF_ALLWORK_MAS... Sebastian Andrzej Siewior
- Re: [PATCH 00/11 v3] x86: load FPU registers on ... Rik van Riel
- Re: [PATCH 00/11 v3] x86: load FPU register... Andy Lutomirski
- Re: [PATCH 00/11 v3] x86: load FPU register... Sebastian Andrzej Siewior