No, I don't. For the same reason you trust yours, I distrust mine: I wrote it. I trust this thing to run inside of an emulator, and maybe on real hardware that I own, but I would not wish that thing on anyone who is not myself. Testing is important and does reveal flaws. However, due to the problem of combinatorial explosions, it is practically impossible to test all combinations of decisions and conditions that might occur in any program of any real complexity. Therefore I rely on ongoing runtime detection of problems, vulgo CPU exceptions. And otherwise on reading code to find bugs. But of course, I keep missing stuff, given that I am cursed with that imperfect pound of grey matter between my ears, that gets constantly distracted.bzt wrote:Only if you're a noob programmer. I know for sure that my kernel is working okay, because it is I who wrote it, and I made lots of tests and run-time checks. Are you suggesting that you don't trust your own code?
That is the custom, yes. Of course, only after collecting all debug info I could think of, in order to aid me in discovering the cause of the flaw and to correct it. I'm well aware that I'm not exactly writing Minix.bzt wrote:And how do you plan to recover from a kernel panic? Let me guess, by rebooting the entire computer?
Unless it was null pointer access with offset (e.g. array or structure access through a pointer, and the pointer was null). And even so, I know many applications where that is really not better than rebooting. Embedded applications often have a small number of processes, but those are really important, and if any of those is killed, the machine ceases to function. A reboot would also cause a break in functionality, but only for a limited time. And in many cases, simply restarting the killed application without a reboot would also not work.bzt wrote:...which will detected as the TCB starts with a magic. It doesn't happen, but even in the unlikely event if it does, my kernel is capable to handle that gracefully, kill the clobbered process (and only that one).
Well, point a) really means that x86 is just fundamentally insecure. However, I think I can patch that: If I detect a GPF in userspace while IP is pointing to a SWAPGS instruction, I can just flush all caches. So no speculative cache timing attack there, because when the "privileged opcode" handler runs, absolutely nothing will be in cache. Is what I imagine, anyway. The use of SWAPGS is all but mandatory if kernel address space is fixed, multiple CPUs are supported, and SYSCALL is the system call method of choice. In that case the syscall handler will be entered with SP pointing to the user stack, and saving things in global variables is going to be a problem due to the multiple CPUs. Of course, if you put the TCB (or the CPU-local structure, now that I think about it) at a fixed virtual address and keep swapping that out, that problem is fixed. And for that it doesn't even matter what that fixed address is (so 0 works as well as any other free address). It's just harder conceptually (because now I can't share any pointers into that memory area with any other context, which is a restriction not placed on any other kernel address).bzt wrote:That way you must use SWAPGS, which is a) known to be vulnerable to attacks, b) using segmentation makes your kernel unportable.
As for point b), well it would if I wasn't using %gs (or rather, GS.Base) merely as a register holding a pointer. Every other architecture has a thread pointer register I can use (PowerPC has R2, Microblaze has R21, ...), the x86 version is merely unbelievably awkward to use.
I am experienced, that is why I know a bit about what I can and cannot do. I can slap together a kernel that won't crash if you look at it wrong. I cannot write bug-free software. That grey matter getting in the way again.bzt wrote:I would recommend to write your kernel properly instead, so that it can't have NULL pointer dereferences in the first place. You can't guarantee that all applications are written correctly, but you can guarantee at least that the kernel that you wrote is free of NULL dereferences. It shouldn't be a problem for an experienced programmer to write correct code. That's why they are called "experienced".
Also, your claim of being able to write correct code would be a lot more convincing if this thread did not exist. Everyone makes mistakes, and I don't trust myself to find all of them before they blow up in my face.
Nothing. Sometimes conversations evolve and go off-topic. In this case from memory copy via Linus Torvalds' design philosophy to this.nexos wrote:What does TCBs have to do with moving blocks of data?
Nobody is perfect, making bug tolerant software is a prudent and intelligent decision no matter how experienced you are.