linux-kernel - Re: [PATCH v5 05/19] arm64: Add support for trace synchronization barrier

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: <17e57b01-840b-dbeb-c09f-1c04becb8749@arm.com>
Date:   Wed, 24 Mar 2021 16:25:12 +0000
From:   Suzuki K Poulose <suzuki.poulose@....com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        coresight@...ts.linaro.org, mike.leach@...aro.org,
        leo.yan@...aro.org, anshuman.khandual@....com,
        Will Deacon <will.deacon@....com>
Subject: Re: [PATCH v5 05/19] arm64: Add support for trace synchronization
 barrier

On 24/03/2021 16:16, Marc Zyngier wrote:
> On Wed, 24 Mar 2021 15:51:14 +0000,
> Suzuki K Poulose <suzuki.poulose@....com> wrote:
>>
>> On 24/03/2021 13:49, Marc Zyngier wrote:
>>> On Wed, 24 Mar 2021 09:39:13 +0000,
>>> Suzuki K Poulose <suzuki.poulose@....com> wrote:
>>>>
>>>> On 23/03/2021 18:21, Catalin Marinas wrote:
>>>>> Hi Suzuki?
>>>>>
>>>>> On Tue, Mar 23, 2021 at 12:06:33PM +0000, Suzuki K Poulose wrote:
>>>>>> tsb csync synchronizes the trace operation of instructions.
>>>>>> The instruction is a nop when FEAT_TRF is not implemented.
>>>>>>
>>>>>> Cc: Mathieu Poirier <mathieu.poirier@...aro.org>
>>>>>> Cc: Mike Leach <mike.leach@...aro.org>
>>>>>> Cc: Catalin Marinas <catalin.marinas@....com>
>>>>>> Cc: Will Deacon <will.deacon@....com>
>>>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
>>>>>
>>>>> How do you plan to merge these patches? If they go via the coresight
>>>>> tree:
>>>>>
>>>>
>>>> Ideally all of this should go via the CoreSight tree to have the
>>>> dependencies solved at one place. But there are some issues :
>>>>
>>>> If this makes to 5.13 queue for CoreSight,
>>>>
>>>> 1) CoreSight next is based on rc2 at the moment and we have fixes gone
>>>> into rc3 and later, which this series will depend on. (We could move
>>>> the next tree forward to a later rc to solve this).
>>>>
>>>> 2) There could be conflicts with the kvmarm tree for the KVM host
>>>> changes (That has dependency on the TRBE definitions patch).
>>>>
>>>> If it doesn't make to 5.13 queue, it would be good to have this patch,
>>>> the TRBE defintions and the KVM host patches queued for 5.13 (not sure
>>>> if this is acceptable) and we could rebase the CoreSight changes on 5.13
>>>> and push it to next release.
>>>>
>>>> I am open for other suggestions.
>>>>
>>>> Marc, Mathieu,
>>>>
>>>> Thoughts ?
>>>
>>> I was planning to take the first two patches in 5.12 as fixes (they
>>> are queued already, and would hopefully land in -rc5). If that doesn't
>>> fit with the plan, please let me know ASAP.
>>
>> Marc,
>>
>> I think it would be better to hold on pushing those patches until we
>> have a clarity on how things will go.
> 
> OK. I thought there was a need for these patches to prevent guest
> access to the v8.4 self hosted tracing feature that went in 5.12
> though[1]... Did I get it wrong?

Yes, that is correct. The guest could access the Trace Filter Control 
register and fiddle with the host settings, without this patch.
e.g, it could disable tracing at EL0/EL1, without the host being
aware on nVHE host.

Cheers
Suzuki