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]
Date:   Tue, 19 Dec 2017 00:34:46 +0100
From:   Javier Martinez Canillas <javierm@...hat.com>
To:     Jason Gunthorpe <jgg@...pe.ca>,
        "Shaikh, Azhar" <azhar.shaikh@...el.com>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        James Ettle <james@...le.org.uk>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "james.l.morris@...cle.com" <james.l.morris@...cle.com>
Subject: Re: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on
 Braswell system

Hello Jason,

On 12/18/2017 09:19 PM, Jason Gunthorpe wrote:
> On Mon, Dec 18, 2017 at 07:34:29PM +0000, Shaikh, Azhar wrote:
> 
>>> IIUC, if CLKRUN_EN is enabled, then all the devices attached to the
>>> LPC bus have to support the CLKRUN protocol. My guess is that on
>>> some Braswell systems LPC power management is enabled but the TPM
>>> device doesn't have CLKRUN support.
>>
>> I think this is what might be happening here.
> 
> That makes it a BIOS bug, not a chipset bug, and we shouldn't be
> trying to fix it like this in Linux.
>

Indeed, the system integrator should make sure that all peripherals that
are connected through the LPC bus either support the CLKRUN protocol and
CLKRUN_EN is enabled or CLKRUN_EN should be disabled.
 
> Based on the original discussion I always thought this was an Intel
> chipset bug and applies to all cases.
>

After thinking about this and with a better understanding of the issue,
I think we have 2 options (please let me know if I got something wrong):

1) Leave the code as is and apply the patch I shared with James. In that
   case the CLKRUN protocol will be disabled only during TPM transactions
   and not enabled again after transactions if it wasn't enabled.

   This shouldn't affect other peripherals since even if they have CLKRUN
   support, they should work correctly while CLKRUN protocol is disabled.

   The disadvantage is that TPM devices that have CLKRUN support (do they
   exist?) will not take the advantage of the power management feature of
   stopping the LPC host LCLK clock during low-power states.

2) Drop the pending CLKRUN patch in linux-tpmdd and revert CLKRUN commit
   in mainline. And instead of disabling the CLKRUN protocol during the
   TPM transactions, disable if the CLKRUN_EN is enabled and the system
   is in a list of systems that have a TPM that doesn't support CLKRUN.

   This list could be for example a struct dmi_system_id array and match
   using DMI data on module_init().

   The advantage is that TPM devices with CLKRUN protocol support could
   make use of the CLKRUN power management feature and only systems with
   a TPM that doesn't support the CLKRUN protocol will disable it.

   The disadvantage is that the struct dmi_system_id array to match will
   have to be maintained and every known-to-be-broken system added to it.

Thoughts?

> Jason
> 

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