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: <CACdnJutomLNthYDzEc0wFBcBHK5iqnk0p-hkAkp57zQZ38oGPA@mail.gmail.com>
Date:   Mon, 26 Aug 2019 10:40:25 -0700
From:   Matthew Garrett <mjg59@...gle.com>
To:     Seunghun Han <kkamagui@...il.com>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Peter Huewe <peterhuewe@....de>,
        "open list:TPM DEVICE DRIVER" <linux-integrity@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: tpm: Remove a busy bit of the NVS area for
 supporting AMD's fTPM

On Mon, Aug 26, 2019 at 1:18 AM Seunghun Han <kkamagui@...il.com> wrote:
> To support AMD's fTPM, I removed the busy bit from the ACPI NVS area like
> the reserved area so that AMD's fTPM regions could be assigned in it.

drivers/acpi/nvs.c saves and restores the contents of NVS regions, and
if other drivers use these regions without any awareness of this then
things may break. I'm reluctant to say that just unilaterally marking
these regions as available is a good thing, but it's clearly what's
expected by AMD's implementation. One approach would be to have a
callback into the nvs code to indicate that a certain region should be
handed off to a driver, which would ensure that we can handle this on
a case by case basis?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