From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 8CABA740032 for ; Tue, 15 Aug 2023 08:20:28 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=L2QKmbqdmm6rAVrhAGUxa7EGLBQBCAHNhKYsTuIThfo=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:User-Agent:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1692087626; v=1; b=Oi1r+2j9DVGfRs4yJjfg8IYrDeNqNJbYyiOHeNUUi9PthdGBq9J3UIjlTs6Lp3PvaEzHjPjZ Tp2lRC1mOsGGCYc3pkpIM9n4OKUtVDtDv/Jpw6PUxY2XdiEkaUxEeRgAiy7DoJR5nl8TkIPZBGT 2J/xam93/lCCReFFI57Uy/00= X-Received: by 127.0.0.2 with SMTP id cS5rYY7687511xCxB0l56aJR; Tue, 15 Aug 2023 01:20:26 -0700 X-Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by mx.groups.io with SMTP id smtpd.web10.129869.1692087625200763353 for ; Tue, 15 Aug 2023 01:20:25 -0700 X-Received: from loongson.cn (unknown [10.40.24.149]) by gateway (Coremail) with SMTP id _____8CxNvFDNdtk3K8YAA--.50822S3; Tue, 15 Aug 2023 16:20:19 +0800 (CST) X-Received: from [10.40.24.149] (unknown [10.40.24.149]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Dx4eRBNdtkjQNbAA--.27171S3; Tue, 15 Aug 2023 16:20:17 +0800 (CST) Message-ID: Date: Tue, 15 Aug 2023 16:20:17 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [edk2-devel] About EDK2 supports Self Modifying Code To: "Andrew (EFI) Fish" , edk2-devel-groups-io Cc: Liming Gao , Bob Feng , Yuwei Chen References: <22642530-3177-d5d9-426a-d5a68ebfe8c6@loongson.cn> <4EB062B0-6C13-480F-A2CC-95C715A08ECD@apple.com> From: "Chao Li" In-Reply-To: <4EB062B0-6C13-480F-A2CC-95C715A08ECD@apple.com> X-CM-TRANSID: AQAAf8Dx4eRBNdtkjQNbAA--.27171S3 X-CM-SenderInfo: xolfxt3r6o00pqjv00gofq/1tbiAQAECGTa+zICxwABs+ X-Coremail-Antispam: 1Uk129KBj93XoWxAw4Uuw1xtrW7Gw13GFWfJFc_yoWrCw1fpF WY93y7KrWkJF429wn7Xr429FyS93yfGrsrGrn8t34kG3s8JFn2qrsag3yYya47tw40yw1j qa1jqrZ5Ww4kAFXCm3ZEXasCq-sJn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ34c02F40En4AKxVAvwIkv4cxYr27v73VFW2AGmfu7bjvjm3AaLaJ3UjIY CTnIWjp_UUUYv7kC6x804xWl14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcI k0rVWrJVCq3wAFIxvE14AKwVWUGVWUXwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK 021l84ACjcxK6xIIjxv20xvE14v26r1j6r1xM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r 1j6r4UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_ Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07AIYIkI8VC2zVCFFI0UMc 02F40En4AKxVAvwIkv4cxYr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v2 6r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCjr7xvwVCIw2I0I7xG6c 02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMI IF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2 KfnxnUUI43ZEXa7IU84KZJUUUUU== Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lichao@loongson.cn List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: tiHfLmKp9ZRwOTM7YqemuJkCx7686176AA= Content-Type: multipart/alternative; boundary="------------EU86KJLkUtCv6sH3rRtwurRX" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=Oi1r+2j9; dmarc=none; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io --------------EU86KJLkUtCv6sH3rRtwurRX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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] -=-=-=-=-=-=-=-=-=-=-=- --------------EU86KJLkUtCv6sH3rRtwurRX Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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) | | Mute This Topic | New Topic
Your Subscription | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--------------EU86KJLkUtCv6sH3rRtwurRX--