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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43B7BC432BE for ; Wed, 1 Sep 2021 07:27:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 26B9661056 for ; Wed, 1 Sep 2021 07:27:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242559AbhIAH2J (ORCPT ); Wed, 1 Sep 2021 03:28:09 -0400 Received: from mail.skyhub.de ([5.9.137.197]:37646 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231739AbhIAH2I (ORCPT ); Wed, 1 Sep 2021 03:28:08 -0400 Received: from zn.tnic (p200300ec2f0f3000ff66408ba4c79392.dip0.t-ipconnect.de [IPv6:2003:ec:2f0f:3000:ff66:408b:a4c7:9392]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id BF9E61EC051E; Wed, 1 Sep 2021 09:27:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1630481226; 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: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=6p6hxtBn8gLHMzkoO0aM3iXU0A8QRJ+1AexPaqoZxP0=; b=aBEpLFUNgs+kBXiS5AwC0yCDqg3DN5FnxwBqH+NRcVcw9mCi+OgzOhfIcxF7YLFtgHqzBB /fuOcdGMdcS1AvVMZWNi9ynkGYuss7WmbFwInv158Vm0/mXEThvDpMrIC1SUmiBWgadeie 6YjaXvPwXGSZkOzqi3eC5A9KxMVwtYE= Date: Wed, 1 Sep 2021 09:27:40 +0200 From: Borislav Petkov To: "Luck, Tony" Cc: Thomas Gleixner , Linus Torvalds , Al Viro , Dan Williams , LKML , the arch/x86 maintainers , Lukas Bulwahn Subject: Re: [patch 01/10] x86/fpu/signal: Clarify exception handling in restore_fpregs_from_user() Message-ID: References: <20210830162545.374070793@linutronix.de> <87zgsyg0eg.ffs@tglx> <87zgsye9kn.ffs@tglx> <20210831183921.GA1687448@agluck-desk2.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210831183921.GA1687448@agluck-desk2.amr.corp.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 31, 2021 at 11:39:21AM -0700, Luck, Tony wrote: > You can imagine all you want. And if your imagination is based > on experiences with very old systems like Haswell (launched in 2015) > then you'd be right to be skeptical of firmware capabilities. I wish it were only Haswell boxes. Do you remember how many times I've talked to you in the past about boxes with broken einj? I don't think they were all Haswell but I haven't kept track. > Turn off eMCA in BIOS to avoid this. I'll try. That is, provided there even is such an option. > The injection controls in the memory controller can only be accessed > in SMM mode. Some paranoia there that some ring0 attack could inject > errors at random intervals causing major costs to diagnose and replace > "failing" DIMMs. So documentation wouldn't help Linux because it just > can't twiddle the necessary bits in the h/w. Yah, that's why this thing needs a BIOS switch which controls injection. And probably they do that already. > Downsides of ACPI/EINJ today: > 1) Availability on production machines. It is always disabled by default > in BIOS. That's ok. > OEMs may not provide a setup option to turn it on (or may have deleted > the code to support it completely). Yeah, that's practically the same thing I'm complaining about - einj is just as useless as before in that case. > Intel's pre-production servers always have the code, and the setup > option to enable. Except that only you and a couple of partners have access to such boxes. I guess tglx has too and if so that at least answers his initial complaint about not having an injection method to test kernel code. > 2) Doesn't inject to 3D-Xpoint (that has its own injection method, but > it is annoying to have to juggle two methods). I guess that doesn't matter for our use case of wanting to test the MCE code, provided one can at least inject somewhere. > 3) Hard/impossible to inject into SGX memory (because BIOS is untrusted > and isn't allowed to do a store to push the poison data to DDR). Oh well. So, I really wanna believe you that injection capability has improved but until I see it with my own eyes, I will remain very much sceptical. And considering how firmware and OEMs are at play here, sceptical is just the right stance. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette