From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56CD0C433F5 for ; Wed, 18 May 2022 01:02:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233111AbiERBCS (ORCPT ); Tue, 17 May 2022 21:02:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233077AbiERBCP (ORCPT ); Tue, 17 May 2022 21:02:15 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C2396325 for ; Tue, 17 May 2022 18:02:14 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C1103B819D2 for ; Wed, 18 May 2022 01:02:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D28C7C34116; Wed, 18 May 2022 01:02:10 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="mQPCCfqG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1652835729; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EwK9iYZioy8uS/wkcAol0jY2RzNpH6Zi8zhygVBATws=; b=mQPCCfqGYJZ1T6m0TR++PjXuliDZHnpU9ww5bi2lk9dGsIecY3ESl8StVGLNqIyC8/zgKw 6GEsTssVuTiMvMFLN3dH0qVSI6m5un8/ahjn6/+1YDjC9c4sefYJFqwbHqRCcj/06RXb/b /ZpLJTqySAIJKm63TzcIPsVnsxosALk= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 3b5780c0 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Wed, 18 May 2022 01:02:08 +0000 (UTC) Date: Wed, 18 May 2022 03:02:05 +0200 From: "Jason A. Donenfeld" To: Thomas Gleixner Cc: LKML , x86@kernel.org, Filipe Manana , Vadim Galitsin Subject: Re: [patch 0/3] x86/fpu: Prevent FPU state corruption Message-ID: References: <20220501192740.203963477@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey Thomas, On Wed, May 04, 2022 at 05:40:26PM +0200, Jason A. Donenfeld wrote: > Hi Thomas, > > On Sun, May 01, 2022 at 09:31:42PM +0200, Thomas Gleixner wrote: > > The recent changes in the random code unearthed a long standing FPU state > > corruption due do a buggy condition for granting in-kernel FPU usage. > > Thanks for working that out. I've been banging my head over [1] for a > few days now trying to see if it's a mis-bisect or a real thing. I'll > ask Larry to retry with this patchset. So, Larry's debugging was inconsistent and didn't result in anything I could piece together into basic cause and effect. But luckily Vadim, who maintains the VirtualBox drivers for Oracle, was able to reproduce the issue and was able to conduct some real debugging. I've CC'd him here. >From talking with Vadim, here are some findings thus far: - Certain Linux guest processes crash under high load. - Windows kernel guest panics. Observation: the Windows kernel uses SSSE3 in their kernel all over the place, generated by the compiler. - Moving the mouse around helps induce the crash. Observation: add_input_randomness() -> .. -> kernel_fpu_begin() -> blake2s_compress(). - The problem exhibits itself in rc7, so this patchset does not fix the issue. - Applying https://xn--4db.cc/ttEUSvdC fixes the issue. Observation: the problem is definitely related to using the FPU in a hard IRQ. I went reading KVM to get some idea of why KVM does *not* have this problem, and it looks like there's some careful code there about doing xsave and such around IRQs. So my current theory is that VirtualBox's VMM just forgot to do this, and until now this bug went unnoticed. Since VirtualBox is out of tree (and extremely messy of a codebase), and this appears to be an out of tree module problem rather than a kernel problem, I'm inclined to think that there's not much for us to do, at least until we receive information to the contrary of this presumption. But in case you do want to do something proactively, I don't have any objections to just disabling the FPU in hard IRQ for 5.18. And in 5.19, add_input_randomness() isn't going to hit that path anyway. But also, doing nothing and letting the VirtualBox people figure out their bug would be fine with me too. Either way, just wanted to give you a heads up. Jason