linux-kernel - Re: [PATCH v2 5/7] kvm/riscv: rework guest entry logic

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: <f39d3e7e-8eee-a371-b2b6-175d4b023720@redhat.com>
Date:   Thu, 20 Jan 2022 14:13:06 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Mark Rutland <mark.rutland@....com>, palmer@...belt.com
Cc:     linux-kernel@...r.kernel.org, aleksandar.qemu.devel@...il.com,
        alexandru.elisei@....com, anup.patel@....com,
        aou@...s.berkeley.edu, atish.patra@....com,
        borntraeger@...ux.ibm.com, bp@...en8.de, catalin.marinas@....com,
        chenhuacai@...nel.org, dave.hansen@...ux.intel.com,
        frankja@...ux.ibm.com, frederic@...nel.org, gor@...ux.ibm.com,
        hca@...ux.ibm.com, james.morse@....com, jmattson@...gle.com,
        joro@...tes.org, luto@...nel.org, maz@...nel.org, mingo@...hat.com,
        mpe@...erman.id.au, nsaenzju@...hat.com, paulmck@...nel.org,
        paul.walmsley@...ive.com, peterz@...radead.org, seanjc@...gle.com,
        suzuki.poulose@....com, svens@...ux.ibm.com, tglx@...utronix.de,
        tsbogend@...ha.franken.de, vkuznets@...hat.com,
        wanpengli@...cent.com, will@...nel.org
Subject: Re: [PATCH v2 5/7] kvm/riscv: rework guest entry logic

On 1/20/22 13:56, Mark Rutland wrote:
>> This should be the required architectural behavior: "a CSR access is
>> performed after the execution of any prior instructions in program order
>> whose behavior modifies or is modified by the CSR state and before the
>> execution of any subsequent instructions in program order whose behavior
>> modifies or is modified by the CSR state" (Zicsr spec, paragraph "CSR Access
>> Ordering", available at
>> https://www.five-embeddev.com/riscv-isa-manual/latest/csr.html#csrinsts).
>
> I think that's necessary, but not sufficient.
> 
> IIUC that wording means that writes to the CSR state occur in program order
> without requiring additional barriers to take effect. The current value of the
> CSR determines whether interrupts *can* be taken, but that doesn't say that
> pending interrrupts *must*  be taken immediately when unmasked in the CSR.

I see.  Yeah, my reasoning was that there would be _different_ 
instructions executed after the CSR write if an interrupt has to be 
taken, but perhaps that's a bit of a stretch.

Paolo