From: Atish Patra <atishp@atishpatra.org> To: "Heiko Stübner" <heiko@sntech.de> Cc: Geert Uytterhoeven <geert@linux-m68k.org>, re@w6rz.net, linux-riscv <linux-riscv@lists.infradead.org>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: Out-of-bounds access when hartid >= NR_CPUS Date: Wed, 27 Oct 2021 16:34:15 -0700 [thread overview] Message-ID: <CAOnJCU+MSP1QdpRRGYUpen8xZU+kn3PcSMJnZnRQw-iATs8JgQ@mail.gmail.com> (raw) In-Reply-To: <1714720.9tEa3Li8Nu@diego> On Tue, Oct 26, 2021 at 2:34 AM Heiko Stübner <heiko@sntech.de> wrote: > > Am Dienstag, 26. Oktober 2021, 10:57:26 CEST schrieb Geert Uytterhoeven: > > Hi Heiko, > > > > On Tue, Oct 26, 2021 at 10:53 AM Heiko Stübner <heiko@sntech.de> wrote: > > > Am Dienstag, 26. Oktober 2021, 08:44:31 CEST schrieb Geert Uytterhoeven: > > > > On Tue, Oct 26, 2021 at 2:37 AM Ron Economos <re@w6rz.net> wrote: > > > > > On 10/25/21 8:54 AM, Geert Uytterhoeven wrote: > > > > > > When booting a kernel with CONFIG_NR_CPUS=4 on Microchip PolarFire, > > > > > > the 4th CPU either fails to come online, or the system crashes. > > > > > > > > > > > > This happens because PolarFire has 5 CPU cores: hart 0 is an e51, > > > > > > and harts 1-4 are u54s, with the latter becoming CPUs 0-3 in Linux: > > > > > > - unused core has hartid 0 (sifive,e51), > > > > > > - processor 0 has hartid 1 (sifive,u74-mc), > > > > > > - processor 1 has hartid 2 (sifive,u74-mc), > > > > > > - processor 2 has hartid 3 (sifive,u74-mc), > > > > > > - processor 3 has hartid 4 (sifive,u74-mc). > > > > > > > > > > > > I assume the same issue is present on the SiFive fu540 and fu740 > > > > > > SoCs, but I don't have access to these. The issue is not present > > > > > > on StarFive JH7100, as processor 0 has hartid 1, and processor 1 has > > > > > > hartid 0. > > > > > > > > > > > > arch/riscv/kernel/cpu_ops.c has: > > > > > > > > > > > > void *__cpu_up_stack_pointer[NR_CPUS] __section(".data"); > > > > > > void *__cpu_up_task_pointer[NR_CPUS] __section(".data"); > > > > > > > > > > > > void cpu_update_secondary_bootdata(unsigned int cpuid, > > > > > > struct task_struct *tidle) > > > > > > { > > > > > > int hartid = cpuid_to_hartid_map(cpuid); > > > > > > > > > > > > /* Make sure tidle is updated */ > > > > > > smp_mb(); > > > > > > WRITE_ONCE(__cpu_up_stack_pointer[hartid], > > > > > > task_stack_page(tidle) + THREAD_SIZE); > > > > > > WRITE_ONCE(__cpu_up_task_pointer[hartid], tidle); > > > > > > > > > > > > The above two writes cause out-of-bound accesses beyond > > > > > > __cpu_up_{stack,pointer}_pointer[] if hartid >= CONFIG_NR_CPUS. > > > > > > > > > > > > } > > > > > > https://riscv.org/wp-content/uploads/2017/05/riscv-privileged-v1.10.pdf > > > > says: > > > > > > > > Hart IDs might not necessarily be numbered contiguously in a > > > > multiprocessor system, but at least one hart must have a hart > > > > ID of zero. > > > > > > > > Which means indexing arrays by hart ID is a no-go? > > > > > > Isn't that also similar on aarch64? > > > > > > On a rk3399 you get 0-3 and 100-101 and with the paragraph above > > > something like this could very well exist on some riscv cpu too I guess. > > > > Yes, it looks like hart IDs are similar to MPIDRs on ARM. > > and they have the set_cpu_logical_map construct to map hwids > to a continuous list of cpu-ids. > > So with hartids not being necessarily continuous this looks like > riscv would need a similar mechanism. > RISC-V already has a similar mechanism cpuid_to_hartid_map. Logical cpu ids are continuous while hartid can be sparse. The issue here is that __cpu_up_stack/task_pointer are per hart but array size depends on the NR_CPUs which represents the logical CPU. That's why, having a maximum number of hartids defined in config will be helpful. > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv -- Regards, Atish
WARNING: multiple messages have this Message-ID (diff)
From: Atish Patra <atishp@atishpatra.org> To: "Heiko Stübner" <heiko@sntech.de> Cc: Geert Uytterhoeven <geert@linux-m68k.org>, re@w6rz.net, linux-riscv <linux-riscv@lists.infradead.org>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: Out-of-bounds access when hartid >= NR_CPUS Date: Wed, 27 Oct 2021 16:34:15 -0700 [thread overview] Message-ID: <CAOnJCU+MSP1QdpRRGYUpen8xZU+kn3PcSMJnZnRQw-iATs8JgQ@mail.gmail.com> (raw) In-Reply-To: <1714720.9tEa3Li8Nu@diego> On Tue, Oct 26, 2021 at 2:34 AM Heiko Stübner <heiko@sntech.de> wrote: > > Am Dienstag, 26. Oktober 2021, 10:57:26 CEST schrieb Geert Uytterhoeven: > > Hi Heiko, > > > > On Tue, Oct 26, 2021 at 10:53 AM Heiko Stübner <heiko@sntech.de> wrote: > > > Am Dienstag, 26. Oktober 2021, 08:44:31 CEST schrieb Geert Uytterhoeven: > > > > On Tue, Oct 26, 2021 at 2:37 AM Ron Economos <re@w6rz.net> wrote: > > > > > On 10/25/21 8:54 AM, Geert Uytterhoeven wrote: > > > > > > When booting a kernel with CONFIG_NR_CPUS=4 on Microchip PolarFire, > > > > > > the 4th CPU either fails to come online, or the system crashes. > > > > > > > > > > > > This happens because PolarFire has 5 CPU cores: hart 0 is an e51, > > > > > > and harts 1-4 are u54s, with the latter becoming CPUs 0-3 in Linux: > > > > > > - unused core has hartid 0 (sifive,e51), > > > > > > - processor 0 has hartid 1 (sifive,u74-mc), > > > > > > - processor 1 has hartid 2 (sifive,u74-mc), > > > > > > - processor 2 has hartid 3 (sifive,u74-mc), > > > > > > - processor 3 has hartid 4 (sifive,u74-mc). > > > > > > > > > > > > I assume the same issue is present on the SiFive fu540 and fu740 > > > > > > SoCs, but I don't have access to these. The issue is not present > > > > > > on StarFive JH7100, as processor 0 has hartid 1, and processor 1 has > > > > > > hartid 0. > > > > > > > > > > > > arch/riscv/kernel/cpu_ops.c has: > > > > > > > > > > > > void *__cpu_up_stack_pointer[NR_CPUS] __section(".data"); > > > > > > void *__cpu_up_task_pointer[NR_CPUS] __section(".data"); > > > > > > > > > > > > void cpu_update_secondary_bootdata(unsigned int cpuid, > > > > > > struct task_struct *tidle) > > > > > > { > > > > > > int hartid = cpuid_to_hartid_map(cpuid); > > > > > > > > > > > > /* Make sure tidle is updated */ > > > > > > smp_mb(); > > > > > > WRITE_ONCE(__cpu_up_stack_pointer[hartid], > > > > > > task_stack_page(tidle) + THREAD_SIZE); > > > > > > WRITE_ONCE(__cpu_up_task_pointer[hartid], tidle); > > > > > > > > > > > > The above two writes cause out-of-bound accesses beyond > > > > > > __cpu_up_{stack,pointer}_pointer[] if hartid >= CONFIG_NR_CPUS. > > > > > > > > > > > > } > > > > > > https://riscv.org/wp-content/uploads/2017/05/riscv-privileged-v1.10.pdf > > > > says: > > > > > > > > Hart IDs might not necessarily be numbered contiguously in a > > > > multiprocessor system, but at least one hart must have a hart > > > > ID of zero. > > > > > > > > Which means indexing arrays by hart ID is a no-go? > > > > > > Isn't that also similar on aarch64? > > > > > > On a rk3399 you get 0-3 and 100-101 and with the paragraph above > > > something like this could very well exist on some riscv cpu too I guess. > > > > Yes, it looks like hart IDs are similar to MPIDRs on ARM. > > and they have the set_cpu_logical_map construct to map hwids > to a continuous list of cpu-ids. > > So with hartids not being necessarily continuous this looks like > riscv would need a similar mechanism. > RISC-V already has a similar mechanism cpuid_to_hartid_map. Logical cpu ids are continuous while hartid can be sparse. The issue here is that __cpu_up_stack/task_pointer are per hart but array size depends on the NR_CPUs which represents the logical CPU. That's why, having a maximum number of hartids defined in config will be helpful. > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv -- Regards, Atish _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2021-10-27 23:34 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-25 15:54 Out-of-bounds access when hartid >= NR_CPUS Geert Uytterhoeven 2021-10-25 15:54 ` Geert Uytterhoeven 2021-10-26 0:37 ` Ron Economos 2021-10-26 0:37 ` Ron Economos 2021-10-26 6:44 ` Geert Uytterhoeven 2021-10-26 6:44 ` Geert Uytterhoeven 2021-10-26 8:53 ` Heiko Stübner 2021-10-26 8:53 ` Heiko Stübner 2021-10-26 8:57 ` Geert Uytterhoeven 2021-10-26 8:57 ` Geert Uytterhoeven 2021-10-26 9:28 ` Heiko Stübner 2021-10-26 9:28 ` Heiko Stübner 2021-10-27 23:34 ` Atish Patra [this message] 2021-10-27 23:34 ` Atish Patra 2021-10-28 15:09 ` Palmer Dabbelt 2021-10-28 15:09 ` Palmer Dabbelt 2021-10-28 16:12 ` Heiko Stübner 2021-10-28 16:12 ` Heiko Stübner 2021-10-28 16:21 ` Anup Patel 2021-10-28 16:21 ` Anup Patel 2021-10-28 17:16 ` Palmer Dabbelt 2021-10-28 17:16 ` Palmer Dabbelt 2021-10-28 23:40 ` Atish Patra 2021-10-28 23:40 ` Atish Patra 2021-10-26 8:55 ` Atish Patra 2021-10-26 8:55 ` Atish Patra 2021-10-26 9:03 ` Geert Uytterhoeven 2021-10-26 9:03 ` Geert Uytterhoeven 2021-10-28 1:28 ` Atish Patra 2021-10-28 1:28 ` Atish Patra
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=CAOnJCU+MSP1QdpRRGYUpen8xZU+kn3PcSMJnZnRQw-iATs8JgQ@mail.gmail.com \ --to=atishp@atishpatra.org \ --cc=aou@eecs.berkeley.edu \ --cc=geert@linux-m68k.org \ --cc=heiko@sntech.de \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ --cc=re@w6rz.net \ /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: linkBe 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.