Hi Mike, Sorry for reply late, I'm a bit busy this week. The Linux kernel defines some inline assembly functions to access CSR registers, as GCC compiled the Linux kernel is very popler now. Chao, Thinks -----原始邮件----- 发件人:"Michael D Kinney" 发送时间:2023-08-19 12:29:12 (星期六) 收件人: 李超 , "devel@edk2.groups.io" , "afish@apple.com" 抄送: "pedro.falcato@gmail.com" , "Gao, Liming" , "Feng, Bob C" , "Chen, Christine" , "Kinney, Michael D" 主题: Re: [edk2-devel] About EDK2 supports Self Modifying Code Have you looked to see what OS code does to access CSR registers? Mike From:李超 Sent: Friday, August 18, 2023 7:18 PM To: devel@edk2.groups.io; afish@apple.com Cc: Kinney, Michael D ; pedro.falcato@gmail.com; Gao, Liming ; Feng, Bob C ; Chen, Christine Subject: Re: Re: [edk2-devel] About EDK2 supports Self Modifying Code Hi Mike and Andrew, The CSR instructions integer value width is 14 bits, use for to access the CSR registers (Control And Status Registers). Just like Andrew saying, the CSR registers include status registers, exception registers, TLB registers, performance conters etc. Now, there are a few numbers CSR ineger value request by FW, but I don't known wether it will be use more numbers in future. There are three choices: Choices 1, As Andrew saying, create some fixed variable and use marco `FixedGetPcd32` to get the right value befor calling the CSR instructions, but our might be create a lot of fixed variable, because it is 14bits width. Choices 2, As Mike saying, defined a limited APIs set, and if needs to more values, just adding them in future. Choices 3, Defined some inline assembly macro and handled it in the preprocessing stage, just like defined the CSR inline assembly macro in MdePkg/Include/Registers/LoongArch64/Csr.h, and include it when request to access the CSR registers. Hope you can give your suggestion again and I will wait for your relpy. -----原始邮件----- 发件人: "Andrew Fish via groups.io" 发送时间: 2023-08-18 04:55:13 (星期五) 收件人:devel@edk2.groups.io, "Mike Kinney" 抄送: "lichao@loongson.cn" , "pedro.falcato@gmail.com" , "Gao, Liming" , "Feng, Bob C" , "Chen, Christine" 主题: Re: [edk2-devel] About EDK2 supports Self Modifying Code On Aug 17, 2023, at 12:53 PM, Michael D Kinney wrote: How many different integer values are needed by FW for use of the csrrd instruction? MIke, I’m no expert on this and I just tried to site read a specification for the 1st time…. 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 resources seemed to be debug registers and performance counters, so things that make a lot of sense to have a variable number defined by the implementation? Thanks, Andrew Fish There are examples of access functions on x86 for things like mm0, mm1, mm2, …, mm7 and cs, ds, es, ss, fs, gs. These are implemented 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 have standard names, then perhaps you could define a set of APIs to access those registers. Mike 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@gmail.com Cc: Andrew (EFI) Fish ; Gao, Liming ; Feng, Bob C ; Chen, Christine 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 chance to get immediate value except using SMC. But then we should ask to the MdePkg maintainer if it is OK. Thanks, Chao 在 2023/8/15 23:35, Pedro Falcato 写道: On Tue, Aug 15, 2023 at 9:20 AM Chao Li 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 tell you real problem, there are some CSR instructions in LoongArch64 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. I know that .c or .h files in MdePkg shouldn't depend on a single compiler 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 transfer the CSR registers selection, and dynamically 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 preprocessing stage or using SMC, otherwise I can only write a lot of similar functions 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: CsrOperationGcc.c, and other future compiler feature-dependent files will be named: CsrOperationClang.c, CsrOperationXlang.c and so on. 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. Choice 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: csrw a0, \csr ret (this is riscv pseudo-asm but I know your arch is similar enough) 本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#108027): https://edk2.groups.io/g/devel/message/108027 Mute This Topic: https://groups.io/mt/100751724/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-