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.
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.
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.
Choice 2:
Use SMC.
Choice 3:
Write a lot of similar CSR functions.
The Choice 2 and 3 will not depend on any feature
of compiler, but Choice 2 is a security risk and Choice 3
becames the code heavy.
We also support Xcode clang so that means we also support Mach-O executables that get converted to PE/COFF. The is a tool called mtoc (mach-o to coff) in a crufty old open source project that does the conversion.
The reason you are having issues is due to security hardening as the self modifying code is a security risk. It is kind of hard to imagine a case in UEFI that the self modifying code is worth the security risk?. I know Linux does some patching but those are really hot paths that get used a lot, I don’t see that being a pattern that would be common in firmware. The only case I can think you might want SMC is if you were trying to make an UEFI based stress test of some kind?
It might be helpful if you could explain why you can’t use a dispatch table or just define a UEFI Protocol and construct it on the fly to meet your configuration? To me saying you need Self Modifying Code is kind of like saying you need to write it in assembler since the C compiler is not smart enough, and most of the times people think that they are wrong.
Thanks,
Andrew Fish
On Aug 14, 2023, at 8:06 PM, Chao Li <lichao@loongson.cn> wrote:
Hi Liming, Bob and Yuwei
There is a need that some code wants to supports Self-Modification, because some program behavior may not be determined during compilation, and I think this demand may be very popular.
The permise of Self-Modification is that the section has executable and writable permissions. Adding a new section and giving it executable and writable permissions is a better way, and the 'pragma seg_code' is recognized in Microsoft VS compiler but GCC doesn't. If use the GCC as the compiler, the '.section name flags' of GNU GAS are acceptable.
But there is a problem, if converting from elf to efi, the user-defined section with W+X or A+W+X will be droped, Elf64Convert.c will scan the file section permission of elf, if the section is A+X, it will be classified into the .text section, if the section is A+W , then it will be classified into the .data section, if the section is A+W+X or W+X, then it will be droped(Elf64Convert.c, line 272 to 325).
That is:
If using the VS compiler, the user-defined with executable and writable sections may be perserved, but GCC elf to efi conversion may not.
Hope hearback from you and discuss the necessity of SMC(Slef-Modifying-Code) and how to implement it.