From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id BEFC8D8046F for ; Thu, 17 Aug 2023 20:55:31 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=crd01G9wQjcwdCrTgoL0EIgxk8qj7HF4akKbE463XQk=; c=relaxed/simple; d=groups.io; h=From:Message-id:MIME-version:Subject:Date:In-reply-to:Cc:To:References:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-type; s=20140610; t=1692305730; v=1; b=JO87nlX3Gew7pzH8f4/9fGS+eOUzuJ4krGHvCXWnBcem6ZG6vHZ9FltCAceugpZSErLdJiPf 6k2HmOUhaX+5ILUOPRFXktPyQgpuuSprez8jCuFAf34dysskq98Ch238VEBe35uZro5YcP7idwS hOjg4D6JPYfNdUJRX0m4DBD0= X-Received: by 127.0.0.2 with SMTP id E9TNYY7687511xucViuYk9cK; Thu, 17 Aug 2023 13:55:30 -0700 X-Received: from ma-mailsvcp-mx-lapp02.apple.com (ma-mailsvcp-mx-lapp02.apple.com [17.32.222.23]) by mx.groups.io with SMTP id smtpd.web10.4800.1692305729757243108 for ; Thu, 17 Aug 2023 13:55:29 -0700 X-Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma-mailsvcp-mx-lapp02.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0RZJ010G2ZGFOK20@ma-mailsvcp-mx-lapp02.apple.com> for devel@edk2.groups.io; Thu, 17 Aug 2023 13:55:29 -0700 (PDT) X-Proofpoint-GUID: HSF8RmRFataWbUwbz4iNOQQ4ZyWJQmql X-Proofpoint-ORIG-GUID: HSF8RmRFataWbUwbz4iNOQQ4ZyWJQmql X-Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0RZJ00IKVZGFTG10@rn-mailsvcp-mta-lapp02.rno.apple.com>; Thu, 17 Aug 2023 13:55:27 -0700 (PDT) X-Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) id <0RZJ00900Z82DO00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 17 Aug 2023 13:55:27 -0700 (PDT) X-Va-A: X-Va-T-CD: ea8ecdd7c7fec670404234df68c44261 X-Va-E-CD: a79fd2dfc6232e7fdb69a3f9586137f7 X-Va-R-CD: e4c78c371ebf7c6b093b9a3c3edfe85c X-Va-ID: afc67775-b00f-494a-a309-4e000ab01405 X-Va-CD: 0 X-V-A: X-V-T-CD: ea8ecdd7c7fec670404234df68c44261 X-V-E-CD: a79fd2dfc6232e7fdb69a3f9586137f7 X-V-R-CD: e4c78c371ebf7c6b093b9a3c3edfe85c X-V-ID: 5046ed25-8361-4cca-b79e-ffc0565c3498 X-V-CD: 0 X-Received: from smtpclient.apple (unknown [17.115.2.33]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPSA id <0RZJ00SLZZGBNM00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 17 Aug 2023 13:55:23 -0700 (PDT) From: "Andrew Fish via groups.io" Message-id: MIME-version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: [edk2-devel] About EDK2 supports Self Modifying Code Date: Thu, 17 Aug 2023 13:55:13 -0700 In-reply-to: Cc: "lichao@loongson.cn" , "pedro.falcato@gmail.com" , "Gao, Liming" , "Feng, Bob C" , "Chen, Christine" To: devel@edk2.groups.io, Mike Kinney References: <22642530-3177-d5d9-426a-d5a68ebfe8c6@loongson.cn> <4EB062B0-6C13-480F-A2CC-95C715A08ECD@apple.com> <0f741dad-fd9b-7402-453c-0457875bfba9@loongson.cn> Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,afish@apple.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: h685ppOmGzni0sYvak61gAcHx7686176AA= Content-type: multipart/alternative; boundary="Apple-Mail=_A862D544-6007-443E-A582-9BB26F0B4F44" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=JO87nlX3; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=none --Apple-Mail=_A862D544-6007-443E-A582-9BB26F0B4F44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 17, 2023, at 12:53 PM, Michael D Kinney wrote: >=20 > How many different integer values are needed by FW for use of the csrrd i= nstruction? > =20 MIke, I=E2=80=99m no expert on this and I just tried to site read a specification= for the 1st time=E2=80=A6. It looks to me the like the arch spec does not say something like mm0 - mm7= it seems to imply mm0 - mmN (N is implementation defined). Some of these r= esources seemed to be debug registers and performance counters, so things t= hat make a lot of sense to have a variable number defined by the implementa= tion?=20 Thanks, Andrew Fish > There are examples of access functions on x86 for things like mm0, mm1, m= m2, =E2=80=A6, mm7 and cs, ds, es, ss, fs, gs. These are implemented as di= fferent BaseLib APIs because they would also require SMC to do in a single = API. > =20 > If there is a small number of csrrd index values that need to be accessed= , and they have standard names, then perhaps you could define a set of APIs= to access those registers. > =20 > Mike > =20 > From: devel@edk2.groups.io > On Behalf Of Chao Li > Sent: Wednesday, August 16, 2023 7:30 PM > To: devel@edk2.groups.io ; pedro.falcato@gma= il.com > Cc: Andrew (EFI) Fish >; Gao, Li= ming >; Feng, Bo= b C >; Chen, Christine <= yuwei.chen@intel.com > > Subject: Re: [edk2-devel] About EDK2 supports Self Modifying Code > =20 > Hi Pedro, >=20 > Sorry for the late reply, I was a bit busy yesterday. >=20 > I think the better way is to use inline asm, because this issue must has = to be dealt with in preprocessing stage, because in other stages, it has no= chance to get immediate value except using SMC. But then we should ask to = the MdePkg maintainer if it is OK. >=20 > =20 > Thanks, > Chao > =E5=9C=A8 2023/8/15 23:35, Pedro Falcato =E5=86=99=E9=81=93: > On Tue, Aug 15, 2023 at 9:20=E2=80=AFAM Chao Li wrote: > =20 > Hi Andrew, > =20 > Yes, you are right, I also think that SMC is a bit flawed in terms of sec= urity, but can we use some security mechanism to protect the SMC, like encr= yption and decryption? Sorry, I'm not consider mature enough about SMC secu= rity. > =20 > There isn't any. Actual use cases in something like a kernel are > heavily vetted and read-protected as soon as possible. > =20 > =20 > I can tell you real problem, there are some CSR instructions in LoongArch= 64 that can only accept immediate value, for example: `csrrd $a0, 0x1`, the= 0x1 is the selection of CSR register number, it can't use the registers to= select. This operation should be in the MdePkg base library. > =20 > I know that .c or .h files in MdePkg shouldn't depend on a single compile= r feature, so I can't use the GNU AT&T style inline ASM function(AT&T style= inline supports input parameters being immedite value, use "i" option). In= this case, I think using SMC can handle this, that is use register transfe= r the CSR registers selection, and dynamically modify CSR instructions duri= ng execution phase with reference to transfer register value, this way is d= epend on the .text section or target memory is executable and writable. > =20 > FYI, poking instructions willy-nilly is unsafe and unreliable (except > on x86 due to kludges, but then it's slow). > =20 > =20 > The problem of immediate values can only be handled by preprocessing stag= e or using SMC, otherwise I can only write a lot of similar functions and u= se `switch case` to call them. This method will cause the program size to e= xpand a lot. > =20 > So, I think I have following choice: > =20 > Choice 1: > =20 > Use AT&T style inline function, and create a file named: CsrOperationGcc.= c, and other future compiler feature-dependent files will be named: CsrOper= ationClang.c, CsrOperationXlang.c and so on. > =20 > If you're going to use inline assembly, just expose them directly? I > don't see the problem there, I don't expect loongarch to be picked up > by visual studio any time soon. > =20 > =20 > =20 > Choice 2: > =20 > Use SMC. > =20 > =20 > Choice 3: > =20 > Write a lot of similar CSR functions. > =20 > You /could/ use a GAS macro. > =20 > .macro csr_write csr > .global CsrWrite\csr > CsrWrite\csr: > csrw a0, \csr > ret > =20 > (this is riscv pseudo-asm but I know your arch is similar enough) > =20 >=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#107841): https://edk2.groups.io/g/devel/message/107841 Mute This Topic: https://groups.io/mt/100751724/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --Apple-Mail=_A862D544-6007-443E-A582-9BB26F0B4F44 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 17, 2023, at 12:53 PM, Michael D Kinney <michael.d.kin= ney@intel.com> wrote:

