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] [day] [month] [year] [list]
Message-ID: <CAHjaAcR51FKgBMF736-qsW0gKHxzf4jMJDsDnh0mm2dACOV65A@mail.gmail.com>
Date:   Tue, 27 Aug 2019 16:38:01 +0900
From:   Seunghun Han <kkamagui@...il.com>
To:     "Safford, David (GE Global Research, US)" <david.safford@...com>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Peter Huewe <peterhuewe@....de>,
        Thomas Gleixner <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>
Subject: Re: [PATCH] tpm: tpm_crb: Add an AMD fTPM support feature

> > From: linux-integrity-owner@...r.kernel.org <linux-integrity-
> > owner@...r.kernel.org> On Behalf Of Jarkko Sakkinen
> > Sent: Monday, August 26, 2019 1:59 AM
> > To: Seunghun Han <kkamagui@...il.com>
> > Cc: Peter Huewe <peterhuewe@....de>; Thomas Gleixner
> > <tglx@...utronix.de>; linux-kernel@...r.kernel.org; linux-
> > integrity@...r.kernel.org
> > Subject: EXT: Re: [PATCH] tpm: tpm_crb: Add an AMD fTPM support feature
> >
> > On Mon, Aug 26, 2019 at 02:40:19AM +0900, Seunghun Han wrote:
> > > I'm Seunghun Han and work at the Affiliated Institute of ETRI. I got
> > > an AMD system which had a Ryzen Threadripper 1950X and MSI mainboard,
> > > and I had a problem with AMD's fTPM. My machine showed an error
> > > message below, and the fTPM didn't work because of it.
> > >
> > > [    5.732084] tpm_crb MSFT0101:00: can't request region for resource
> > >                [mem 0x79b4f000-0x79b4ffff]
> > > [    5.732089] tpm_crb: probe of MSFT0101:00 failed with error -16
> > >
> > > When I saw the iomem areas and found two TPM CRB regions were in the
> > > ACPI NVS area.  The iomem regions are below.
> > >
> > > 79a39000-79b6afff : ACPI Non-volatile Storage
> > >   79b4b000-79b4bfff : MSFT0101:00
> > >   79b4f000-79b4ffff : MSFT0101:00
> > >
> > > After analyzing this issue, I found out that a busy bit was set to the
> > > ACPI NVS area, and the current Linux kernel allowed nothing to be
> > > assigned in it. I also found that the kernel couldn't calculate the
> > > sizes of command and response buffers correctly when the TPM regions
> > were two or more.
> > >
> > > To support AMD's fTPM, I removed the busy bit from the ACPI NVS area
> > > so that AMD's fTPM regions could be assigned in it. I also fixed the
> > > bug that did not calculate the sizes of command and response buffer
> > correctly.
>
> The problem is that the acpi tables are _wrong_ in this and other cases.
> They not only incorrectly report the area as reserved, but also report
> the command and response buffer sizes incorrectly. If you look at
> the addresses for the buffers listed in the crb control area, the sizes
> are correct (4Kbytes).  My patch uses the control area values, and
> everything works. The remaining problem is that if acpi reports the
> area as NVS, then the linux nvs driver will try to use the space.
> I'm looking at how to fix that. I'm not sure, if simply removing
> the busy bit is sufficient.
> Dave

Thank you for your reply. I have read your patch. However, I would
like to solve this problem without a kernel parameter. In my view, I'd
better change the crb_fixup_cmd_size() function because the TPM CRB
driver wants to get the command buffer and response buffer sizes by
using the function.

I agree on that removing the busy bit is sufficient.

Seunghun

>
> > >
> > > Signed-off-by: Seunghun Han <kkamagui@...il.com>
> >
> > You need to split this into multiple patches e.g. if you think you've fixed a
> > bug, please write a patch with just the bug fix and nothing else.
> >
> > For further information, read the section three of
> >
> > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> >
> > I'd also recommend to check out the earlier discussion on ACPI NVS:
> >
> > https://lore.kernel.org/linux-
> > integrity/BCA04D5D9A3B764C9B7405BBA4D4A3C035EF7BC7@...MBAPA12.e
> > 2k.ad.ge.com/
> >
> > /Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