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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 8BA20C742A2 for ; Thu, 11 Jul 2019 20:33:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 56EB4206B8 for ; Thu, 11 Jul 2019 20:33:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="h8dfg609" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730242AbfGKUd0 (ORCPT ); Thu, 11 Jul 2019 16:33:26 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:33343 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729616AbfGKUd0 (ORCPT ); Thu, 11 Jul 2019 16:33:26 -0400 Received: by mail-io1-f66.google.com with SMTP id z3so15580454iog.0 for ; Thu, 11 Jul 2019 13:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1rQWFvQ45gUjO8JhBu1BZ8yG6gJGSx9SFOsZLTKRxg8=; b=h8dfg609t0LWfBFR5ij3Lmr6akiDQjlKwkNM+EqaXfWfEs3eMurxebMJ4NX+Q/+AHp gw9VhCYI2l7gWg29DRK1Tu6Pnkq1wrfbM6+b/N7FBPHBeZRa+Ndj9LGLz0VP+AThoBLB Nez7ayFrx66wd69B+IJKnJJI/+jw5QJkwVSGPquFF1hdedJ8uTkS5E+qfIN4DMN+32di Zob7A8SodxjQnJl0hLOccP8fh3gglPHU5ggURbusWF616wk+75rrxToYXKqJgMsAmST7 vwwqqXXGMzo91euWDVUrM0yOmwUs292hYbXizxw+ozpQh9NBz1kZWBTD3ECrUq032fRl U48A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1rQWFvQ45gUjO8JhBu1BZ8yG6gJGSx9SFOsZLTKRxg8=; b=bWenkx9X/QcGWstJeHst+kapMNyBYQCThZi9AlLhpdcWEEW4hr/TZmucMaiyfFzD3W 5AH5kd2/empNbFaMm5Knbk/CEqq7UrwHJNaIikPLrNmOwQOiOk2tzQkvUxAuHM9D51zF iA3jrUWigXIPfTh2wdE17gp5SkqolKGRUbTUpok08OSeV9GX6CZU9OvntVNXMGUp6c/j O1vKHO/YKodzSl9OKKa8luqVNsVB+ls4jDMGf0T4y3cKQQD4XKnJff1jmoqggwfpFRJP fjc6qGAzoeEbFn4pq28mmLwIziawG8i1mNAFvsg0jTpZt8Rl216lvFqEseMdf3wSJ8yd 8cXQ== X-Gm-Message-State: APjAAAVpkgLoe/i7d+O9EYpb13PraqrFUNJc2Lzl8S853iZIEg79oX+e vWe35grqV/G1ub/kZvPss1HVpNSDfDInNR2bU9hmJBEa1UI= X-Google-Smtp-Source: APXvYqwDgkvNEPSUYh8/ZFQ6yCS54ifuJJcYqOEv/n7MelLIW9JH5L58ISp5Pd71W3fDzVpIuiG5W8MN+PN2Dq64MnE= X-Received: by 2002:a6b:f114:: with SMTP id e20mr3646041iog.169.1562877205424; Thu, 11 Jul 2019 13:33:25 -0700 (PDT) MIME-Version: 1.0 References: <20190711145850.GC25807@ziepe.ca> <20190711185027.GG25807@ziepe.ca> In-Reply-To: From: Matthew Garrett Date: Thu, 11 Jul 2019 13:33:14 -0700 Message-ID: Subject: Re: [PATCH] tpm_crb - workaround broken ACPI tables To: "Safford, David (GE Global Research, US)" Cc: Jason Gunthorpe , "linux-integrity@vger.kernel.org" , "jarkko.sakkinen@linux.intel.com" , "Wiseman, Monty (GE Global Research, US)" Content-Type: text/plain; charset="UTF-8" Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On Thu, Jul 11, 2019 at 12:32 PM Safford, David (GE Global Research, US) wrote: > As far as I can tell, some OEMs simply are putting bad data in the tables. > I have seen at least one report where a BIOS update did fix the problem. The issue is that the CRB region is mapped into a region marked as ACPI NVS. drivers/acpi/nvs.c claims this region and as a result a resource conflict is generated. Since Windows is clearly fine with other drivers using ACPI NVS regions, the correct fix involves figuring out a way to either share these resources or allow tpm_crb to reclaim the region from the NVS driver. Note that the NVS driver's behaviour is to save and restore NVS regions over suspend/resume, so simply forcibly allocating the resource will result in two separate codepaths touching the region on resume - this seems like a bad outcome. Ideally this could be solved generically, but practically (given we've only seen this around TPMs, as far as I can tell) adding a hook to nvs.c that allowed drivers aware of the issue to have the space handed off to them might be easier. Have you seen this on any non-AMD systems?