=
How many different integer values are needed by FW fo= r use of the csrrd instruction?
 
=

MIke,

I=E2=80=99m no expert on this and I just tried to site read a specificatio= n for the 1st time=E2=80=A6.
It looks to me the like the arch spe= c does not say something like mm0 - mm7 it seems to imply mm0 - mmN (N is i= mplementation defined). Some of these resources seemed to be debug register= s and performance counters, so things that make a lot of sense to have a va= riable number defined by the implementation? 

Thanks,

Andrew Fish

There are examples of access functions on x86 for things like mm0,= mm1, mm2, =E2=80=A6, mm7 and cs, ds, es, ss, fs, gs.  These are imple= mented as different BaseLib APIs because they would also require SMC to do = in a single API.
 
If there is= a small number of csrrd index values that need to be accessed, and they ha= ve standard names, then perhaps you could define a set of APIs to access th= ose registers.
 
Mike
 
= From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Chao Li
Sent: Wednesday, August 16, 2023 7:30 PM
To: devel@edk2.gr= oups.io; pedro.falcato@gmail.com
Cc: Andrew (EFI) Fish <afish@apple.com>; Gao, Liming <gaoliming@byosoft.com.cn>= ; Feng, Bob C <bob.c.feng@intel.com>; Chen, Chris= tine <yuwei.chen@intel.com>
Subject: Re: [edk2-devel] About EDK2= supports Self Modifying Code
 

