Hello, recently I've found the-sea-watcher project and now I'm trying to repeat it. https://scumjr.github.io/2016/01/10/from-smm-to-userland-in-a-few-bytes/ But I have a strange problem when I trigger a SMI my VM instantly reboot. I use that function to send SMI:
#define PORT_SMI_CMD 0x00b2 int main(void) { if (ioperm(PORT_SMI_CMD, 1, 1) != 0) err(EXIT_FAILURE, "ioperm"); outb(0x61, PORT_SMI_CMD); printf("done\n"); return EXIT_SUCCESS; }
I have rebuild SeaBios with CONFIG_DEBUG_LEVEL=8 and found out that SMI's reboot VM with a rather big chance. This is a part of SeaBios log:
VBE current mode=3 stub vbe_104fXX:406: a=00004f09 b=00000001 c=00000100 d=00000000 ds=0040 es=0000 ss=0100 si=00000000 di=00002000 bp=00000000 sp=00001000 cs=0000 ip=0600 f=3200 VBE mode set: c18f set VGA mode 18f //at this point Ubuntu is loaded handle_smi cmd=61 smbase=0x000a0000 //I send first handle_smi cmd=61 smbase=0x000a0000 //and second SMI In resume (status=0) //have reboot on third In 32bit resume Attempting a hard reboot enabling shadow ram SeaBIOS (version rel-1.13.0-15-gde88a96-dirty-20200406_111431-test-Lenovo-ideapad-320S-13IKB) BUILD: gcc: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 binutils: (GNU Binutils for Ubuntu) 2.30
I've started to explore the source code, but I don't found anything that could help me. Can you give me an advice or a direction for my research?
Best regards.
I continue ma research and now have proofs of that QEMU/Seabios behavior. I've connected gdb to QEMU and got memory dump of first MB. Then I've disassembled it, found address of handle_resume function and set a hardware breakpoint on it. Then I have generated some SMI's and stopped on the breakpoint. How it can be? Could some one help me?