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 EC17ED806DA for ; Tue, 15 Aug 2023 08:55:08 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=/Sro0yV0cFPNqn4G+qpprxcgTh3tvad+Q5oFKkI9oYs=; 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=1692089707; v=1; b=e6UC2RzmgFaZGIQJMKOOeNwXFP4k6uRkWBA4cAnnWotygOvSy+/uewhNx+/7V8hBduZguHv7 2AY9vejpxEUU7djR7ebIS6bL4vkwhjPGyNF9VzJhm2jLe4s9+TI7Sdv7MExAPsYf83DIoQj6ySP 5GwqqcmO/f5ZOWoEUURdBOeE= X-Received: by 127.0.0.2 with SMTP id R3hqYY7687511xwnistMR0Nm; Tue, 15 Aug 2023 01:55:07 -0700 X-Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by mx.groups.io with SMTP id smtpd.web11.130323.1692089705952230866 for ; Tue, 15 Aug 2023 01:55:06 -0700 X-Received: from loongson.cn (unknown [10.40.24.149]) by gateway (Coremail) with SMTP id _____8BxXetmPdtk+7IYAA--.45648S3; Tue, 15 Aug 2023 16:55:02 +0800 (CST) X-Received: from [10.40.24.149] (unknown [10.40.24.149]) by localhost.localdomain (Coremail) with SMTP id AQAAf8BxXSNjPdtk9whbAA--.8505S3; Tue, 15 Aug 2023 16:54:59 +0800 (CST) Message-ID: <0026aa43-c2d6-92bf-77a0-391a608e8b22@loongson.cn> Date: Tue, 15 Aug 2023 16:54:59 +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: devel@edk2.groups.io, ardb@kernel.org Cc: "Andrew (EFI) Fish" , 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: X-CM-TRANSID: AQAAf8BxXSNjPdtk9whbAA--.8505S3 X-CM-SenderInfo: xolfxt3r6o00pqjv00gofq/1tbiAQAECGTa+zIDWgAAsj X-Coremail-Antispam: 1Uk129KBj93XoWxAw48AFyruw47tFW7Ar4UJrc_yoW5GF45pF Z8K3yfAryDtF4j934UArWjq3WSgw4SkF4Uurn8t348Gas5JFn7tr4fKryYyFy7Cw1ru3WU Xa1Yqw45Wa1UCagCm3ZEXasCq-sJn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3UbIjqfuFe4nvWSU5nxnvy29KBjDU0xBIdaVrnRJUUU9Ib4IE77IF4wAF F20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r 1Y6r17M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAF wI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2js IE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1le2I262IYc4CY 6c8Ij28IcVAaY2xG8wAqjxCEc2xF0cIa020Ex4CE44I27wAv7VC0I7IYx2IY67AKxVWUGV WUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48J Mx8GjcxK6IxK0xIIj40E5I8CrwCYjI0SjxkI62AI1cAE67vIY487MxAIw28IcxkI7VAKI4 8JMxC20s026xCaFVCjc4AY6r1j6r4UMxCIbckI1I0E14v26r126r1DMI8I3I0E5I8CrVAF wI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc4 0Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AK xVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr 1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUFrWrDUUU U 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: mXCxNCsPQyBVcMpU58qNfZkCx7686176AA= Content-Type: multipart/alternative; boundary="------------l7o4xxbTRXTeOHHY6OYTe9ed" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=e6UC2Rzm; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=none --------------l7o4xxbTRXTeOHHY6OYTe9ed Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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] -=-=-=-=-=-=-=-=-=-=-=- --------------l7o4xxbTRXTeOHHY6OYTe9ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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

_._,_._,_
--------------l7o4xxbTRXTeOHHY6OYTe9ed--