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 CA7AB74003B for ; Thu, 17 Aug 2023 03:38:29 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=X2RE+LVzVzemwVD/zeY7wO34Xucl/cbEIE/c45uQxRU=; 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=1692243508; v=1; b=uWpNkohlnlC1gBCIExtuZtYVmgZPOxnbP+h0jQvCySCis2DNtmtSWsvbUlxuwKryKv0bbM/G NmtWKLEtqAHttsV1lYRhvZWkO2z0jC75ftOA4p38eE7jAmpe/u4onZqIfd/H3ojT8NPx7zTamZ6 IamDnxX5VUyDn7SlqHWFSICs= X-Received: by 127.0.0.2 with SMTP id ic55YY7687511xSVngh3dZ88; Wed, 16 Aug 2023 20:38:28 -0700 X-Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by mx.groups.io with SMTP id smtpd.web10.179544.1692243506558917392 for ; Wed, 16 Aug 2023 20:38:27 -0700 X-Received: from loongson.cn (unknown [10.40.24.149]) by gateway (Coremail) with SMTP id _____8AxlPAult1kkFwZAA--.52219S3; Thu, 17 Aug 2023 11:38:22 +0800 (CST) X-Received: from [10.40.24.149] (unknown [10.40.24.149]) by localhost.localdomain (Coremail) with SMTP id AQAAf8DxJ80qlt1kL3VcAA--.28546S3; Thu, 17 Aug 2023 11:38:18 +0800 (CST) Message-ID: Date: Thu, 17 Aug 2023 11:38:18 +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, afish@apple.com, Ard Biesheuvel , Michael D Kinney Cc: Pedro Falcato , Liming Gao , Bob Feng , Yuwei Chen References: <22642530-3177-d5d9-426a-d5a68ebfe8c6@loongson.cn> <4EB062B0-6C13-480F-A2CC-95C715A08ECD@apple.com> <0026aa43-c2d6-92bf-77a0-391a608e8b22@loongson.cn> <30CC4A49-0827-4960-A8F5-F44F534051F9@apple.com> <360DC97D-9F0F-4B86-B441-1C9789912AC6@apple.com> <0F79F614-3F6B-4262-93A6-26DF5FB8C11A@apple.com> From: "Chao Li" In-Reply-To: <0F79F614-3F6B-4262-93A6-26DF5FB8C11A@apple.com> X-CM-TRANSID: AQAAf8DxJ80qlt1kL3VcAA--.28546S3 X-CM-SenderInfo: xolfxt3r6o00pqjv00gofq/1tbiAQAGCGTcTLIHfwABsw X-Coremail-Antispam: 1Uk129KBj93XoWxur4kXw1DZF4kKrW3tFW3CFX_yoWrCF1Dpa y5G34Ykr4kJa1xu34Ika1SgF1FqFs5JrW5X390q3yj93W5Ga4vgFs2yryYyry7Zws5u342 gFWjqw4rWas8ZFXCm3ZEXasCq-sJn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ34c02F40En4AKxVAvwIkv4cxYr27v73VFW2AGmfu7bjvjm3AaLaJ3UjIY CTnIWjp_UUUYv7kC6x804xWl14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcI k0rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK 021l84ACjcxK6xIIjxv20xvE14v26r4j6ryUM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r 4j6F4UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_ Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07AIYIkI8VC2zVCFFI0UMc 02F40En4AKxVAvwIkv4cxYr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v2 6r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCjr7xvwVCIw2I0I7xG6c 02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMI IF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2 KfnxnUUI43ZEXa7IU1tEf7UUUUU== 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: usrwzlhukKnAvAuQ95bk7Fuhx7686176AA= Content-Type: multipart/alternative; boundary="------------92P0EgD0lzpVyWb84TcJFuca" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=uWpNkohl; 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 --------------92P0EgD0lzpVyWb84TcJFuca Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 wrote: >> >> On Tue, 15 Aug 2023 at 18:31, Andrew Fish viagroups.io >> >> wrote: >>> >>> >>> >>>> On Aug 15, 2023, at 8:39 AM, Pedro Falcato >>>> wrote: >>>> >>>> On Tue, Aug 15, 2023 at 4:05 PM Andrew Fish via 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] -=-=-=-=-=-=-=-=-=-=-=- --------------92P0EgD0lzpVyWb84TcJFuca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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


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.


Thanks,

Andrew Fish



_._,_._,_
Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#107822) | | Mute This Topic | New Topic
Your Subscription | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--------------92P0EgD0lzpVyWb84TcJFuca--