[edk2-devel] About EDK2 supports Self Modifying Code

[edk2-devel] About EDK2 supports Self Modifying Code

[Chao Li]

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

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.



Thanks,
Chao


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

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

[Andrew Fish via groups.io]

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

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.
> 
> 
> 
> 
> Thanks,
> Chao
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107760): https://edk2.groups.io/g/devel/message/107760
Mute This Topic: https://groups.io/mt/100751724/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



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

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

[Chao Li]

[-- 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 --]

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

[Ard Biesheuvel]

On Tue, 15 Aug 2023 at 10:20, Chao Li <lichao@loongson.cn> 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.
>
> 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.
>

That is *not* a good reason for using self modifying code. If the CSR
register number is known at build time, it should be emitted into the
binary at build time in one way or another.

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

If the only currently supported compiler (GCC?) has a syntax that
permits emitting this as inline asm, it is perfectly fine to use this
in your implementation. Once other compiler support is introduced, we
can think about how to address the difference, but I suspect that
Clang will just work with the GCC notation.


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

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

[Chao Li]

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

Hi Ard,

Ok, I see, thanks for you suggestion.


Thanks,
Chao
在 2023/8/15 16:28, Ard Biesheuvel 写道:
> On Tue, 15 Aug 2023 at 10:20, Chao Li<lichao@loongson.cn>  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.
>>
>> 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.
>>
> That is *not* a good reason for using self modifying code. If the CSR
> register number is known at build time, it should be emitted into the
> binary at build time in one way or another.
>
>> 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.
>>
> If the only currently supported compiler (GCC?) has a syntax that
> permits emitting this as inline asm, it is perfectly fine to use this
> in your implementation. Once other compiler support is introduced, we
> can think about how to address the difference, but I suspect that
> Clang will just work with the GCC notation.
>
>
> 
>


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

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

[Andrew Fish via groups.io]

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

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.  

Thanks,

Andrew Fish

> On Aug 15, 2023, at 1:54 AM, Chao Li <lichao@loongson.cn> wrote:
> 
> Hi Ard, 
> 
> Ok, I see, thanks for you suggestion.
> 
> 
> Thanks,
> Chao
> 在 2023/8/15 16:28, Ard Biesheuvel 写道:
>> On Tue, 15 Aug 2023 at 10:20, Chao Li <lichao@loongson.cn> <mailto:lichao@loongson.cn> 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.
>>> 
>>> 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.
>>> 
>> That is *not* a good reason for using self modifying code. If the CSR
>> register number is known at build time, it should be emitted into the
>> binary at build time in one way or another.
>> 
>>> 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.
>>> 
>> If the only currently supported compiler (GCC?) has a syntax that
>> permits emitting this as inline asm, it is perfectly fine to use this
>> in your implementation. Once other compiler support is introduced, we
>> can think about how to address the difference, but I suspect that
>> Clang will just work with the GCC notation.
>> 
>> 
>> 
>> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107766): https://edk2.groups.io/g/devel/message/107766
Mute This Topic: https://groups.io/mt/100751724/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



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

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

[Pedro Falcato]

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.

-- 
Pedro


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

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

[Andrew Fish via groups.io]

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

Thanks,

Andrew Fish

> -- 
> Pedro
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107770): https://edk2.groups.io/g/devel/message/107770
Mute This Topic: https://groups.io/mt/100751724/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Ard Biesheuvel]

On Tue, 15 Aug 2023 at 18:31, Andrew Fish via 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.


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

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

[Andrew Fish via groups.io]

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



> On Aug 15, 2023, at 11:48 AM, Ard Biesheuvel <ardb@kernel.org> wrote:
> 
> On Tue, 15 Aug 2023 at 18:31, Andrew Fish via groups.io <http://groups.io/>
> <afish=apple.com@groups.io <mailto: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 (#107772): https://edk2.groups.io/g/devel/message/107772
Mute This Topic: https://groups.io/mt/100751724/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



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

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

[Chao Li]

[-- 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 --]

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

[Pedro Falcato]

On Tue, Aug 15, 2023 at 9:20 AM Chao Li <lichao@loongson.cn> 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)

-- 
Pedro


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

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

[Chao Li]

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

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<lichao@loongson.cn>  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)
>


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

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

[Michael D Kinney]

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

How many different integer values are needed by FW for use of the csrrd instruction?

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 <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 <afish@apple.com>; Gao, Liming <gaoliming@byosoft.com.cn>; Feng, Bob C <bob.c.feng@intel.com>; Chen, Christine <yuwei.chen@intel.com>
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 <lichao@loongson.cn><mailto:lichao@loongson.cn> 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)





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107837): https://edk2.groups.io/g/devel/message/107837
Mute This Topic: https://groups.io/mt/100751724/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



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

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

[Andrew Fish via groups.io]

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



> On Aug 17, 2023, at 12:53 PM, Michael D Kinney <michael.d.kinney@intel.com> 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 <mailto:devel@edk2.groups.io> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>> On Behalf Of Chao Li
> Sent: Wednesday, August 16, 2023 7:30 PM
> To: devel@edk2.groups.io <mailto:devel@edk2.groups.io>; pedro.falcato@gmail.com <mailto:pedro.falcato@gmail.com>
> Cc: Andrew (EFI) Fish <afish@apple.com <mailto:afish@apple.com>>; Gao, Liming <gaoliming@byosoft.com.cn <mailto:gaoliming@byosoft.com.cn>>; Feng, Bob C <bob.c.feng@intel.com <mailto:bob.c.feng@intel.com>>; Chen, Christine <yuwei.chen@intel.com <mailto:yuwei.chen@intel.com>>
> 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 <lichao@loongson.cn> <mailto:lichao@loongson.cn> 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)
>  
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107841): https://edk2.groups.io/g/devel/message/107841
Mute This Topic: https://groups.io/mt/100751724/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



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

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

