bieganski

have you considered forking existing OS and implementing changes that you needed instead?

it's hard for me to justify the tremendous effort of implementing the OS from scratch, instead of adding the functionality that you need to for example linux or xv6.

> (it) exposes primitives that let a single experiment switch privilege levels at runtime while executing the same instructions in the same address space.

why not just create a linux kernel driver that exposes svc/eret functionality via MMIO?

their costs are bound to compute anyway, they don't mind huge compensations also - it's not much of a cost saving to re-build, even cheaply, inhouse Slack or whatever?

"preventing firearms printing", aka "securing big companies' income from spare parts selling with 500% margin"

i wish there was an additional column in the table, that says "what problem does it solve". oh, and 'it's written in rust' does not count.

that's really cool. to gain traction i would start with reimplementing all the tools from https://github.com/iovisor/bcc/tree/master/libbpf-tools in PythonBPF.

it would be nice to have some peripheral drivers implemented (UART, eMMC etc).

having this, the next tempting step is to make `print` function work, then the filesystem wrapper etc.

btw - what i'm missing is a clear information of limitations. it's definitely not true that i can take any Python snippet and run it using PyXL (for example threads i suppose?)

> The available Linux debuggers are gdb and lldb. They both suck. They crash all the time, don't understand the data types I care about, and they don't make the data I need available at my fingertips as quickly as possible.

Okay, so this is the author's answer to the most important question: "why?"

For me this is a serious issue, making strong statements without any single backing example. If you experience crashes, please report to the maintainers - i guarantee that you won't be ignored. You say that it's missing some data that you need? Fine, but be precise - what data?

Otherwise it sounds like a "yeah, let's make a project for fun and pretend that it's serious by finding sort-of-justification/use case" (i'm not telling that it is the case for you - i'm telling that it sounds like it, based on your own description).

Also, would you feel nice if i put in my project's README a note that the project of you, the one that you put your effort to, "sucks"?

> while there's also a push to statically link everything

could you elaborate? who is pushing and what?

dynamic linking has it pitfalls, often it's a pain, but it has big big profits as well.

related url, for syscall intercepting made easy: https://github.com/bieganski/asstrace/

see `pathsubst` example.

unfortunately set of use cases for `ptrace`-based solution is limited, due to high performance overhead.

can someone explain to me, isn't it the kernel's responsibility to preempt the CPU-heavy userspace thread (noisy neighbour in our case) after fixed slice of time anyway?

sounds like an interesting direction, but I don't understand why should we have it coupled to specific tool (pwndbg)? Why not implement a BinaryNinja plugin to dump all user-defined names (function names, stack variables), together with an original (stripped) binary to the new ELF/.exe file, with symbol table and presumably with DWARF section?