linux-kernel - Re: [tpmdd-devel] [PATCH 1/2] tpm: Apply an adapterlimit for retransmission.

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: <CAFqH_52TFBWLCXY00pTNdhDKJJ=R3uhY6kpp7Sgx2-fHnq-_iw@mail.gmail.com>
Date:   Mon, 27 Feb 2017 22:30:32 +0100
From:   Enric Balletbo Serra <eballetbo@...il.com>
To:     Wolfram Sang <wsa@...-dreams.de>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Peter Huewe <peterhuewe@....de>,
        Marcel Selhorst <tpmdd@...horst.net>,
        Andrey Pronin <apronin@...gle.com>,
        tpmdd-devel@...ts.sourceforge.net,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [tpmdd-devel] [PATCH 1/2] tpm: Apply an adapterlimit for retransmission.

2017-02-27 20:12 GMT+01:00 Wolfram Sang <wsa@...-dreams.de>:
> Hi,
>
>> >> > Rather than trying small and smaller transfers, would it not be better
>> >> > to get the i2c core to expose the quirk info about transfer limits?
>> >> >
>> >>
>> >> Sounds a good idea to me, I guess the quirk info can be accessed with
>> >>
>> >>   tpm_dev.client->adapter->quirks->max_read_len
>> >>
>> >> so I think we don't need to touch the i2c core. I'll propose a second version of the patch.
>> >
>> > Hi Enric
>> >
>> > You should probably ask Wolfram Sang <wsa@...-dreams.de>, the i2c
>> > subsystem maintainer. He may prefer adding an API call.
>
> Thanks for pointing me to this thread.
>
> I understand it looks tempting to use the quirks struct directly, but I
> don't think this is the proper solution. Quirks are complex and and to
> determine which one finally applies, you need all the logic encoded in
> i2c_check_for_quirks(). Which already gets called on every transfer.
>
> So, my suggestion would be to simply fall back to a sane minimum when
> the maximum failed. 32 (I2C_SMBUS_BLOCK_MAX) should be a good choice.
>

Sounds a good solution for me, I'll test and send a new version of the patches.

> BTW I noted that the original patch checks for -EINVAL. The core returns
> -EOPNOTSUPP, though. So, a) the patch needs to be adapted

Yes I already detected this, In this series I forget to fixup the
patch that fixed this when I did the git rebase. It's is fixed in the
second version.

> and b) it
> looks the i2c host driver returning -EINVAL could be converted to use
> the quirk infrastructure? Which driver is it?
>
> Regards,
>
>    Wolfram
>

Regards,
  Enric