public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Andrew Fish via groups.io" <afish=apple.com@groups.io>
To: edk2-devel-groups-io <devel@edk2.groups.io>, lichao@loongson.cn
Cc: Liming Gao <gaoliming@byosoft.com.cn>,
	Bob Feng <bob.c.feng@intel.com>,
	Yuwei Chen <yuwei.chen@intel.com>
Subject: Re: [edk2-devel] About EDK2 supports Self Modifying Code
Date: Mon, 14 Aug 2023 21:57:01 -0700	[thread overview]
Message-ID: <4EB062B0-6C13-480F-A2CC-95C715A08ECD@apple.com> (raw)
In-Reply-To: <22642530-3177-d5d9-426a-d5a68ebfe8c6@loongson.cn>

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

  reply	other threads:[~2023-08-15  4:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-15  3:06 [edk2-devel] About EDK2 supports Self Modifying Code Chao Li
2023-08-15  4:57 ` Andrew Fish via groups.io [this message]
2023-08-15  8:20   ` Chao Li
2023-08-15  8:28     ` Ard Biesheuvel
2023-08-15  8:54       ` Chao Li
2023-08-15 15:05         ` Andrew Fish via groups.io
2023-08-15 15:39           ` Pedro Falcato
2023-08-15 16:30             ` Andrew Fish via groups.io
2023-08-15 18:48               ` Ard Biesheuvel
2023-08-15 21:26                 ` Andrew Fish via groups.io
2023-08-17  3:38                   ` Chao Li
2023-08-15 15:35     ` Pedro Falcato
2023-08-17  2:30       ` Chao Li
2023-08-17 19:53         ` Michael D Kinney
2023-08-17 20:55           ` Andrew Fish via groups.io
2023-08-19  2:18             ` Chao Li
2023-08-19  4:29               ` Michael D Kinney
2023-08-25  4:02                 ` Chao Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EB062B0-6C13-480F-A2CC-95C715A08ECD@apple.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox