linux-kernel - [RESEND PATCH 00/11] platform/chrome: Kunit tests and refactor for cros_ec_cmd

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-next>] [day] [month] [year] [list]

Message-Id: <20220628024913.1755292-1-tzungbi@kernel.org>
Date:   Tue, 28 Jun 2022 02:49:02 +0000
From:   Tzung-Bi Shih <tzungbi@...nel.org>
To:     bleung@...omium.org, groeck@...omium.org
Cc:     chrome-platform@...ts.linux.dev, tzungbi@...nel.org,
        linux-kernel@...r.kernel.org
Subject: [RESEND PATCH 00/11] platform/chrome: Kunit tests and refactor for cros_ec_cmd_xfer()

The first 5 patches add Kunit tests and refactors for cros_ec_cmd_xfer().

The last 6 patches change the behavior a bit by altering return codes.

Asynchronous mechanism in EC protocol:
EC returns EC_RES_IN_PROGRESS if the host command needs more time to complete.
It saves the result into `saved_result` once the command completed[1].

By design, AP should send another command EC_CMD_RESEND_RESPONSE for getting
the result from the previous pending command[2].  The mechanism was only
designed for commands that don't need responses[3].

However, the kernel code doesn't have such logic when dealing with
EC_RES_IN_PROGRESS.

The series doesn't fix it but leave it as is.  I doubt there is no existing
use case.

[1]: https://crrev.com/9b80051e01872d8cae86fff999b5d31a0bea985b/common/host_command.c#113
[2]: https://crrev.com/9b80051e01872d8cae86fff999b5d31a0bea985b/common/host_command.c#748
[3]: https://crrev.com/9b80051e01872d8cae86fff999b5d31a0bea985b/common/host_command.c#126

Return value overridden in cros_ec_send_command() if asynchronous:
By original intention, cros_ec_send_command() returns number of available
bytes of input payload.

When it falls into asynchronous path (i.e. EC_RES_IN_PROGRESS), both return
value and `msg->result` will be overridden by the subsequent
EC_CMD_GET_COMMS_STATUS.

The series doesn't fix it but leave it as is.

Tzung-Bi Shih (11):
  platform/chrome: cros_ec_proto: add "cros_ec_" prefix to
    send_command()
  platform/chrome: cros_ec_proto: add Kunit tests for cros_ec_cmd_xfer()
  platform/chrome: cros_ec_proto: add Kunit tests for
    cros_ec_send_command()
  platform/chrome: cros_ec_proto: separate cros_ec_xfer_command()
  platform/chrome: cros_ec_proto: separate cros_ec_wait_until_complete()
  platform/chrome: cros_ec_proto: change Kunit expectation when timed
    out
  platform/chrome: cros_ec_proto: return -EAGAIN when retries timed out
  platform/chrome: cros_ec_proto: change Kunit expectation for EC errors
  platform/chrome: cros_ec_proto: return standard error codes for EC
    errors
  platform/chrome: cros_ec_proto: add Kunit test for empty payload
  platform/chrome: cros_ec_proto: return -EPROTO if empty payload

 drivers/platform/chrome/cros_ec_proto.c      | 106 +++--
 drivers/platform/chrome/cros_ec_proto_test.c | 443 +++++++++++++++++++
 drivers/platform/chrome/cros_kunit_util.c    |  20 +
 drivers/platform/chrome/cros_kunit_util.h    |   4 +
 4 files changed, 527 insertions(+), 46 deletions(-)

-- 
2.37.0.rc0.161.g10f37bed90-goog