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 0E0D97803CE for ; Thu, 17 Aug 2023 02:30:38 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=r57D7t+lorGh6gDv2QC27OR2bjvi2RGBgO6sGe9dVZ0=; 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=1692239437; v=1; b=ngfz1Xpkb8lKTfMEbgylHrJu48KYSuee0wMFpXTdwdH4zcWvwcAy4qwQcbrehBW0JGs2L/zk hep09/34ChuBntLLrUXnPzNp2f6Vg+y5CVaosaxfuoNUQFwTA+rXThRg+B1SuxfCbW70QfszzeM IPj+USwWw1vXP1LIhcldigV8= X-Received: by 127.0.0.2 with SMTP id SskSYY7687511x0seHbIG14p; Wed, 16 Aug 2023 19:30:37 -0700 X-Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by mx.groups.io with SMTP id smtpd.web10.178625.1692239435545787099 for ; Wed, 16 Aug 2023 19:30:36 -0700 X-Received: from loongson.cn (unknown [10.40.24.149]) by gateway (Coremail) with SMTP id _____8CxbetGht1k81cZAA--.49873S3; Thu, 17 Aug 2023 10:30:30 +0800 (CST) X-Received: from [10.40.24.149] (unknown [10.40.24.149]) by localhost.localdomain (Coremail) with SMTP id AQAAf8CxLCNFht1kM21cAA--.11230S3; Thu, 17 Aug 2023 10:30:29 +0800 (CST) Message-ID: <0f741dad-fd9b-7402-453c-0457875bfba9@loongson.cn> Date: Thu, 17 Aug 2023 10:30:29 +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, pedro.falcato@gmail.com 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: AQAAf8CxLCNFht1kM21cAA--.11230S3 X-CM-SenderInfo: xolfxt3r6o00pqjv00gofq/1tbiAQAGCGTcTLIGgAABsO X-Coremail-Antispam: 1Uk129KBj93XoWxurW5GF47WFyrXw1UtryUXFc_yoW5GFW5pF ZIg3y3GrZ7JF4j9w1DZw4xZa1Y9r4fGr43WrnIqry8Xas8GryqvrWfK390kF9rAr1I9w1j qa12qr98Wa1qyFgCm3ZEXasCq-sJn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3UbIjqfuFe4nvWSU5nxnvy29KBjDU0xBIdaVrnRJUUUv0b4IE77IF4wAF F20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r 106r15M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAF wI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv67 AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVW8Jr0_Cr1UM2AIxVAIcxkEcVAq 07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx1lYx0E2Ix0cI8IcVAFwI0_JrI_Jr ylYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCj r7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrw CFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE 14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2 IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxK x2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI 0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU1F_M3UUUUU== 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: RcxheMf3fCyqsuiP4Nceqptux7686176AA= Content-Type: multipart/alternative; boundary="------------7YHE797KqjTovTBb1BZFDFnm" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=ngfz1Xpk; 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 --------------7YHE797KqjTovTBb1BZFDFnm Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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] -=-=-=-=-=-=-=-=-=-=-=- --------------7YHE797KqjTovTBb1BZFDFnm Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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

_._,_._,_
--------------7YHE797KqjTovTBb1BZFDFnm--