From: Sergey Matyukevich <geomatsi@gmail.com>
To: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Cc: Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Alexandre Ghiti <alex@ghiti.fr>, Oleg Nesterov <oleg@redhat.com>,
Shuah Khan <shuah@kernel.org>, Thomas Huth <thuth@redhat.com>,
Charlie Jenkins <charlie@rivosinc.com>,
Andy Chiu <andybnac@gmail.com>,
Samuel Holland <samuel.holland@sifive.com>,
Joel Granados <joel.granados@kernel.org>,
Conor Dooley <conor.dooley@microchip.com>,
Yong-Xuan Wang <yongxuan.wang@sifive.com>,
Heiko Stuebner <heiko@sntech.de>,
Sergey Matyukevich <geomatsi@gmail.com>
Subject: [PATCH v4 4/9] riscv: vector: init vector context with proper vlenb
Date: Sat, 8 Nov 2025 22:41:43 +0300 [thread overview]
Message-ID: <20251108194207.1257866-5-geomatsi@gmail.com> (raw)
In-Reply-To: <20251108194207.1257866-1-geomatsi@gmail.com>
The vstate in thread_struct is zeroed when the vector context is
initialized. That includes read-only register vlenb, which holds
the vector register length in bytes. This zeroed state persists
until mstatus.VS becomes 'dirty' and a context switch saves the
actual hardware values.
This can expose the zero vlenb value to the user-space in early
debug scenarios, e.g. when ptrace attaches to a traced process
early, before any vector instruction except the first one was
executed.
Fix this by specifying proper vlenb on vector context init.
Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
---
arch/riscv/kernel/vector.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/riscv/kernel/vector.c b/arch/riscv/kernel/vector.c
index 901e67adf576..34048c4c26dc 100644
--- a/arch/riscv/kernel/vector.c
+++ b/arch/riscv/kernel/vector.c
@@ -109,8 +109,8 @@ bool insn_is_vector(u32 insn_buf)
return false;
}
-static int riscv_v_thread_zalloc(struct kmem_cache *cache,
- struct __riscv_v_ext_state *ctx)
+static int riscv_v_thread_ctx_alloc(struct kmem_cache *cache,
+ struct __riscv_v_ext_state *ctx)
{
void *datap;
@@ -120,13 +120,15 @@ static int riscv_v_thread_zalloc(struct kmem_cache *cache,
ctx->datap = datap;
memset(ctx, 0, offsetof(struct __riscv_v_ext_state, datap));
+ ctx->vlenb = riscv_v_vsize / 32;
+
return 0;
}
void riscv_v_thread_alloc(struct task_struct *tsk)
{
#ifdef CONFIG_RISCV_ISA_V_PREEMPTIVE
- riscv_v_thread_zalloc(riscv_v_kernel_cachep, &tsk->thread.kernel_vstate);
+ riscv_v_thread_ctx_alloc(riscv_v_kernel_cachep, &tsk->thread.kernel_vstate);
#endif
}
@@ -212,12 +214,14 @@ bool riscv_v_first_use_handler(struct pt_regs *regs)
* context where VS has been off. So, try to allocate the user's V
* context and resume execution.
*/
- if (riscv_v_thread_zalloc(riscv_v_user_cachep, ¤t->thread.vstate)) {
+ if (riscv_v_thread_ctx_alloc(riscv_v_user_cachep, ¤t->thread.vstate)) {
force_sig(SIGBUS);
return true;
}
+
riscv_v_vstate_on(regs);
riscv_v_vstate_set_restore(current, regs);
+
return true;
}
--
2.51.0
WARNING: multiple messages have this Message-ID (diff)
From: Sergey Matyukevich <geomatsi@gmail.com>
To: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Cc: Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Alexandre Ghiti <alex@ghiti.fr>, Oleg Nesterov <oleg@redhat.com>,
Shuah Khan <shuah@kernel.org>, Thomas Huth <thuth@redhat.com>,
Charlie Jenkins <charlie@rivosinc.com>,
Andy Chiu <andybnac@gmail.com>,
Samuel Holland <samuel.holland@sifive.com>,
Joel Granados <joel.granados@kernel.org>,
Conor Dooley <conor.dooley@microchip.com>,
Yong-Xuan Wang <yongxuan.wang@sifive.com>,
Heiko Stuebner <heiko@sntech.de>,
Sergey Matyukevich <geomatsi@gmail.com>
Subject: [PATCH v4 4/9] riscv: vector: init vector context with proper vlenb
Date: Sat, 8 Nov 2025 22:41:43 +0300 [thread overview]
Message-ID: <20251108194207.1257866-5-geomatsi@gmail.com> (raw)
In-Reply-To: <20251108194207.1257866-1-geomatsi@gmail.com>
The vstate in thread_struct is zeroed when the vector context is
initialized. That includes read-only register vlenb, which holds
the vector register length in bytes. This zeroed state persists
until mstatus.VS becomes 'dirty' and a context switch saves the
actual hardware values.
This can expose the zero vlenb value to the user-space in early
debug scenarios, e.g. when ptrace attaches to a traced process
early, before any vector instruction except the first one was
executed.
Fix this by specifying proper vlenb on vector context init.
Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
---
arch/riscv/kernel/vector.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/riscv/kernel/vector.c b/arch/riscv/kernel/vector.c
index 901e67adf576..34048c4c26dc 100644
--- a/arch/riscv/kernel/vector.c
+++ b/arch/riscv/kernel/vector.c
@@ -109,8 +109,8 @@ bool insn_is_vector(u32 insn_buf)
return false;
}
-static int riscv_v_thread_zalloc(struct kmem_cache *cache,
- struct __riscv_v_ext_state *ctx)
+static int riscv_v_thread_ctx_alloc(struct kmem_cache *cache,
+ struct __riscv_v_ext_state *ctx)
{
void *datap;
@@ -120,13 +120,15 @@ static int riscv_v_thread_zalloc(struct kmem_cache *cache,
ctx->datap = datap;
memset(ctx, 0, offsetof(struct __riscv_v_ext_state, datap));
+ ctx->vlenb = riscv_v_vsize / 32;
+
return 0;
}
void riscv_v_thread_alloc(struct task_struct *tsk)
{
#ifdef CONFIG_RISCV_ISA_V_PREEMPTIVE
- riscv_v_thread_zalloc(riscv_v_kernel_cachep, &tsk->thread.kernel_vstate);
+ riscv_v_thread_ctx_alloc(riscv_v_kernel_cachep, &tsk->thread.kernel_vstate);
#endif
}
@@ -212,12 +214,14 @@ bool riscv_v_first_use_handler(struct pt_regs *regs)
* context where VS has been off. So, try to allocate the user's V
* context and resume execution.
*/
- if (riscv_v_thread_zalloc(riscv_v_user_cachep, ¤t->thread.vstate)) {
+ if (riscv_v_thread_ctx_alloc(riscv_v_user_cachep, ¤t->thread.vstate)) {
force_sig(SIGBUS);
return true;
}
+
riscv_v_vstate_on(regs);
riscv_v_vstate_set_restore(current, regs);
+
return true;
}
--
2.51.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2025-11-08 19:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-08 19:41 [PATCH v4 0/9] riscv: vector: misc ptrace fixes for debug use-cases Sergey Matyukevich
2025-11-08 19:41 ` Sergey Matyukevich
2025-11-08 19:41 ` [PATCH v4 1/9] selftests: riscv: test ptrace vector interface Sergey Matyukevich
2025-11-08 19:41 ` Sergey Matyukevich
2025-11-19 17:13 ` Andy Chiu
2025-11-19 17:13 ` Andy Chiu
2025-11-20 19:02 ` Sergey Matyukevich
2025-11-20 19:02 ` Sergey Matyukevich
2025-11-08 19:41 ` [PATCH v4 2/9] riscv: ptrace: return ENODATA for inactive vector extension Sergey Matyukevich
2025-11-08 19:41 ` Sergey Matyukevich
2025-11-08 19:41 ` [PATCH v4 3/9] selftests: riscv: verify initial vector state with ptrace Sergey Matyukevich
2025-11-08 19:41 ` Sergey Matyukevich
2025-11-08 19:41 ` Sergey Matyukevich [this message]
2025-11-08 19:41 ` [PATCH v4 4/9] riscv: vector: init vector context with proper vlenb Sergey Matyukevich
2025-11-08 19:41 ` [PATCH v4 5/9] riscv: csr: define vtype registers elements Sergey Matyukevich
2025-11-08 19:41 ` Sergey Matyukevich
2025-11-08 19:41 ` [PATCH v4 6/9] riscv: ptrace: validate input vector csr registers Sergey Matyukevich
2025-11-08 19:41 ` Sergey Matyukevich
2025-11-08 19:41 ` [PATCH v4 7/9] selftests: riscv: verify ptrace rejects invalid vector csr inputs Sergey Matyukevich
2025-11-08 19:41 ` Sergey Matyukevich
2025-11-08 19:41 ` [PATCH v4 8/9] selftests: riscv: verify ptrace accepts valid vector csr values Sergey Matyukevich
2025-11-08 19:41 ` Sergey Matyukevich
2025-11-08 19:41 ` [PATCH v4 9/9] selftests: riscv: verify syscalls discard vector context Sergey Matyukevich
2025-11-08 19:41 ` Sergey Matyukevich
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=20251108194207.1257866-5-geomatsi@gmail.com \
--to=geomatsi@gmail.com \
--cc=alex@ghiti.fr \
--cc=andybnac@gmail.com \
--cc=charlie@rivosinc.com \
--cc=conor.dooley@microchip.com \
--cc=heiko@sntech.de \
--cc=joel.granados@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=oleg@redhat.com \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=samuel.holland@sifive.com \
--cc=shuah@kernel.org \
--cc=thuth@redhat.com \
--cc=yongxuan.wang@sifive.com \
/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.