[Chao Li]

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

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" <afish=apple.com@groups.io>
发送时间:2023-08-18 04:55:13 (星期五)
收件人: devel@edk2.groups.io, "Mike Kinney" <michael.d.kinney@intel.com>
抄送: "lichao@loongson.cn" <lichao@loongson.cn>, "pedro.falcato@gmail.com" <pedro.falcato@gmail.com>, "Gao, Liming" <gaoliming@byosoft.com.cn>, "Feng, Bob C" <bob.c.feng@intel.com>, "Chen, Christine" <yuwei.chen@intel.com>
主题: Re: [edk2-devel] About EDK2 supports Self Modifying Code






On Aug 17, 2023, at 12:53 PM, Michael D Kinney <michael.d.kinney@intel.com> 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 <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 <afish@apple.com>; Gao, Liming <gaoliming@byosoft.com.cn>; Feng, Bob C <bob.c.feng@intel.com>; Chen, Christine <yuwei.chen@intel.com>
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 <lichao@loongson.cn> 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)
 








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

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

[Michael D Kinney]

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

Have you looked to see what OS code does to access CSR registers?

Mike

From: 李超 <lichao@loongson.cn>
Sent: Friday, August 18, 2023 7:18 PM
To: devel@edk2.groups.io; afish@apple.com
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; pedro.falcato@gmail.com; Gao, Liming <gaoliming@byosoft.com.cn>; Feng, Bob C <bob.c.feng@intel.com>; Chen, Christine <yuwei.chen@intel.com>
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" <afish=apple.com@groups.io<mailto:afish=apple.com@groups.io>>
发送时间: 2023-08-18 04:55:13 (星期五)
收件人: devel@edk2.groups.io<mailto:devel@edk2.groups.io>, "Mike Kinney" <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
抄送: "lichao@loongson.cn<mailto:lichao@loongson.cn>" <lichao@loongson.cn<mailto:lichao@loongson.cn>>, "pedro.falcato@gmail.com<mailto:pedro.falcato@gmail.com>" <pedro.falcato@gmail.com<mailto:pedro.falcato@gmail.com>>, "Gao, Liming" <gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>>, "Feng, Bob C" <bob.c.feng@intel.com<mailto:bob.c.feng@intel.com>>, "Chen, Christine" <yuwei.chen@intel.com<mailto:yuwei.chen@intel.com>>
主题: Re: [edk2-devel] About EDK2 supports Self Modifying Code



On Aug 17, 2023, at 12:53 PM, Michael D Kinney <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>> 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<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Chao Li
Sent: Wednesday, August 16, 2023 7:30 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; pedro.falcato@gmail.com<mailto:pedro.falcato@gmail.com>
Cc: Andrew (EFI) Fish <afish@apple.com<mailto:afish@apple.com>>; Gao, Liming <gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>>; Feng, Bob C <bob.c.feng@intel.com<mailto:bob.c.feng@intel.com>>; Chen, Christine <yuwei.chen@intel.com<mailto:yuwei.chen@intel.com>>
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 <lichao@loongson.cn><mailto:lichao@loongson.cn> 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 (#107884): https://edk2.groups.io/g/devel/message/107884
Mute This Topic: https://groups.io/mt/100751724/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



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

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

[Chao Li]

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

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" <michael.d.kinney@intel.com>
发送时间:2023-08-19 12:29:12 (星期六)
收件人: 李超 <lichao@loongson.cn>, "devel@edk2.groups.io" <devel@edk2.groups.io>, "afish@apple.com" <afish@apple.com>
抄送: "pedro.falcato@gmail.com" <pedro.falcato@gmail.com>, "Gao, Liming" <gaoliming@byosoft.com.cn>, "Feng, Bob C" <bob.c.feng@intel.com>, "Chen, Christine" <yuwei.chen@intel.com>, "Kinney, Michael D" <michael.d.kinney@intel.com>
主题: Re: [edk2-devel] About EDK2 supports Self Modifying Code



Have you looked to see what OS code does to access CSR registers?

 

Mike

 

From:李超 <lichao@loongson.cn>
Sent: Friday, August 18, 2023 7:18 PM
To: devel@edk2.groups.io; afish@apple.com
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; pedro.falcato@gmail.com; Gao, Liming <gaoliming@byosoft.com.cn>; Feng, Bob C <bob.c.feng@intel.com>; Chen, Christine <yuwei.chen@intel.com>
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" <afish=apple.com@groups.io>
发送时间: 2023-08-18 04:55:13 (星期五)
收件人:devel@edk2.groups.io, "Mike Kinney" <michael.d.kinney@intel.com>
抄送: "lichao@loongson.cn" <lichao@loongson.cn>, "pedro.falcato@gmail.com" <pedro.falcato@gmail.com>, "Gao, Liming" <gaoliming@byosoft.com.cn>, "Feng, Bob C" <bob.c.feng@intel.com>, "Chen, Christine" <yuwei.chen@intel.com>
主题: Re: [edk2-devel] About EDK2 supports Self Modifying Code

 





On Aug 17, 2023, at 12:53 PM, Michael D Kinney <michael.d.kinney@intel.com> 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 <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 <afish@apple.com>; Gao, Liming <gaoliming@byosoft.com.cn>; Feng, Bob C <bob.c.feng@intel.com>; Chen, Christine <yuwei.chen@intel.com>
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 <lichao@loongson.cn> 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]
-=-=-=-=-=-=-=-=-=-=-=-



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