Software interrupts and iretq

[Bipman]

Hi all

Now I've got 64 bit long mode working I am trying to set up software interrupts before I enable the hardware ones. The table seems to be working well but the issue seems to be when I use a software interrupt for example int 33, the iretq sends the kernel into somewhere it shouldn't. The registers before the iretq are

Code: Select all

	rax=0100043900000000 rbx=0000000000000000 rcx=0000000000000000 rdx=0000000000000000
	rsi=0000000040000010 rdi=0000000040001000 r8 =0000000000000000 r9 =0000000000000003
	r10=00000000000000f0 r11=000000000100002a r12=0000000000000000 r13=0000000000000000
	r14=0000000000000000 r15=0000000000000000 iopl=0 nv up di pl zr na po nc
	rip=000000000100046a rsp=0000000000ffff98 rbp=0000000000000000
	cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010                     rflags=00000046

The RSP before the interrupt is 0xffffc0. The stack looks like

Code: Select all

	%0000000000ffff98: 0000000001000437 0000000000000008
	%0000000000ffffa8: 0000000000000002 0000000000ffffc0
	%0000000000ffffb8: 0000000000000010 0000000000000000
	%0000000000ffffc8: 0000000000000000 0000000000000000

Which appears OK as the 0x1000437 is the correct return address. The code is

Code: Select all

int 33

	jmp $
	
	
	Default_Int:					;Default interrupt
	pushraxrdi						;pusha macro
	mov r8,0
	mov r9,3
	mov r11,PINT					;print 'Interrupt!'
	mov r10,0xf0
	call printc
	popraxrdi						;popa macro
	
	iretq

The ISR prints a message and then should return to the jmp $ line but instead returns to some other part of memory. I've read the articles and double checked the tables but everything looks OK. Any ideas?

Bipman

[LtG]

You said after the iretq it jumps to "somewhere in memory", where exactly? Did you try debugging (single stepping), what happens? The state you copied here, is it after the code returns from your popraxrdi but before the iretq? If not, that would likely be the most useful, single stepping makes it easy to capture the state at that point.

Is it possible that you cause some exception and don't have an exception handler?

[Bipman]

You said after the iretq it jumps to "somewhere in memory", where exactly? Did you try debugging (single stepping), what happens? The state you copied here, is it after the code returns from your popraxrdi but before the iretq? If not, that would likely be the most useful, single stepping makes it easy to capture the state at that point.

Is it possible that you cause some exception and don't have an exception handler?

You were right, it was another interrupt. I created a GPF handler plus system error handler and it was the GPF that fired. I'm now trying to find out what caused the GPF but not sure how I find out.

Bipman

[LtG]

You were right, it was another interrupt. I created a GPF handler plus system error handler and it was the GPF that fired. I'm now trying to find out what caused the GPF but not sure how I find out.
Bipman

Check the stack, what did the #GP push there? There should be CS:EIP for the instruction that caused the #GP as well as an error code, either it's zero or a segment selector.. You can disassemble your binary and check which instruction exactly caused the #GP. If you can't solve it, copy some of the disassembly with the contents of the stack (the #GP pushed error code and CS:EIP)..

From Wiki

General Protection Fault

A General Protection Fault may occur for various reasons. The most common are:

Segment error (privilege, type, limit, read/write rights).
Executing a privileged instruction while CPL != 0.
Writing a 1 in a reserved register field.
Referencing or accessing a null-descriptor.

The saved instruction pointer points to the instruction which caused the exception.

Error code: The General Protection Fault sets an error code, which is the segment selector index when the exception is segment related. Otherwise, 0.

Finally, I would recommend creating a single exception/interrupt handler that does nothing but print something like "unhandler interrupt/exception" and then halts and in the IDT put all the entries you have pointing to that. That way you always catch them and you'll know that something went wrong (ie. you didn't expect it). Later when you have the time just add valid exception handlers and leave the "generic" one handling the rest, hopefully at some point you have handlers for everything.

You might also want to improve on that a bit by making it print relevant regs, maybe the interrupt/exception number that occurred, possible error code, etc. If you don't print that stuff then everything that goes to the generic handler is indistinguishable, but even still at least you know something went wrong and can keep adding handlers one by one. Choice is yours =)

Note: I intentionally included interrupts and exceptions, I'm guessing quite a few have been bit early in their development by unintentionally enabling interrupts and then PIT or something else generates interrupt and everything just goes crazy for no apparent reason. Related to this last part it's worth remembering that until you re-map the PIC you have no (easy) way of knowing whether something is caused by an IRQ or exception as by default they overlap..

[Bipman]

Thanks, I'll give it a go. I re-mapped the PIC first and then enabled interrupts with the obvious outcome of faults everywhere so turned them off and went back to software interrupts first.

Bipman

[Bipman]

The GPF routine returned the IRETQ as the offending instruction which is a bit weird as I've tried with and without popping the error code just in case and it still causes a GPF even though the return address on the stack is correct. I'll keep looking .....

Bipman

[LtG]

What do you mean by "with and without popping the error code"? Can you elaborate it a bit?

Two things you could try is to either check your "pusha" and "popa" to see that they are proper or simply remove everything from your "Default_Int" except for iretq and see what happens.. single-stepping with debugger is quite useful.

Also can you provide disassembly of your binary? Just to make sure everything is as it should be, you can use objdump for that:
objdump -D -M intel kernel.bin
Obviously replace kernel.bin with the name of your file..

Can you also provide stack contents right when you enter the #GP (set breakpoint to it and dump stack with debugger)?

[Bipman]

I meant trying to take the error code off the stack before the iretq. I tried the iretq on it's own without the rest of the code for that routine and still got a GPF. I've attached the stack at entry to routine and also the code, the fun starts at line 82.

Bipman

[Bipman]

I've solved it now. It had to be something on the stack that was being popped that was causing the GPF. Turned out it was the SS register which I set to 0 and it worked which is strange. I thought as I was in 64 bit long mode that the segment registers did not matter? I know it puts the segment registers in in case you want to return to 32 bit mode but surely with an iretq it can tell?

Bipman

[iansjack]

As you have discovered, segment registers still have a role to play in long mode. Null selectors are not a good idea.

[Korona]

Null selectors are fine for everything except SS and CS. CS obviously needs to be loaded with a long mode segment. While SS base address and limit is ignored its privilege level is still checked.