linux-kernel - Re: [PATCH v4 25/25] coresight: Add support for v8.4 SelfHosted tracing

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:   Fri, 20 Nov 2020 10:03:00 +0000
From:   Suzuki K Poulose <suzuki.poulose@....com>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, mathieu.poirier@...aro.org,
        mike.leach@...aro.org, linux-kernel@...r.kernel.org,
        anshuman.khandual@....com, jonathan.zhouwen@...wei.com,
        coresight@...ts.linaro.org, Will Deacon <will@...nel.org>
Subject: Re: [PATCH v4 25/25] coresight: Add support for v8.4 SelfHosted
 tracing

On 11/19/20 5:22 PM, Catalin Marinas wrote:
> On Thu, Nov 19, 2020 at 04:45:47PM +0000, Suzuki K Poulose wrote:
>> From: Jonathan Zhou <jonathan.zhouwen@...wei.com>
>>
>> v8.4 tracing extensions added support for trace filtering controlled
>> by TRFCR_ELx. This must be programmed to allow tracing at EL1/EL2 and
>> EL0. The timestamp used is the virtual time. Also enable CONTEXIDR_EL2
>> tracing if we are running the kernel at EL2.
>>
>> Cc: Catalin Marinas <catalin.marinas@....com>
>> Cc: Mathieu Poirier <mathieu.poirier@...aro.org>
>> Cc: Mike Leach <mike.leach@...aro.org>
>> Cc: Will Deacon <will@...nel.org>
>> Signed-off-by: Jonathan Zhou <jonathan.zhouwen@...wei.com>
>> [ Move the trace filtering setup etm_init_arch_data() and
>>   clean ups]
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
>> ---
>>   .../coresight/coresight-etm4x-core.c          | 25 +++++++++++++++++++
>>   1 file changed, 25 insertions(+)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> index 1d054d2ab2a0..647685736134 100644
>> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> @@ -760,6 +760,30 @@ static bool etm4_init_csdev_access(struct etmv4_drvdata *drvdata,
>>   	return false;
>>   }
>>   
>> +static void cpu_enable_tracing(void)
>> +{
>> +	u64 dfr0 = read_sysreg(id_aa64dfr0_el1);
>> +	u64 trfcr;
>> +
>> +	if (!(dfr0 >> ID_AA64DFR0_TRACE_FILT_SHIFT))
>> +		return;
> 
> What if we get a new field at position 44 while the FILT one at 40 is 0?
> We should use cpuid_feature_extract_field() here.
> 

Bah, you're right. Sorry for that silly mistake. Thanks for spotting.

> BTW, can this function not go in the cpufeature.c code?

Yes, this could go there. The only reason for keeping this here
was that the ETM is the only Trace component we support.

Ideally, this should be performed at enable/disable of the ETM,
based on the "config" selected for the session. That way we can
be sure that nobody (read, a VM) traces the host kernel/el0 behind our back
(even though we would trap the access for now).

Suzuki