SecuMiKern
@SecuMiKern@sh.itjust.works
- Comment on Secure Operating Systems (Microkernels seems to be the future) 7 months ago:
While that’s true for mitigations, one system can be more secure than another by design
Things like an OS that’s designed with sandboxing, more clean codebase that’s auditable, permissions, … in mind is more secure than an OS that later adds them as an afterthought
MacOS and Windows’s security are objectively better than linux’s, the problem is they are not open source
- Comment on Secure Operating Systems (Microkernels seems to be the future) 7 months ago:
I meant Sony and Micorsoft were selling Playstation and Xbox at loss, profiting from games instead
Nintendo doesn’t seem to be selling their Hardware at loss so probably profits from hardware, actually considering their hardware (which is weaker than even midrange android phones) they probably sell at good profit margin
- Comment on Secure Operating Systems (Microkernels seems to be the future) 7 months ago:
I didn’t know Nintendo subsidize their hardware like Sony and Microsoft, as their hardware seemed overpriced to me for what they offer
And small percentage of gamers are on PC and even smaller percentage would emulate games, even without exclusives most casual gamers seem to prefer consoles so I think Nintendo is overreacting in that aspect though for pirating/jailbreaking switch devices themselves yeah maybe that’s why Nintedo care
- Comment on Secure Operating Systems (Microkernels seems to be the future) 7 months ago:
More info on Atmosphere as I find it fascinating that an OS created for a gaming device got such tight security:
reddit.com/…/mesosphere_opensource_nintendo_switc…
“It is a completely unique microkernel with a cooperative (non-preemptive) scheduler. The kernel is secure – so far as I can tell (as a reverse engineer and hacker), it has zero security bugs. They throw out years of backwards compatibility (they’re not POSIX/UNIX), and they really, really benefit from it from a security and modularity PoV. Horizon’s the only meaningful RTOS with a microkernel that I’m aware of (other than Fuschia). Everything’s in userland – filesystems, gpu (and other device drivers). The OS is capability-based and conceptually all about lots of different processes/drivers (“system modules”) that host microservices. The fact that Nintendo designed such a rock-solid, modular, custom operating system for their consoles fascinates me.”
“IPC is the hottest hot-path in a microkernel, correspondingly Nintendo marked every function involved in IPC as attribute((always_inline)), this was kind of a huge pain to reverse engineer as a result. In addition, Nintendo implemented “SvcReplyAndReceive” as a single system call that allows a microservice server process to reply to and receive a new message in one invocation. That said, there’s actually less overhead than you think. Past of why FUSE is slower than a kernel driver for FS is because FUSE has to talk to the kernel to do filesystem stuff, so when you read a file you have your process -> FUSE -> kernel -> hardware. In comparison, on Horizon the kernel is completely uninvolved in filesystem management (it doesn’t even have the sdmmc hardware mapped). Thus processes will do process -> FS system module process -> hardware.”
“In Horizon, everything is very distinctly not a file. There’s no global filesystem paths the way that unix/linux have special /dev/whatever. Pipes don’t exist in Horizon – all IPC is done via the horizon ipc (“HIPC”) protocol. UNIX/POSIX have stuff like fork() and child processes…but creating a process is an incredibly privileged operation in a capability-based operating system. Fork() is impossible to implement in Horizon, all threads are created via SvcCreateThread() instead. Child processes aren’t a thing that exist.”
- Submitted 7 months ago to privacyguides@lemmy.one | 14 comments