Combuster wrote:No it can't. The sub-idt can only be modified from a kernel-mode process whose idt hasn't been remapped
The world minus you says any kernel task can. So obviously something is going wrong in your head.
How my kernel handles sub-idt's is entirely my choice, and I plan to design it in such a way that it doesn't give a damn whether the process is in kernel-mode or not, if you're using a sub-idt, you're not gonna remap it. There's no need to be so arrogant.
JamesM wrote:SoulofDeity wrote:I plan on encrypting all the kernel code with AES-256 to prevent that
As a sidenote, whenever someone says "I'll use encryption to solve that", the hairs on the back of my neck stand on end as I wonder exactly how much that person knows about attack vectors and making a secure system...
The closest anyone has every gotten to cracking the rijindael encryption was 'theoretically' reducing the encryption key by 2-bits. I'm not saying it's impossible, I mean if they wanted to they could simply dump the ram with some hardware gizmos and disassemble it, but if the kernel keeps shoving them into user mode and they can't make a kernel-mode binary without the keys, any software attacks would be futile.
bluemoon wrote:SoulofDeity wrote:If anyone can tell me a better way to hook the ISR's, I'd be grateful.
Think about how CPU handle interrupts.
1. lookup (cached) IDT
2. Getting CS:E/RIP, Stack/Task switch, etc (refer to manual)
3. Execute the code from the destination address
So, here are some choices:
1. flush IDT upon every context switch, which is impractically slow.
2. Remap the paged memory pointed by ISR with different region of physical memory.
If you are fine with additional lookup chain:
3. Give each process a dedicated kernel stack, so the ISR can de-reference some ID number on the stack and brach to different handlers
4. Abuse process's pid to lookup a table and do chaining.
However, doing long chain without EOI/IRET quickly may cause problems, then upon you improve it you may end up having a traditional signal/IPC mechanism for delayed handling of event, instead of inline handler.
Bottom line, this cannot boost performance as it either pollute cache or doing some overhead; and this provide no security enhancement over standard IPC model.
Thanks for actually posting a solution
1. kinda agree this would be slow
2. sounds decent, but it might be really messy to implement
I'm not entirely sure I understand 3 and 4 :/
------------------------------------------
I have a feeling I've confused everyone about this, so I'm gonna try to re-explain from the start:
Kernel processes can start other processes that have a custom interrupt table called the sub-idt. The actual sub-idt and it's functions are located in the memory space of the calling process so only the calling process can modify it. Whenever an interrupt is executed, the handler is looked up in the sub-idt and executed. The task-manager ensures that processes that use a sub-idt are always in user-mode before executing anything.
Security-wise, this means that process can't remap the real idt (or their own sub-idt without the calling process's permission), can't access kernel data, and the calling process can restrict their access to certain resources (such as using external libraries or reading/writing to certain files or ports).
Outside that, it also makes it possible to log all interrupts called by a process for debugging and improves the performance of virtualized processes by reducing load time, cutting down on memory use, and removing the need for them to be interpreted or dynamically recompiled.
Note that not ALL processes will be run using a sub-idt, it is merely used as a sandbox-environment or a way to simplify virtualizing software.
Honestly, that's the best I can explain it and I hope that clears up some confusion.
