linux-kernel - Re: [PATCH v2 7/7] arm64: nofpsmid: Handle TIF_FOREIGN

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: <3b30d44c34bc265ce4122396077a1670@www.loen.fr>
Date:   Wed, 18 Dec 2019 11:56:58 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Suzuki Kuruppassery Poulose <suzuki.poulose@....com>
Cc:     <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <will@...nel.org>,
        <mark.rutland@....com>, <dave.martin@....com>,
        <catalin.marinas@....com>, <ard.biesheuvel@...aro.org>,
        <christoffer.dall@....com>, Marc Zyngier <marc.zyngier@....com>
Subject: Re: [PATCH v2 7/7] arm64: nofpsmid: Handle TIF_FOREIGN_FPSTATE flag cleanly

On 2019-12-18 11:42, Suzuki Kuruppassery Poulose wrote:
> Hi Marc,
>
> On 17/12/2019 19:05, Marc Zyngier wrote:
>> Hi Suzuki,
>> On 2019-12-17 18:34, Suzuki K Poulose wrote:
>>> We detect the absence of FP/SIMD after an incapable CPU is brought 
>>> up,
>>> and by then we have kernel threads running already with
>>> TIF_FOREIGN_FPSTATE set
>>> which could be set for early userspace applications (e.g, modprobe 
>>> triggered
>>> from initramfs) and init. This could cause the applications to loop
>>> forever in
>>> do_nofity_resume() as we never clear the TIF flag, once we now know 
>>> that
>>> we don't support FP.
>>>
>>> Fix this by making sure that we clear the TIF_FOREIGN_FPSTATE flag
>>> for tasks which may have them set, as we would have done in the 
>>> normal
>>> case, but avoiding touching the hardware state (since we don't 
>>> support any).
>>>
>>> Also to make sure we handle the cases seemlessly we categorise the
>>> helper functions to two :
>>>  1) Helpers for common core code, which calls into take appropriate
>>>     actions without knowing the current FPSIMD state of the 
>>> CPU/task.
>>>
>>>     e.g fpsimd_restore_current_state(), fpsimd_flush_task_state(),
>>>         fpsimd_save_and_flush_cpu_state().
>>>
>>>     We bail out early for these functions, taking any appropriate 
>>> actions
>>>     (e.g, clearing the TIF flag) where necessary to hide the 
>>> handling
>>>     from core code.
>>>
>>>  2) Helpers used when the presence of FP/SIMD is apparent.
>>>     i.e, save/restore the FP/SIMD register state, modify the 
>>> CPU/task
>>>     FP/SIMD state.
>>>     e.g,
>>>
>>>     fpsimd_save(), task_fpsimd_load() - save/restore task FP/SIMD 
>>> registers
>>>
>>>     fpsimd_bind_task_to_cpu()  \
>>>                                 - Update the "state" metadata for 
>>> CPU/task.
>>>     fpsimd_bind_state_to_cpu() /
>>>
>>>     fpsimd_update_current_state() - Update the fp/simd state for 
>>> the current
>>>                                     task from memory.
>>>
>>>     These must not be called in the absence of FP/SIMD. Put in a 
>>> WARNING
>>>     to make sure they are not invoked in the absence of FP/SIMD.
>>>
>>> KVM also uses the TIF_FOREIGN_FPSTATE flag to manage the FP/SIMD 
>>> state
>>> on the CPU. However, without FP/SIMD support we trap all accesses 
>>> and
>>> inject undefined instruction. Thus we should never "load" guest 
>>> state.
>>> Add a sanity check to make sure this is valid.
>> Yes, but no, see below.
>>
>>>
>>> Fixes: 82e0191a1aa11abf ("arm64: Support systems without FP/ASIMD")
>>> Cc: Will Deacon <will@...nel.org>
>>> Cc: Mark Rutland <mark.rutland@....com>
>>> Cc: Catalin Marinas <catalin.marinas@....com>
>>> Cc: Marc Zyngier <marc.zyngier@....com>
>> No idea who that guy is. It's a fake! ;-)
>
> Sorry about that, will fix it.
>
>>
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
>>> ---
>>>  arch/arm64/kernel/fpsimd.c  | 31 +++++++++++++++++++++++++++----
>>>  arch/arm64/kvm/hyp/switch.c |  9 +++++++++
>>>  2 files changed, 36 insertions(+), 4 deletions(-)
>>>
>> [...]
>>
>>> diff --git a/arch/arm64/kvm/hyp/switch.c 
>>> b/arch/arm64/kvm/hyp/switch.c
>>> index 72fbbd86eb5e..9696ebb5c13a 100644
>>> --- a/arch/arm64/kvm/hyp/switch.c
>>> +++ b/arch/arm64/kvm/hyp/switch.c
>>> @@ -28,10 +28,19 @@
>>>  /* Check whether the FP regs were dirtied while in the host-side 
>>> run
>>> loop: */
>>>  static bool __hyp_text update_fp_enabled(struct kvm_vcpu *vcpu)
>>>  {
>>> +    /*
>>> +     * When the system doesn't support FP/SIMD, we cannot rely on
>>> +     * the state of _TIF_FOREIGN_FPSTATE. However, we will never
>>> +     * set the KVM_ARM64_FP_ENABLED, as the FP/SIMD accesses 
>>> always
>>> +     * inject an abort into the guest. Thus we always trap the
>>> +     * accesses.
>>> +     */
>>>      if (vcpu->arch.host_thread_info->flags & _TIF_FOREIGN_FPSTATE)
>>>          vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED |
>>>                        KVM_ARM64_FP_HOST);
>>>
>>> +    WARN_ON(!system_supports_fpsimd() &&
>>> +        (vcpu->arch.flags & KVM_ARM64_FP_ENABLED));
>> Careful, this will panic the host if it happens on a !VHE host
>> (calling non-inline stuff from a __hyp_text function is usually
>> not a good idea).
>
> Ouch! Sorry about that WARN_ON()! I could drop the warning and
> make this :
>
> if (!system_supports_fpsimd() ||
>     (vcpu->arch.host_thread_info->flags & _TIF_FOREIGN_FPSTATE))
> 	vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED |
> 			      KVM_ARM64_FP_HOST);
>
> to make sure we never say fp is enabled.
>
> What do you think ?

Sure, that would work. I can't really see how KVM_ARM64_FP_ENABLED
would get set though. But it probably doesn't matter (WTF is going
to run KVM with such broken HW?), and better safe than sorry.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...