linux-kernel - Re: [RFC PATCH 15/16] selftests: arm64: Add initial SCMI testcases

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

Message-ID: <Yud4re9NC1Tjsoco@e120937-lin>
Date:   Mon, 1 Aug 2022 07:54:58 +0100
From:   Cristian Marussi <cristian.marussi@....com>
To:     Arun KS <arunks.linux@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        sudeep.holla@....com, james.quinlan@...adcom.com,
        Jonathan.Cameron@...wei.com, f.fainelli@...il.com,
        vincent.guittot@...aro.org, souvik.chakravarty@....com,
        peter.hilber@...nsynergy.com, Arun KS <getarunks@...il.com>
Subject: Re: [RFC PATCH 15/16] selftests: arm64: Add initial SCMI testcases

On Mon, Aug 01, 2022 at 10:22:19AM +0530, Arun KS wrote:
> Hi Cristian,
> 

Hi Arun,

[snip]
> > +setup_scmi_test_env()
> > +{
> > +       local scmi_info_dir="${SCMI_DEBUGFS_TOPDIR}/info/"
> > +
> > +       export SCMI_VENDOR="$(cat ${scmi_info_dir}/vendor_id)"
> > +       export SCMI_SUB_VENDOR="$(cat ${scmi_info_dir}/sub_vendor_id)"
> > +       export SCMI_VERS_MAJ="$(cat ${scmi_info_dir}/major_ver)"
> > +       export SCMI_VERS_MIN="$(cat ${scmi_info_dir}/minor_ver)"
> > +       export SCMI_VERS_IMPL="$(cat ${scmi_info_dir}/impl_ver)"
> > +
> > +       ksft_log "Found stack: $SCMI_VENDOR/$SCMI_SUB_VENDOR ${SCMI_VERS_MAJ}.${SCMI_VERS_MAJ} - $SCMI_VERS_IMPL"
> > +
> > +       SCMI_TEST_PROTOS=""
> > +       for p in ${SCMI_DEBUGFS_TOPDIR}/protocol_*; do
> > +               SCMI_TEST_PROTOS="${SCMI_TEST_PROTOS} $(basename $p)"
> > +       done
> > +
> > +       ksft_log "Found testing protocols: $SCMI_TEST_PROTOS"
> > +
> > +       export SCMI_TEST_PROTOS
> > +       SCMI_TRANSPORT_IS_ATOMIC="N"
> > +       [ -d "${SCMI_DEBUGFS_TOPDIR}/transport" ] &&
> > +               SCMI_TRANSPORT_IS_ATOMIC=$(cat "${SCMI_DEBUGFS_TOPDIR}/transport/is_atomic")
> > +       export SCMI_TRANSPORT_IS_ATOMIC
> > +}
> > +
> > +# Setup
> > +check_root_privs
> > +
> > +check_scmi_testing_stack
> > +
> > +setup_scmi_test_env
> > +
> > +# Main
> > +# Run all available tests for the found protocols
> > +#
> > +for proto_dir in $SCMI_TEST_PROTOS; do
> > +       [ ! -d $proto_dir ] && ksft_log "$proto_dir tests NOT supported." && continue
> > +       export TST_PROTO_DIR="${SCMI_DEBUGFS_TOPDIR}/${proto_dir}"
> > +       TST_PROTO_VERSION=$(cat ${TST_PROTO_DIR}/version)
> > +       ksft_log "Running tests for SCMI $proto_dir ver:$TST_PROTO_VERSION"
> > +       for tst in $proto_dir/*; do
> > +               ksft_scmi_run_one $tst
> > +       done
> > +done
> > +
> > +ksft_results
> > diff --git a/tools/testing/selftests/arm64/scmi/testcases/protocol_0x14/clock_enable.sh b/tools/testing/selftests/arm64/scmi/testcases/protocol_0x14/clock_enable.sh
> > new file mode 100755
> > index 000000000000..4cdf3a097ba7
> > --- /dev/null
> > +++ b/tools/testing/selftests/arm64/scmi/testcases/protocol_0x14/clock_enable.sh
> > @@ -0,0 +1,33 @@
> > +#!/bin/bash
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +. ./kselftest_scmi_lib.sh
> > +
> > +supported_fw="EMU-SCMI-VM:userland"
> > +ksft_scmi_check_fw_version $supported_fw
> 
> what is the necessity of this check? Won't it limits the use of this
> common test script across multiple platforms?
> 

Yes, indeed the basic idea here was to showcase in this RFC series that
the testcases could be written so as to be run only on a restricted set
of platforms: the crux of the matter is that some of the SCMI tests by
their own nature can be very invasive and disruptive, but for the sake
of testing the Kernel stack some of those are worth to be run and, with
this 'version-bsed' approach, you could run it safely as long as you
deploy them against some sort of special emulated SCMI-server which is
is instead safe to be tested in any way (since no real clocks are in
fact involved...)

For this same reason, this kind of test tailored at a very special SCMI
server wouldn't be probably upstreamed unless you fw-emulation backend
is upstream in the open too, so I posted this test more to showcase the
version based mechanism than the test itself...

Thanks,
Cristian