Hi Pedro,

Sorry for the late reply, I was a bit= busy yesterday.

I= think the better way is to use inline asm, because this issue must has to = be dealt with in preprocessing stage, because in other stages, it has no ch= ance to get immediate value except using SMC. But then we should ask to the= MdePkg maintainer if it is OK.

 
Thanks,
Chao
=E5=9C=A8 = 2023/8/15 23:35, Pedro Falcato=  =E5=86=99= =E9=81=93:
On Tue, Aug 15, 2023 at 9:20=E2=80=AFAM Chao Li <=
a href=3D"mailto:lichao@loongson.cn" style=3D"color: blue; text-decoration:=
 underline;"><lichao@loongson.cn> wrote:
 
Hi Andrew,
 
Yes, you are right, I also think that SMC is a bit flawed in terms of= security, but can we use some security mechanism to protect the SMC, like = encryption and decryption? Sorry, I'm not consider mature enough about SMC = security.
 
There isn't any. Actual use cases in something like a kernel are
heavily vetted and read-protected as soon as possible.
 
 
I can te=
ll you real problem, there are some CSR instructions in LoongArch64 that ca=
n only accept immediate value, for example: `csrrd $a0, 0x1`, the 0x1 is th=
e selection of CSR register number, it can't use the registers to select. T=
his operation should be in the MdePkg base library.
 
I know that .c or .h files in MdePkg should=
n't depend on a single compiler feature, so I can't use the GNU AT&T st=
yle inline ASM function(AT&T style inline supports input parameters bei=
ng immedite value, use "i" option). In this case, I think using SMC can han=
dle this, that is use register transfer the CSR registers selection, and dy=
namically modify CSR instructions during execution phase with reference to =
transfer register value, this way is depend on the .text section or target =
memory is executable and writable.
 
FYI, poking instructions willy-nilly is unsafe=
 and unreliable (except
on x86 due to kludges, but =
then it's slow).
 
 
The problem of immediate values can only be handled by preproce=
ssing stage or using SMC, otherwise I can only write a lot of similar funct=
ions and use `switch case` to call them. This method will cause the program=
 size to expand a lot.
 
So, I think I have following choice:
 =

Choice 1:
 
Use AT&T style inline function, and create a file named: CsrO=
perationGcc.c, and other future compiler feature-dependent files will be na=
med: CsrOperationClang.c, CsrOperationXlang.c and so on.
 
If you're going to use in=
line assembly, just expose them directly? I
don't s=
ee the problem there, I don't expect loongarch to be picked up
by visual studio any time soon.
&n=
bsp;
=

 
 
Choic=
e 2:
 
Use SMC.
 
 
Choice 3:
 
Write=
 a lot of similar CSR functions.
=
 
You /could/ use a GAS macro.
 
.macro csr_write csr
.global CsrWrite\csr
CsrWrite\csr:<=
/pre>
    csrw a0, \csr
 =
;   ret
 
(t=
his is riscv pseudo-asm but I know your arch is similar enough)<=
/pre>
 





_._,_._,_





Groups.io Links:



 =20
    You receive all messages sent to this group.
 =20
 =20




View/Reply Online (#107841) |


 =20

|

  Mute=
 This Topic


| New Topic







Your Subscriptio=
n |
Contact Group Owner |

Unsubscribe

 [rebecca@openfw.io]


_._,_._,_



--Apple-Mail=_A862D544-6007-443E-A582-9BB26F0B4F44--