linux-kernel - Re: [PATCH] riscv: Only flush the mm icache when setting an exec pte

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Tue, 25 Jun 2024 13:45:10 +0200
From: Alexandre Ghiti <alexghiti@...osinc.com>
To: 桂兵 <guibing@...leisys.com>
Cc: aou <aou@...s.berkeley.edu>, linux-kernel <linux-kernel@...r.kernel.org>, 
	linux-riscv <linux-riscv@...ts.infradead.org>, palmer <palmer@...belt.com>, 
	"paul.walmsley" <paul.walmsley@...ive.com>, 方华启 <hqfang@...leisys.com>
Subject: Re: [PATCH] riscv: Only flush the mm icache when setting an exec pte

Hi Guibing,

You sent your email in html, so it got rejected by the ML, make sure
you reply in plain text mode :)

On Tue, Jun 25, 2024 at 10:45 AM 桂兵 <guibing@...leisys.com> wrote:
>
> Hi alex，
>
> We have encountered a problem related to this patch and would like to ask for your advice, thank you in advance!
>
> Problem description:
> When we use the v6.9 kernel, there is an illegal instruction problem when executing a statically linked application on an SD card, and this problem is not reproduced in v6.6/v6.1 kernel.
> SD card driver uses PIO mode, and the SD card interrupt is bound to core0. If the system schedule the apllication to execute on core1, core2, or core3, it will report an illegal instruction, and if scheduled to execute on core0, it will be executed successfully.

Is it a multithreaded application? You mean that if the application
always runs on core1/2/3, you get an illegal instruction, but that
does not happen when run on core0?

>
> We track the source code, flush_icache_pte function patch leads to this issue on our riscv hardware.
> If you merge this patch into the v6.1 kernel, the same problem can be reproduced in v6.1 kernel.
> If using flush_icache_all() not flush_icache_mm in v6.9 kernel ; this issue can not be reproduced in v6.9 kernel.
>
> +void flush_icache_pte(struct mm_struct *mm, pte_t pte)
>  {
>  struct folio *folio = page_folio(pte_page(pte));
>
>  if (!test_bit(PG_dcache_clean, &folio->flags)) {
> -           flush_icache_all();
> +           flush_icache_mm(mm, false);
>  set_bit(PG_dcache_clean, &folio->flags);
>  }
>  }

Did you check if the instruction in badaddr is different from the
expected instruction? The image you provided is not available here,
but it indicated 0xf486 which corresponds to "c.sdsp  ra, 104(sp)", is
that correct?

>
>
> Our riscv cpu IP supports multi-core L1 dcache synchronization, but does not support multi-core L1 icache synchronization. iCache synchronization requires software maintenance.
> Does the RISCV architecture kernel in future have mandatory requirements for multi-core iCache hardware consistency?

No no, we try to introduce icache flushes whenever it is needed for such uarch.

>
> Thank you for your reply!
>
>
> Link：[PATCH] riscv: Only flush the mm icache when setting an exec pte - Alexandre Ghiti (kernel.org)
>
> ________________________________
> 发自我的企业微信
>
>

Thanks for the report,

Alex