| 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
| ||
|
Message-ID: <e1ba712b42886594fe1095019f2c5813@kernel.org>
Date: Fri, 10 Jan 2020 15:21:59 +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 12:00, Suzuki Kuruppassery Poulose wrote:
> On 18/12/2019 11:56, Marc Zyngier wrote:
>> 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
>
> Thanks I have fixed this locally now.
>
>> would get set though. But it probably doesn't matter (WTF is going
>
> Right. That cannot be set to begin with, as the first access to FP/SIMD
> injects an abort back to the guest, which is why I added a WARN() to
> begin with.
>
> Just wanted to be extra safe.
>
>> to run KVM with such broken HW?), and better safe than sorry.
>
> Right, with no COMPAT KVM support it is really hard to get this far.
So with the above fix:
Acked-by: Marc Zyngier <maz@...nel.org>
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists