Re: [edk2-devel] About EDK2 supports Self Modifying Code

["Chao Li" <lichao@loongson.cn>]

[-- Attachment #1: Type: text/plain, Size: 4717 bytes --]

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 <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.
>>
>>
>> 
>


-=-=-=-=-=-=-=-=-=-=-=-
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/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 8277 bytes --]