having a tough time explaining people that no, even if there's a component referred to as a "driver" inside, a piece of userspace software can not ultimately be at fault for a kernel panic
-
-
Replying to @11rcombs
Now I feel compelled to try and prove that wrong somehow. Though all the obvious ideas start with mmap /dev/kmem...
1 reply 0 retweets 0 likes -
Replying to @pikhq
yeah, that's a potential caveat, but you'd pretty much have to be deliberately trying to fuck shit up
1 reply 0 retweets 0 likes -
I _have_ fucked shit up by mapping /dev/kmem (on an RPi), but at that point I was getting exactly what I was asking for
1 reply 0 retweets 0 likes -
/dev/mem too. Also, say hi to iopl(2). Then there's kexec. You can also make PID 1 exit with various shenanigans. Or just load a broken kernel module.
1 reply 0 retweets 1 like -
yeah, if you really try you can come up with all sorts of ways to do it, sure here, the issue is "the machine reboots", so you could just straight-up write 'b' to /proc/sysrq-trigger if you had the right perms
2 replies 0 retweets 0 likes
Admittedly if you do any of those you're definitely getting exactly what you asked for. Didn't stop me from writing a userspace device tool that sets up DMA to a hugepage mapped from userspace though. Sadly, not IOMMU-compatible.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.