All of lore.kernel.org
 help / color / mirror / Atom feed
From: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
To: Deepak Gupta <debug@rivosinc.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Bin Meng <bin.meng@windriver.com>,
	liweiwei@iscas.ac.cn, dbarboza@ventanamicro.com,
	Kip Walker <kip@rivosinc.com>,
	qemu-riscv@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH v1 RFC Zisslpcfi 1/9] target/riscv: adding zimops and zisslpcfi extension to RISCV cpu config
Date: Thu, 16 Feb 2023 09:46:31 +0800	[thread overview]
Message-ID: <21dedcd4-3483-c080-7a00-6bfeacbfb314@linux.alibaba.com> (raw)
In-Reply-To: <CAKC1njQEcuEO=TSkK8qzywADYGh6cFLLUKLJ4fTfULHvKPOa=w@mail.gmail.com>


On 2023/2/16 4:47, Deepak Gupta wrote:
> On Tue, Feb 14, 2023 at 6:52 PM LIU Zhiwei <zhiwei_liu@linux.alibaba.com> wrote:
>>
>> On 2023/2/9 14:23, Deepak Gupta wrote:
>>> Introducing riscv `zisslpcfi` extension to riscv target. `zisslpcfi`
>>> extension provides hardware assistance to riscv hart to enable control
>>> flow integrity (CFI) for software.
>>>
>>> `zisslpcfi` extension expects hart to implement `zimops`. `zimops` stands
>>> for "unprivileged integer maybe operations". `zimops` carve out certain
>>> reserved opcodes encodings from integer spec to "may be operations"
>>> encodings. `zimops` opcode encodings simply move 0 to rd.
>>> `zisslpcfi` claims some of the `zimops` encodings and use them for shadow
>>> stack management or indirect branch tracking. Any future extension can
>>> also claim `zimops` encodings.
>> Does  the zimops has a independent specification? If so, you should give
>> a link to this
>> specification.
> Actual formal documentation is still a work in progress.
> I am hoping to provide a reference to it in my next iteration.
>
>>> This patch also adds a dependency check for `zimops` to be enabled if
>>> `zisslpcfi` is enabled on the hart.
>> You should don't add two extensions in one patch. I think you should add
>> them one by one.
>> And add the zimop first.  In my opinion, you should implement the whole
>> zimop extension before
>> adding any patch for zisslpcfi, including the implementation of mop.rr
>> and mop.r.
> Noted will make sure of that and will send two different patch series then.

We can rearrange the patch set as follows:

1. Implement the zimop extension.

2. Implement the forward cfi only for system mode.

3. Implement the backward cfi only for system mode.

4. Carefully make the forward cfi can work on user mode.

5. Carefully make the backward cfi work for user mode.

I don't think we can easily make cfi  work on user mode. So we can also 
ignore the 4 or 5, or both.

Thus, we don't have to implement a patch like the patch 8, which is too 
big to review.


Zhiwei

