sorear changed the topic of #riscv to: RISC-V instruction set architecture | | Logs: | Matrix:
naoki has joined #riscv
ntwk has quit [Ping timeout: 240 seconds]
ntwk has joined #riscv
DesRoin has quit [Ping timeout: 268 seconds]
DesRoin has joined #riscv
jacklsw has joined #riscv
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, was probably the most minimal well-supported one a couple years ago
Stat_headcrabed has joined #riscv
zjason` is now known as zjason
JanC_ has joined #riscv
JanC is now known as Guest5517
JanC_ is now known as JanC
Guest5517 has quit [Ping timeout: 264 seconds]
fuwei has joined #riscv
mlw has quit [Ping timeout: 260 seconds]
mlw has joined #riscv
handsome_feng has quit [Quit: Connection closed for inactivity]
coaden has joined #riscv
crossdev has quit [Remote host closed the connection]
khem has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
Leopold has quit [Ping timeout: 260 seconds]
Leopold has joined #riscv
sakman has quit [Ping timeout: 272 seconds]
smaeul has quit [Ping timeout: 260 seconds]
<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 ( (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.
fuwei has quit [Ping timeout: 256 seconds]
fuwei has joined #riscv
junaid_ has joined #riscv
junaid_ has quit [Client Quit]
junaid_ has joined #riscv
eightthree has joined #riscv
scrts has quit [Quit: The Lounge -]
scrts has joined #riscv
<smaeul> sorear: re: arch/riscv/kernel/process.c#n210, yes, they do something. they cause `user_mode(task_pt_regs(task))` to fail for kernel threads.
<smaeul> leaking the kernel GP to userspace is pretty bad... we should probably be clearing it in start_thread()
___nick___ has joined #riscv
___nick___ has joined #riscv
junaid_ has quit [Quit: Lost terminal]
davidlt has quit [Ping timeout: 252 seconds]
jljusten has quit [Read error: Connection reset by peer]
ncopa5 has quit [Changing host]
ncopa5 has joined #riscv
mlw has quit [Ping timeout: 246 seconds]
jljusten has joined #riscv
crossdev has joined #riscv
erg_ has joined #riscv
crossdev has quit [Ping timeout: 268 seconds]
___nick___ has quit [Ping timeout: 256 seconds]
<sorear> smaeul: where is that condition used? possibly related question, how are pt_regs managed under PREEMPT=y?
psydroid has quit [Quit: KVIrc 5.0.0 Aria]
JanC_ has joined #riscv
JanC has quit [Killed ( (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)
scrts has joined #riscv
OwlWizard has quit [Quit: OwlWizard]