fuwei has quit [Remote host closed the connection]
handsome_feng has joined #riscv
emilknievel has joined #riscv
Tenkawa has quit [Quit: Was I really ever here?]
Trifton has joined #riscv
vagrantc has quit [Ping timeout: 255 seconds]
emilknievel has quit [Ping timeout: 245 seconds]
emilknievel has joined #riscv
khem has joined #riscv
esv_ has quit [Quit: Leaving]
esv_ has joined #riscv
BootLayer has joined #riscv
jacklsw has quit [Quit: Back to the real world]
naoki has quit [Quit: naoki]
marcj has joined #riscv
vagrantc has joined #riscv
mlw has joined #riscv
EchelonX has quit [Quit: Leaving]
BootLayer has quit [Quit: Leaving]
sakman has joined #riscv
vagrantc has quit [Quit: leaving]
crossdev has joined #riscv
vgtw has joined #riscv
prabhakar has quit [Ping timeout: 255 seconds]
crabbedhaloablut has quit []
crabbedhaloablut has joined #riscv
ldevulder has joined #riscv
crossdev has quit [Remote host closed the connection]
crossdev has joined #riscv
naoki has joined #riscv
naoki has quit [Client Quit]
lagash has quit [Ping timeout: 260 seconds]
khem has quit [Quit: Connection closed for inactivity]
zups has joined #riscv
davidlt has joined #riscv
mlw has quit [Ping timeout: 245 seconds]
danilogondolfo has joined #riscv
mlw has joined #riscv
mlw has quit [Read error: Connection reset by peer]
naoki has joined #riscv
naoki has quit [Quit: naoki]
lagash has joined #riscv
mlw has joined #riscv
<lzrd>
hello, I'm quite new to risc-v. Been going through the spec and had fun booting a minimal busybox-based system on qemu-system-riscv64 "virt" machine.
<lzrd>
I want to build my own RISC-V core on FPGA, and wanted to ask about ways I can get started. Is there a standard core that's like the bare minimum one needs to boot linux?
<lzrd>
I saw cnlohr's mini-rv32ima project, looked like a nice long-term goal (end of 2024 maybe) for hardware implementation.
paulk has quit [Quit: WeeChat 3.0]
paulk has joined #riscv
naoki has joined #riscv
naoki has quit [Client Quit]
psydroid has joined #riscv
Tenkawa has joined #riscv
esv_ is now known as esv
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #riscv
<sorear>
lzrd: there are a couple of reasonably popular cores that are used to boot linux on a fpga, https://github.com/SpinalHDL/VexRiscv was probably the most minimal well-supported one a couple years ago
<somlo>
then your FPGA bitstream can also be built using FOSS tools (yosys/trellis/nextpnr) -- you can fit one 64bit rocket core (capable of running fedora and/or debian), or multiple vexriscv 32-bit core
<somlo>
*cores
smaeul has joined #riscv
EchelonX has joined #riscv
<sorear>
somlo: does the 64bit rocket that fits have a hardware FPU, does linux still work with bbl for FP emulation, or is there a new way to do FP emulation in opensbi/in the kernel/otherwise?
___nick___ has joined #riscv
ldevulder_ has joined #riscv
JanC_ has joined #riscv
JanC has quit [Killed (lithium.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
jakzale_ has joined #riscv
raghavgururajan_ has joined #riscv
sumoon_ has joined #riscv
shreyasminocha_ has joined #riscv
pld_ has joined #riscv
foxbat_ has joined #riscv
ln5_ has joined #riscv
prabhakalad has quit [*.net *.split]
ldevulder has quit [*.net *.split]
djdelorie has quit [*.net *.split]
motherfsck has quit [*.net *.split]
foxbat has quit [*.net *.split]
clemens3 has quit [*.net *.split]
ln5 has quit [*.net *.split]
jakzale has quit [*.net *.split]
pld has quit [*.net *.split]
sumoon has quit [*.net *.split]
shreyasminocha has quit [*.net *.split]
raghavgururajan has quit [*.net *.split]
chripo has quit [*.net *.split]
jakzale_ is now known as jakzale
sumoon_ is now known as sumoon
pld_ is now known as pld
shreyasminocha_ is now known as shreyasminocha
prabhakalad has joined #riscv
motherfsck has joined #riscv
coaden has quit [Ping timeout: 260 seconds]
clemens3 has joined #riscv
djdelorie has joined #riscv
djdelorie has quit [Client Quit]
djdelorie has joined #riscv
<drmpeg>
Seeing some error messages on Linux 6.9.0-rc1.
<drmpeg>
irq: no irq domain found for interrupt-controller@c000000 !
<drmpeg>
CCACHE: Could not request IRQ 0
<davidlt>
drmpeg, QEMU/HW?
<drmpeg>
Unmatched.
<conchuod>
drmpeg: chaning the plic to a platform driver broke the ccache :)
<drmpeg>
Gotcha.
<conchuod>
On an unmatched the ccache driver pretty much only exists to expose the ECC stuff to the edac driver, so it shouldn't be functionally different. Samuel said he'd send a fix, if he doesn't, I'll do it this week.
<drmpeg>
Yeah, it's working fine otherwise.
<drmpeg>
All other interrupts are present.
chripo has joined #riscv
<conchuod>
tl;dr is that driver is initialised by an arch_initcall() and that happens before the platform driver plic is available.
___nick___ has quit [Ping timeout: 255 seconds]
<lzrd>
sorear, geertu, somlo thanks! Sorry for the late reply but I have starred all the repos.
<lzrd>
somlo: unfortunately I can't get a specific board. Will have to make do with the PYNQ-Z2 available at my uni lab.
JanC has quit [Killed (lead.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
<sorear>
would it be fair to say that, at least for non-kernel-threads, task_pt_regs(task) is always the user-mode registers, the interrupted syscall context pt_regs live somewhere on the stack and can't be found except by unwinding/continuing execution from task->thread?
luca_ has joined #riscv
luca_ is now known as OwlWizard
Tenkawa has quit [Quit: Was I really ever here?]
<smaeul>
sorear: `task_pt_regs` points to the first frame on the kernel stack, so for user threads, yes, it is always the user-mode registers
<smaeul>
for preempt, there are additional pt_regs pushed to the kernel stack when handling an exception/IRQ. these are accessible via get_irq_regs()
Tenkawa has joined #riscv
<smaeul>
all of the exception/IRQ handling functions (see arch/riscv/kernel/traps.c) take a pointer to the just-pushed pt_regs. this could be either the user-mode registers or an interrupted kernel context.
<sorear>
that seems to tell you what the pt_regs of the interrupted context in hardirq context is, it doesn't tell you the pt_regs of the syscall context in a task that was preempted mid-syscall
<sorear>
is the latter something that has a name and a generic access method or does it only exist implicitly?
<smaeul>
if you mean a task that has been scheduled out due to preemption, that is the fields in `struct thread_struct` as written by __switch_to()
<sorear>
that's less than half of the architectural registers
<sorear>
preemption can happen on any instruction boundary, so the rest of them have to be stored somewhere
<sorear>
you're going along in syscall context. a timer interrupt happens, the syscall register state is stored as a pt_regs presumably(?) on the task kernel stack, directly below the stack memory which was used by the syscall context. we are now in a hardirq context with a valid get_irq_regs()
<sorear>
does PREEMPT=y just mean that you can schedule while in specific hardirq contexts, and the swapped out task has thread_struct containing enough registers to go back to the hardirq context before returning from the timer interrupt?
<smaeul>
the pt_regs for the syscall handler is stored on the task's stack when entering the timer interrupt, yes
<smaeul>
then scheduling happens in softirq context inside the interrupt, and the callee-saved registers from the call to switch_to() get stored in thread_struct
<smaeul>
when switching back to the original thread, that also happens in softirq context, and we return from switch_to() as if nothing happened, finish the interrupt handling, and pop the pt_regs in ret_from_exception()
<smaeul>
so to (I think) answer your original question, the pointer to that pt_regs is not saved anywhere easily accessible
<smaeul>
...accessible by another thread
<sorear>
I found preempt_schedule_irq and TIF_NEED_RESCHED
naoki has joined #riscv
<sorear>
every architecture other than openrisc either unconditionally has !user_mode(task_pt_regs(new)) after copy_thread with fn != NULL, or (alpha, x86) copies enough of task_pt_regs that the new thread will match its parent, which I haven't figured out yet where init_task gets its stack
<smaeul>
init_task's stack is statically allocated (init/init_task.c)
<sorear>
in several cases this only happens because of the /* Clear stale pointers from reused stack. */ zeroing the pt_regs region, which is supervisor mode on most of our architectures
<sorear>
in kernel/fork.c
<smaeul>
init_task's pt_regs is allocated in arch/riscv/kernel/head.S (search PT_SIZE_ON_STACK)
<sorear>
the task_struct is statically allocated but I don't see a char array of size THREAD_SIZE in that file
<smaeul>
it's allocated in the linker script: . = __start_init_task + THREAD_SIZE;
<sorear>
so it's in .data and therefore zeroed
<smaeul>
right
<sorear>
I was on v6.1 for some reason, need to redo my review...
<sorear>
what uses !user_mode(task_pt_regs(p)) as a kernel thread check instead PF_KTHREAD?
EchelonX has quit [Quit: Leaving]
<sorear>
do you think there'd be any interest in counting M-mode events if exclude_hv=0 and it is not forbidden by the platform security policy?
<smaeul>
> what uses !user_mode(task_pt_regs(p)) // possibly nothing, but I don't know for which (if any) calls to user_mode(regs) that regs is task_pt_regs(p)
<sorear>
It doesn't make any conceptual sense and it isn't true on openrisc (or arm CPU_V7M=y, where user_mode returns true for all possible pt_regs)
<sorear>
still given that the other 19 architectures do the same thing I no longer consider it obviously useless code in riscv
<smaeul>
right, conceptually kernel threads don't even need a pt_regs on stack because they will never get to the end of ret_from_fork()
<sorear>
there's a difference between kernel_thread and user_mode_thread, user_mode_thread still needs to reserve space for the pt_regs or else kernel_execve might step on something important
<smaeul>
we didn't actually allocate one for the init task until c7cdd96eca2810f5b69c37eb439ec63d59fa1b83 because FP and vector switch_to() use task_pt_regs()
<smaeul>
and so assume there is one allocated
<smaeul>
> there's a difference between kernel_thread and user_mode_thread // yes, exactly
<sorear>
I'm planning to submit two patches, (A) clear registers in ELF_PLAT_INIT (B) remove the gp set from copy_thread
<sorear>
(A) is needed anyway because there's also a user-to-user information leak if you're dropping privileges
<sorear>
other arches are split between using *_PLAT_INIT and using start_thread; I'm favoring *_PLAT_INIT because it has to be binfmt-specific anyway, see the mess on arm (32)'s start_thread
<sorear>
it _also_ removes the easiest and most obvious way to access the kernel gp written in copy_thread but I don't think it's a complete fix
<sorear>
ptrace, /proc/*/task/*/syscall, and perf_event_open all allow accessing the pt_regs of a thread and can be used on a user_mode_thread without hitting a -EPERM
scrts has quit [Ping timeout: 246 seconds]
<sorear>
none of those three seem to be exploitable, for different and seemingly accidental reasons (I have test code that uses FUSE to engineer a race condition with coredump_pattern set to a pipe and successfully PTRACE_SEIZE a user_mode_helper prior to execve, but the process is in TASK_UNINTERRUPTABLE state and none of the ptrace subcommands do anything useful)