>
>>> Signed-off-by: Deepak Gupta <debug@rivosinc.com>
>>> Signed-off-by: Kip Walker  <kip@rivosinc.com>
>>> ---
>>>    target/riscv/cpu.c | 13 +++++++++++++
>>>    target/riscv/cpu.h |  2 ++
>>>    2 files changed, 15 insertions(+)
>>>
>>> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
>>> index cc75ca7667..6b4e90eb91 100644
>>> --- a/target/riscv/cpu.c
>>> +++ b/target/riscv/cpu.c
>>> @@ -110,6 +110,8 @@ static const struct isa_ext_data isa_edata_arr[] = {
>>>        ISA_EXT_DATA_ENTRY(svnapot, true, PRIV_VERSION_1_12_0, ext_svnapot),
>>>        ISA_EXT_DATA_ENTRY(svpbmt, true, PRIV_VERSION_1_12_0, ext_svpbmt),
>>>        ISA_EXT_DATA_ENTRY(xventanacondops, true, PRIV_VERSION_1_12_0, ext_XVentanaCondOps),
>>> +    ISA_EXT_DATA_ENTRY(zimops, true, PRIV_VERSION_1_12_0, ext_zimops),
>>> +    ISA_EXT_DATA_ENTRY(zisslpcfi, true, PRIV_VERSION_1_12_0, ext_cfi),
>> Add them one by one.
>>>    };
>>>
>>>    static bool isa_ext_is_enabled(RISCVCPU *cpu,
>>> @@ -792,6 +794,11 @@ static void riscv_cpu_realize(DeviceState *dev, Error **errp)
>>>                return;
>>>            }
>>>
>>> +        if (cpu->cfg.ext_cfi && !cpu->cfg.ext_zimops) {
>>> +            error_setg(errp, "Zisslpcfi extension requires Zimops extension");
>>> +            return;
>>> +        }
>>> +
>> Seems reasonable for me.
>>>            /* Set the ISA extensions, checks should have happened above */
>>>            if (cpu->cfg.ext_zdinx || cpu->cfg.ext_zhinx ||
>>>                cpu->cfg.ext_zhinxmin) {
>>> @@ -1102,6 +1109,12 @@ static Property riscv_cpu_properties[] = {
>>>    #ifndef CONFIG_USER_ONLY
>>>        DEFINE_PROP_UINT64("resetvec", RISCVCPU, env.resetvec, DEFAULT_RSTVEC),
>>>    #endif
>>> +    /*
>>> +     * Zisslpcfi CFI extension, Zisslpcfi implicitly means Zimops is
>>> +     * implemented
>>> +     */
>>> +    DEFINE_PROP_BOOL("zisslpcfi", RISCVCPU, cfg.ext_cfi, true),
>>> +    DEFINE_PROP_BOOL("zimops", RISCVCPU, cfg.ext_zimops, true),
>> Default value should be false.
> Yes, I have to fix this.
>
>> Zhiwei
>>
>>>        DEFINE_PROP_BOOL("short-isa-string", RISCVCPU, cfg.short_isa_string, false),
>>>
>>> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
>>> index f5609b62a2..9a923760b2 100644
>>> --- a/target/riscv/cpu.h
>>> +++ b/target/riscv/cpu.h
>>> @@ -471,6 +471,8 @@ struct RISCVCPUConfig {
>>>        uint32_t mvendorid;
>>>        uint64_t marchid;
>>>        uint64_t mimpid;
>>> +    bool ext_zimops;
>>> +    bool ext_cfi;
>>>
>>>        /* Vendor-specific custom extensions */
>>>        bool ext_XVentanaCondOps;


  reply	other threads:[~2023-02-16  1:46 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230209062404.3582018-1-debug@rivosinc.com>
2023-02-09  6:23 ` [PATCH v1 RFC Zisslpcfi 1/9] target/riscv: adding zimops and zisslpcfi extension to RISCV cpu config Deepak Gupta
2023-02-11  3:19   ` weiwei
2023-02-13  3:15     ` Deepak Gupta
2023-02-15  2:52   ` LIU Zhiwei
2023-02-15 20:47     ` Deepak Gupta
2023-02-16  1:46       ` LIU Zhiwei [this message]
2023-02-16  4:20         ` Richard Henderson
2023-02-09  6:23 ` [PATCH v1 RFC Zisslpcfi 2/9] target/riscv: zisslpcfi CSR, bit positions and other definitions Deepak Gupta
2023-02-11  3:32   ` weiwei
2023-02-13  3:21     ` Deepak Gupta
2023-02-15  3:31   ` LIU Zhiwei
2023-02-15 20:42     ` Deepak Gupta
2023-02-09  6:23 ` [PATCH v1 RFC Zisslpcfi 3/9] target/riscv: implements CSRs and new bits in existing CSRs in zisslpcfi Deepak Gupta
2023-02-15  5:47   ` LIU Zhiwei
2023-02-15  6:24     ` LIU Zhiwei
2023-02-15 23:42       ` Deepak Gupta
2023-02-15 23:33     ` Deepak Gupta
2023-02-16  0:02       ` Richard Henderson
2023-02-16  1:38         ` Deepak Gupta
2023-02-16  2:43           ` Richard Henderson
2023-02-16  5:20             ` Deepak Gupta
2023-02-09  6:23 ` [PATCH v1 RFC Zisslpcfi 4/9] target/riscv: helper functions for forward and backward cfi Deepak Gupta
2023-02-15  6:26   ` LIU Zhiwei
2023-02-15 23:35     ` Deepak Gupta
2023-02-09  6:24 ` [PATCH v1 RFC Zisslpcfi 5/9] target/riscv: state save and restore of zisslppcfi state Deepak Gupta
2023-02-15  6:10   ` LIU Zhiwei
2023-02-15 23:13     ` Deepak Gupta
2023-02-09  6:24 ` [PATCH v1 RFC Zisslpcfi 6/9] target/riscv: MMU changes for back cfi's shadow stack Deepak Gupta
2023-02-15  8:43   ` LIU Zhiwei
2023-02-15 23:57     ` Deepak Gupta
2023-02-16  2:36       ` LIU Zhiwei
2023-02-16  5:43         ` Deepak Gupta
2023-02-09  6:24 ` [PATCH v1 RFC Zisslpcfi 7/9] target/riscv: Tracking indirect branches (fcfi) using TCG Deepak Gupta
2023-02-15  8:55   ` LIU Zhiwei
2023-02-16  0:02     ` Deepak Gupta
2023-02-16  2:43       ` LIU Zhiwei
2023-02-16  5:45         ` Deepak Gupta
2023-02-16  6:05   ` Richard Henderson
2023-02-09  6:24 ` [PATCH v1 RFC Zisslpcfi 8/9] target/riscv: Instructions encodings, implementation and handlers Deepak Gupta
2023-02-15 10:43   ` LIU Zhiwei
2023-02-09  6:24 ` [PATCH v1 RFC Zisslpcfi 9/9] target/riscv: diassembly support for zisslpcfi instructions Deepak Gupta
2023-02-09  6:29 [PATCH v1 RFC Zisslpcfi 0/9] zimops and zisslpcfi extension to riscv Deepak Gupta
2023-02-09  6:29 ` [PATCH v1 RFC Zisslpcfi 1/9] target/riscv: adding zimops and zisslpcfi extension to RISCV cpu config Deepak Gupta

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-all 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=21dedcd4-3483-c080-7a00-6bfeacbfb314@linux.alibaba.com \
    --to=zhiwei_liu@linux.alibaba.com \
    --cc=alistair.francis@wdc.com \
    --cc=bin.meng@windriver.com \
    --cc=dbarboza@ventanamicro.com \
    --cc=debug@rivosinc.com \
    --cc=kip@rivosinc.com \
    --cc=liweiwei@iscas.ac.cn \
    --cc=palmer@dabbelt.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.