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

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

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

Loop Mike.

Hi Mike and Liming,

Please refer to history emails. The Self-Modifying-Code(SMC) method has 
security risks and no one approve it. Ard and Pedro suggest using inline 
ASM in MdePkg.

For this problem, it can only dealt with in the preprocessing stage, 
because the CSR instructions can only recognize immediate values, so 
macro can only be used to expand and obtain the immediate values in the 
preprocessing stage.

So, can I create a .h file and using inline ASM? I think this file might 
be named Csr.h and located in MdePkg/Include/Register/LoongArch64/. I 
have two plans if possible:

*Plan A,
*

All of CSR register numbers are defined in Csr.h and include three CSR 
operations inline ASM, pseudocode:

#if defined(__GNUC__)

#define CsrRead(Sel)

({

XXXX

)}

...

#endif


*Plan B,*

These three macros are defined in another file, which may be named 
CsrOperationGcc.h, and include it in Csr.h, pseudocode:

#if defined(__GNUC__)

#include "CsrPerationGcc.h"

#endif


Hope you can give your suggestions.



Thanks,
Chao
在 2023/8/16 05:26, Andrew Fish via groups.io 写道:
>
>
>> On Aug 15, 2023, at 11:48 AM, Ard Biesheuvel <ardb@kernel.org> wrote:
>>
>> On Tue, 15 Aug 2023 at 18:31, Andrew Fish viagroups.io 
>> <http://groups.io/>
>> <afish=apple.com@groups.io> wrote:
>>>
>>>
>>>
>>>> On Aug 15, 2023, at 8:39 AM, Pedro Falcato 
>>>> <pedro.falcato@gmail.com> wrote:
>>>>
>>>> On Tue, Aug 15, 2023 at 4:05 PM Andrew Fish via groups.io
>>>> <afish=apple.com@groups.io> wrote:
>>>>>
>>>>> Chao,
>>>>>
>>>>> From a quick google it looks like CSR* is used to access banks of 
>>>>> registers that relate to things like performance counters and 
>>>>> debug infrastructure and the number of banks of these register 
>>>>> sets is likely implementation defined. Seems like we could 
>>>>> introduce some Fixed At Build PCD values that define the maximum 
>>>>> number of elements in a given bank.
>>>>>
>>>>> If we are forced to use assembler it might be possible to write 
>>>>> some macros that used the fixed at build values to only generate 
>>>>> functions for banks that are needed for a given build. Then I 
>>>>> think it becomes an exercise in dead code stripping the assembler. 
>>>>> Most compilers generate assembler that contains functions that can 
>>>>> be stripped as long as those functions follow certain rules.
>>>>>
>>>>> As a side note it would be good for us to have an FAQ/Wiki entry 
>>>>> for the dead code stripping rules for the various flavors of 
>>>>> assembler. I know the Apple assembler has a unique take on this.
>>>>
>>>> FWIW, I'm almost positive there's no DCE in GNU as (or llvm-as as
>>>> well). Unless you use something ffunction-sections
>>>> -fdata-sections-like, but then you're relying on the linker +
>>>> gc-sections to take care of it, just like GCC/clang would.
>>>>
>>>
>>> I guess I usually think of DCE as a linker job, since the linker 
>>> knows the functions that are NOT called. At least from the Apple 
>>> tools the DCE has the same rules if you are using Link Time 
>>> Optimization or not. It is basically a flag in the object that tells 
>>> the inker it is OK to follow the DCE rules around labels and remove 
>>> stuff.
>>>
>>> Worst case it seems like we could have macros that generate assembly 
>>> files based on build time constants so we have one function per 
>>> file. This might take a tweak to the build system, but I’d rather do 
>>> that than have library functions that magically turn on Self 
>>> Modifying Code.
>>>
>>> Regardless of the answer I think documenting the rules is a useful 
>>> exercises since needing to save size in firmware images is not an 
>>> uncommon task.
>>>
>>
>> There is already prior art in MdePkg where code targeting both GCC and
>> VS uses inline asm, so I don't see why we would make our lives
>> difficult and deviate from that for LoongArch.
>>
>
> If you look at the BaseLib you can see an example of the INF file[1] 
> using C inline assembler for the GCC family[2] of compilers and NASM 
> for the MSFT [3] tools. Maybe you can plan on using a similar pattern.
>
> [1] 
> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/BaseLib.inf#L321
> [2] 
> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/GccInline.c
> [3] 
> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/CpuPause.nasm
>
> Thanks,
>
> Andrew Fish
>
>>
>
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107822): https://edk2.groups.io/g/devel/message/107822
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: 17089 bytes --]