linux-kernel - Re: [PATCH] tpm/tpm_i2c_infineon: ensure no ongoing commands on shutdown

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:   Mon, 23 Jan 2017 15:57:49 -0700
From:   Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:     Andrey Pronin <apronin@...omium.org>
Cc:     Peter Huewe <peterhuewe@....de>,
        Marcel Selhorst <tpmdd@...horst.net>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        tpmdd-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
        semenzato@...omium.org, groeck@...omium.org
Subject: Re: [PATCH] tpm/tpm_i2c_infineon: ensure no ongoing commands on
 shutdown

On Mon, Jan 23, 2017 at 02:19:29PM -0800, Andrey Pronin wrote:

> Simplifying to class vs driver handlers, it checks class suspend
> first. And if it exists, calls it. Otherwise, it calls driver
> suspend. So, it's "either-or", not "first one, then another".
> Unless I'm missing something obvious, of course...

I belive the typical approach is that the class handler then chains to
the driver handler at the proper point in the shutdown flow. (ie this
way class code can execute before and after the driver power
management method)

> if it is needed. Even if we reverse the order and do "driver
> first, and iff it doesn't exist, then class", we'd still
> need to create and export 'tpm_shutdown' for drivers to use

The purpose of the driver shutdown would be to shutdown the bus, not
the chip. So it would be called with ops already disabled by the core
code, there is never a reason for a bus driver to call tpm_shutdown.

> We can go the register_reboot_notifier() route. Which already
> explicitly supports priorites for those notify handlers, so one

This is probably OK too, but it just feels weird to ignore the basic
core code pattern and fall back to notifiers, but I understand it can
be hard to make those changes.. But still worth at least one attempt,
IMHO.

Jason