linux-kernel - Re: [PATCH v2 4/7] platform/x86/intel/ifs: Implement Array BIST test

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:   Wed, 22 Feb 2023 14:07:35 -0800
From:   "Joseph, Jithu" <jithu.joseph@...el.com>
To:     Dave Hansen <dave.hansen@...el.com>, <hdegoede@...hat.com>,
        <markgross@...nel.org>
CC:     <tglx@...utronix.de>, <mingo@...hat.com>, <bp@...en8.de>,
        <dave.hansen@...ux.intel.com>, <x86@...nel.org>, <hpa@...or.com>,
        <gregkh@...uxfoundation.org>, <rostedt@...dmis.org>,
        <ashok.raj@...el.com>, <tony.luck@...el.com>,
        <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <patches@...ts.linux.dev>,
        <ravi.v.shankar@...el.com>, <thiago.macieira@...el.com>,
        <athenas.jimenez.gonzalez@...el.com>, <sohil.mehta@...el.com>
Subject: Re: [PATCH v2 4/7] platform/x86/intel/ifs: Implement Array BIST test



On 2/22/2023 12:12 PM, Dave Hansen wrote:
> 
> I actually really think this tracing should go away, *ESPECIALLY* if you
> insist on dumping out raw, non-human-readable MSR values.
> 
> I say NAK on the tracing.  You haven't convinced me that it's necessary
> on top of what we have today (MSR tracing).


Thanks for the pointer on MSR trace. I agree that setting the appropriate filter ("msr == 0x105") would generate the read and write values (snip2 below).

The primary value addition for the custom trace added by this driver was readability / convenience (snip1 below).  The format it is dumping today is most convenient for tracking  the progress of this test  from start to completion. (Two formatted input fields (wrmsr) and one output field (rdmsr) on the same line ).
Another convenience is that, by enabling the high-level intel_ifs trace,  we can see all  activity related to all IFS tests (and not having to explicitly remember and enable the MSRs corresponding to each of the IFS tests)

Since the trace has to be explicitly enabled (I thought it is okay to add a more convenient custom one only to be enabled for detailed analysis when required).

<Snip 1 added by driver>
     bash-9411    [123] ..... 423555.355664: ifs_array: cpu: 10, array_list: ffffffff, array_bank: 0000, status: 0000010000007ff2
     bash-9411    [123] ..... 423555.355858: ifs_array: cpu: 10, array_list: 00007ff2, array_bank: 0100, status: 0000000000007fe0
     bash-9411    [123] ..... 423555.355891: ifs_array: cpu: 10, array_list: 00007fe0, array_bank: 0000, status: 0000010000007fe0
     bash-9411    [123] ..... 423555.355923: ifs_array: cpu: 10, array_list: 00007fe0, array_bank: 0100, status: 0000000100007fe0
</snip1>


<snip2 using msr trace>
   migration/10-76      [010] d..1. 423672.955522: write_msr: 105, value ffffffff
   migration/10-76      [010] d..1. 423672.955525: read_msr: 105, value 10000007ff2
   migration/10-76      [010] d..1. 423672.955733: write_msr: 105, value 10000007ff2
   migration/10-76      [010] d..1. 423672.955736: read_msr: 105, value 7fe0
   migration/10-76      [010] d..1. 423672.955783: write_msr: 105, value 7fe0
   migration/10-76      [010] d..1. 423672.955786: read_msr: 105, value 10000007fe0
   migration/10-76      [010] d..1. 423672.955819: write_msr: 105, value 10000007fe0
   migration/10-76      [010] d..1. 423672.955822: read_msr: 105, value 100007fe0
</snip2 msr trace>


Jithu