linux-kernel - Re: [PATCH v3 1/8] arm64/sysreg: Add definitions for immediate versions of MSR ALLINT

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: <cde4d448-dc9d-eaad-4a2d-a6d34bda4449@huawei.com>
Date: Tue, 7 May 2024 15:41:08 +0800
From: "Liao, Chang" <liaochang1@...wei.com>
To: Mark Brown <broonie@...nel.org>, Mark Rutland <mark.rutland@....com>
CC: <catalin.marinas@....com>, <will@...nel.org>, <maz@...nel.org>,
	<oliver.upton@...ux.dev>, <james.morse@....com>, <suzuki.poulose@....com>,
	<yuzenghui@...wei.com>, <tglx@...utronix.de>, <ardb@...nel.org>,
	<anshuman.khandual@....com>, <miguel.luis@...cle.com>, <joey.gouly@....com>,
	<ryan.roberts@....com>, <jeremy.linton@....com>, <ericchancf@...gle.com>,
	<kristina.martsenko@....com>, <robh@...nel.org>,
	<scott@...amperecomputing.com>, <songshuaishuai@...ylab.org>,
	<shijie@...amperecomputing.com>, <akpm@...ux-foundation.org>,
	<bhe@...hat.com>, <horms@...nel.org>, <mhiramat@...nel.org>,
	<rmk+kernel@...linux.org.uk>, <shahuang@...hat.com>,
	<takakura@...inux.co.jp>, <dianders@...omium.org>, <swboyd@...omium.org>,
	<sumit.garg@...aro.org>, <frederic@...nel.org>, <reijiw@...gle.com>,
	<akihiko.odaki@...nix.com>, <ruanjinjie@...wei.com>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
	<kvmarm@...ts.linux.dev>
Subject: Re: [PATCH v3 1/8] arm64/sysreg: Add definitions for immediate
 versions of MSR ALLINT

Hi, Mark.

在 2024/5/6 23:15, Mark Brown 写道:
> On Fri, May 03, 2024 at 05:00:49PM +0100, Mark Rutland wrote:
>> On Mon, Apr 15, 2024 at 06:47:51AM +0000, Liao Chang wrote:
> 
>> +#define PSTATE_ALLINT                  pstate_field(1, 0)
> 
>> +#define set_pstate_allint(x)           asm volatile(SET_PSTATE_ALLINT(x))
> 
> Hrm, those helpers are not ideally discoverable, partly due to the
> system register description for ALLINT not providing any references to
> this being a general scheme (which is fixable there) and partly due to

Based on the Arm ISA reference manual, the instruction accessing the ALLINT
field of PSTATE uses the following encoding:
                    op0  op1   CRn    CRm    op2
MSR ALLINT, #<imm>  0b00 0b001 0b0100 0b000x 0b000

In this encoding, the 'x' represents the LSB of #<imm>, op1 is fixed as 0b001
and op2 is fixed as 0b000. With this understanding, those helpers seem like a
good approach for accessing the PSTATE.ALLINT field. I've aslo confirmed that
the binary encoding generated by those helpers is same with the encoding of v3.

> the use of __emit_inst() with a numeric literal - we should probably add
> a comment next to the __emit_inst() saying what instruction we are
> emitting
Arm Architecture Reference Manual for A-profile outlines two variants for
MSR instructions used to modify PSTATE fields direclty using immediate. The
major difference between these variants lies in the CRm field encoding:

- 4 bit immediate, examples include "MSR DAIFSET,#Imm4" and "MSR DAIFCLR,#Imm4".
  The CRm field in this variant uses the least 4 bits of immediate.
- 1 bit immediate, currently, only "MSR ALLINT,#Imm1" uses this variant.
  The CRm field uses only the least 1 bit of immediate.

The current implementation of the macro SET_PSTATE() defaults to the 1 bit
immediate variant (!!x << PSTATE_Imm_shift). Currently, this macro is used
to generate instructions accessing PAN, UAO, SSBS, TCO and DIT which require
1 bit immediate variant, hence I would say it also work for ALLINT as well.

Thanks.

-- 
BR
Liao, Chang