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.
Thanks,
Chao
在 2023/8/15 12:57, Andrew (EFI) Fish 写道:
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 <lic...@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.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107762): https://edk2.groups.io/g/devel/message/107762
Mute This Topic: https://groups.io/mt/100751724/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
