How do I access the process' vector table in linux?

[jaunty inlet]

It should be on some accessible memory address, 0x0 is not mapped in my process.
Can sigaction somehow reveal the raw address?

[humble gyro]

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.

[honest sapphire]

Just to clarify, what do you mean by vector table?

[jaunty inlet]

the interrupt vector table, a fixed length array of 256 void* pointers, the first one of them being the divide-by-zero function pointer handler

[honest sapphire]

Oh that. I'm 99% sure that there is just the one interupt table for the CPU as a whole. An individual process doesn't have an interupt vector table

[jaunty inlet]

when I tried to run gdb and track divide by zero, instruction by instruction, I don't see any function calls to the handler

maybe userland processes can't see the magic

[honest sapphire]

That's because interupt handlers are run by the kernel in kernel mode. GDB wouldn't see what happens

[jaunty inlet]

so... if I forcefully edit the bootloader GRUB, and make it divide by zero, and track that thing with gdb, it will teleport to the dividebyzero handler?

in theory

[honest sapphire]

I mean, if you want to debug Linux itself... Maybe?
I'm not sure you can debug the kernel that is running the debugger though???
You might need to debug using a VM

[jaunty inlet]

linux is loaded after grub, grub is in charge of preparing... things,
my point is that,
if some random ass pointer bug ends up forcefully overwriting a snippet of the interrupt vector table, we need sanity checks / debug log prints showing the raw contents of that array at the start of grub, and at the end right before linux gets loaded

and thus we can see, ohhhhhhhhhh, so that's why the interrupt handler refuses to run what it should

but my skill is too weak, I need to read thousands of pages of docs first, and maybe follow the linux-from-scratch guide

[honest sapphire]

I mean, at that point just build your own Linux :P

[jaunty inlet]

I will leave the thread open to see what others comment

[potent flax]

The IVT is kernelspace, not userspace. I think in DOS you could access the IVT.

The signal handler won't help you reverse engineer it back to kernelspace im afraid

I would be surprised if Linux has some kind of API that shows the IVT

But why not read the source of the kernel? Im not too sure what you are trying to do

[jaunty inlet]

yes I forgor, the signal handlers are very very different from the interrupt handlers

[jaunty inlet]

I am not skilled enough for that
maybe one day

[potent flax]

they are related. you just cant context switch with gdb

[potent flax]

I would recommend BSD instead of Linux. Linux codebase is a mess

[jaunty inlet]

well... gdb is a wrapper around ptrace, ptrace is accessing all of the raw memory pages of the targeted debugged userland process

if there are no visible pages, then gdb can't access anything

[jaunty inlet]

how does BSD help, what do you mean

[jaunty inlet]

ohhhhhhh, yes, gdb can't trace the raw implementation of a system call, it can only show the system call return value in the userland process, of course

[potent flax]

I meant that if you are interested generally in OSDev, Linux is a tough read, BSD is less so. They do deviate, but the main ideas (how IVT is generally handled) doesnt change

[jaunty inlet]

oke, I will keep that in mind
thank you kind stranger ⭐

[potent flax]

anytime :)

[jaunty inlet]

wait... the x86 division instruction, that's not a system call, I am just, asking the cpu to do arithmetic, why are you telling me there is a context switch hidden in there?

the CPU raised a hardware exception, and eventually the OS decided to send SIGFPE to the process I have, gdb shows me the signal we received

[honest sapphire]

The division itself doesn't context switch, the division by zero causes an interupt, and all interrupts context switch

[jaunty inlet]

aaaaaaaaaaaaaaaaaa

oke

!solved

[humble gyro]

Thank you and let us know if you have any more questions!

This thread is now set to auto-hide after an hour of inactivity

[jaunty inlet]

bye guys 👋

[dark flint]

fyi this is a video that talks a bit about what happens when an interrupt happens

this guy in general is pretty nice

power point guy

[honest sapphire]

I was also thinking of that video, XD

[jaunty inlet]

kay so,
userland processess cannot read and cannot write in the table, otherwise every userland process would be able to hack the entire OS, each interrupt, like interrupt 0x80, has a special function pointer that says "when interupt number N happens, go jump here and run that thing"

[dark flint]

when an interrupt happens you jump to a special place in memory where the kernel will handle the interrupt, exactly

[jaunty inlet]

and all interrupts run in priviledged mode, all the CPU instructions for hardware accessing are available

[dark flint]

that is why an interrupt is called an interrupt

[jaunty inlet]

once upon a time in old OS-es without system calls, we would run raw interrupts via the instruction int, all the time

[dark flint]

they interrupt the program by invoking the kernel to handle stuff

[jaunty inlet]

ye

[jaunty inlet]

buuuuut, the software that loads the OS itself, the first stage bootloader like GRUB, does run in priviledged mode,
so, now the question is, when in priviledged mode, how do we rip the vector interrupt table out of the RAM?

[dark flint]

im not going to lie you do so much mischief with computers that i cant really follow