> Hi Paul,
>
> On Mon, 2017-12-11 at 13:54 +0100, Paul Menzel wrote:
> > Dear Jason,
> >
> >
> > On 12/08/17 17:18, Jason Gunthorpe wrote:
> > > On Fri, Dec 08, 2017 at 05:07:39PM +0100, Paul Menzel wrote:
> > >
> > >> I have no access to the system right now, but want to point out, that the
> > >
> On Thu, Dec 21, 2017 at 6:19 PM, wrote:
> >> Hi,
> >> We have a desktop which has S3 suspend (to RAM) problem due to
> >> error messages as follows.
> >> [ 198.908282] tpm tpm0: Error (38) sending savestate before suspend
> >> [ 198.908289] __pnp_bus_suspend(): tpm_pm_suspend+0x0/0x160
>
> Hi,
> We have a desktop which has S3 suspend (to RAM) problem due to
> error messages as follows.
> [ 198.908282] tpm tpm0: Error (38) sending savestate before suspend
> [ 198.908289] __pnp_bus_suspend(): tpm_pm_suspend+0x0/0x160 returns
> 38
> [ 198.908293] dpm_run_callback(): pnp_bus_sus
> Hi Hans,
>
> Thanks a lot for your feedback.
>
> On 12/20/2017 12:43 PM, Hans de Goede wrote:
> > Hi,
> >
> > On 20-12-17 12:35, Javier Martinez Canillas wrote:
> >> Hello,
> >>
> >> Commit 5e572cab92f0 ("tpm: Enable CLKRUN protocol for Braswell
> systems")
> >> added logic in the TPM TIS drive
> [Adding Rafael and Len as they, to my knowledge, also use or have a
> access to a Dell XPS 13 9360. With latest Linux master do you get TPM
> self-test errors, when cold starting the system without the power supply
> plugged in?]
>
> Dear Mario, dear Alexander,
>
>
> the added line breaks to t
> > -Original Message-
> > From: alexander.stef...@infineon.com
> [mailto:alexander.stef...@infineon.com]
> > Sent: Thursday, December 14, 2017 6:21 AM
> > To: pmen...@molgen.mpg.de; j...@ziepe.ca
> > Cc: linux-integr...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Limonciello,
> > Mari
> [Mario from Dell added to CC list.]
>
> Dear Alexander,
>
>
> On 12/11/17 17:08, alexander.stef...@infineon.com wrote:
>
> >> On 12/08/17 17:18, Jason Gunthorpe wrote:
> >>> On Fri, Dec 08, 2017 at 05:07:39PM +0100, Paul Menzel wrote:
> >>>
> I have no access to the system right now, but
> Dear Jason,
>
>
> On 12/08/17 17:18, Jason Gunthorpe wrote:
> > On Fri, Dec 08, 2017 at 05:07:39PM +0100, Paul Menzel wrote:
> >
> >> I have no access to the system right now, but want to point out, that the
> >> log was created by `journactl -k`, so I do not know if that messes with the
> >> t
> On Thu, Dec 07, 2017 at 03:56:07PM +, alexander.stef...@infineon.com
> wrote:
>
> > > If these are intentional, it’d be great
> > > to give some hint to the user, what effect this has.
> >
> > I agree that those error messages in their current form are not that
> > helpful for the users. But
> Dear Linux folks,
>
>
> With Linux 4.15-rc2 built by the Ubuntu Kernel Team, the error messages
> below are shown by the Linux kernel. These are new.
>
> ```
> Dez 06 13:22:24 Ixpees kernel: microcode: microcode updated early to
> revision 0x62, date = 2017-04-27
> Dez 06 13:22:24 Ixpees kerne
> On Wed, Nov 22, 2017 at 06:52:03AM +,
> alexander.stef...@infineon.com wrote:
> > > > > > This seems to fail reliably with my SPI TPM 2.0. I get EIO when
> > > > > > trying
> to
> > > > > send large amounts of data, e.g. with TPM2_Hash, and subsequent
> tests
> > > > > seem to take an unusua
> > > On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote:
> > > >> The TPM burstcount status indicates the number of bytes that can
> > > >> be sent to the TPM without causing bus wait states. Effectively,
> > > >> it is the number of empty bytes in the command FIFO.
> > > >>
> > > >> Th
> > On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote:
> > >> The TPM burstcount status indicates the number of bytes that can
> > >> be sent to the TPM without causing bus wait states. Effectively,
> > >> it is the number of empty bytes in the command FIFO.
> > >>
> > >> This patch opt
> On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote:
> >> The TPM burstcount status indicates the number of bytes that can
> >> be sent to the TPM without causing bus wait states. Effectively,
> >> it is the number of empty bytes in the command FIFO.
> >>
> >> This patch optimizes the t
> > On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote:
> > > On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen
> > > wrote:
> > > > I'm implementing a fix for CVE-2017-15361 that simply blacklists
> > > > vulnerable FW versions. I think this is the only responsible action from
> > > >
> On Thu, Oct 26, 2017 at 12:26:10AM +0200, Peter Huewe wrote:
> >
> >
> > Am 25. Oktober 2017 20:53:49 MESZ schrieb Jarkko Sakkinen
> :
> > >On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote:
> > >> On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen
> > >> wrote:
> > >> > I'm implemen
> On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote:
> > On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen
> > wrote:
> > > I'm implementing a fix for CVE-2017-15361 that simply blacklists
> > > vulnerable FW versions. I think this is the only responsible action from
> > > my side tha
> The TPM burstcount status indicates the number of bytes that can
> be sent to the TPM without causing bus wait states. Effectively,
> it is the number of empty bytes in the command FIFO.
>
> This patch optimizes the tpm_tis_send_data() function by checking
> the burstcount only once. And if the
> On Fri, Oct 20, 2017 at 12:01:39PM +0300, Jarkko Sakkinen wrote:
> > On Thu, Oct 19, 2017 at 04:58:23PM +,
> alexander.stef...@infineon.com wrote:
> > > > On Tue, Oct 17, 2017 at 11:50:05AM +,
> alexander.stef...@infineon.com
> > > > wrote:
> > > > > > > Replace the specification of data
> On Tue, Oct 17, 2017 at 04:32:29PM -0400, Nayna Jain wrote:
> > The function wait_for_tpm_stat() is currently defined in
> > tpm-interface file. It is a hardware specific function used
> > only by tpm_tis and xen-tpmfront, so it is removed from
> > tpm-interface.c and defined in respective driver
> On Tue, Oct 17, 2017 at 11:50:05AM +, alexander.stef...@infineon.com
> wrote:
> > > > Replace the specification of data structures by pointer dereferences
> > > > as the parameter for the operator "sizeof" to make the corresponding
> > > > size
> > > > determination a bit safer according to t
> On Wed, 2017-10-18 at 10:44 +, alexander.stef...@infineon.com wrote:
> > > For instance, nothing about
> > > > > sizeof(type)
> > > > > vs
> > > > > sizeof(*ptr)
> > > > > makes it easier for a human to read the code.
> > > >
> > > > If it does not make it easier to read the code
> On Wed, 18 Oct 2017, alexander.stef...@infineon.com wrote:
>
> > > On Wed, 2017-10-18 at 11:00 +0200, SF Markus Elfring wrote:
> > > > > The printk removals do change the objects.
> > > > >
> > > > > The value of that type of change is only for resource limited systems.
> > > >
> > > > I imagine
> On Wed, 2017-10-18 at 11:00 +0200, SF Markus Elfring wrote:
> > > The printk removals do change the objects.
> > >
> > > The value of that type of change is only for resource limited systems.
> >
> > I imagine that such small code adjustments are also useful for other
> systems.
>
> Your imagina
> On Tue, 17 Oct 2017, Mimi Zohar wrote:
>
> > On Tue, 2017-10-17 at 14:58 +0200, Julia Lawall wrote:
> > >
> > > On Tue, 17 Oct 2017, Mimi Zohar wrote:
> > >
> > > > On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com
> > > > wrote:
> > > > > > > Replace the specification of data st
> On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com
> wrote:
> > > > Replace the specification of data structures by pointer dereferences
> > > > as the parameter for the operator "sizeof" to make the corresponding
> > > > size
> > > > determination a bit safer according to the Linu
> > Replace the specification of data structures by pointer dereferences
> > as the parameter for the operator "sizeof" to make the corresponding
> > size
> > determination a bit safer according to the Linux coding style
> > convention.
>
>
> This patch does one style in favor of the other.
I ac
> After further discussions with the Device Driver working group (ddwg),
> the following changes were made:
>
> * Check for burstcount at least once to confirm the TPM is ready to accept
> the data. Similarly, query for the TPM Expect status as sanity check at
> the end.
>
> * Make the sleep for
> On Sat, Sep 09, 2017 at 12:37:39AM +0300, Jarkko Sakkinen wrote:
> > On Fri, Sep 08, 2017 at 05:21:32PM +0200, Alexander Steffen wrote:
> > > tpm_transmit() does not offer an explicit interface to indicate the
> number
> > > of valid bytes in the communication buffer. Instead, it relies on the
>
> On Wed, Sep 06, 2017 at 02:19:28PM +,
> alexander.stef...@infineon.com wrote:
> > > On Wed, Sep 06, 2017 at 03:42:33PM +0300, Jarkko Sakkinen wrote:
> > > > On Mon, Sep 04, 2017 at 07:36:42PM +0200, Alexander Steffen wrote:
> > > > > tpm_transmit() does not offer an explicit interface to indi
> On Wed, Sep 06, 2017 at 03:42:33PM +0300, Jarkko Sakkinen wrote:
> > On Mon, Sep 04, 2017 at 07:36:42PM +0200, Alexander Steffen wrote:
> > > tpm_transmit() does not offer an explicit interface to indicate the
> > > number of valid bytes in the communication buffer. Instead, it
> > > relies on th
Yes, this fixes the issue for me. Thanks.
Alexander
> -Original Message-
> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> Sent: Tuesday, March 28, 2017 12:25 PM
> To: Steffen Alexander (IFAG CCS ESS D SW A)
> Cc: tpmdd-de...@lists.sourceforge.net; linux-security-
> mod..
> > There are a few special cases that need some thought though. For
> > example, it is possible to use an upgrade to switch the TPM family
> > from 1.2 to 2.0 (or vice versa). In this case it seems useful to let
> > the kernel reinitialize the TPM driver, so it uses the correct
> > timeouts for co
> I think the most straight-forward way to sort this out would be to limit
> validation to the resource manager.
Sounds good to me.
> If I send a fix, would you care to test it?
Sure, will do.
Alexander
>>> 2. When upgrading the firmware on my TPM, it switches to a
>>> non-standard communication mode for the upgrade process and does not
>>> communicate using TPM2.0 commands during this time. Rejecting
>>> non-TPM2.0 commands means upgrading won't be possible anymore.
>>
>> How non standard? Is the
> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-
> interface.c
> index 20b1fe3..db5ffe9 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -376,11 +376,12 @@ static bool tpm_validate_command(struct
> tpm_chip *chip, const u8 *cmd,
>
> Check for every TPM 2.0 command that the command code is supported and
> the command buffer has at least the length that can contain the header
> and the handle area.
This breaks several use cases for me:
1. I've got a TPM that implements vendor-specific command codes. Those cannot
be send to
37 matches
Mail list logo
