[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-port-xen
Subject:    xen: easy DoS... tiring
From:       Maxime Villard <max () m00nbsd ! net>
Date:       2017-10-14 12:10:10
Message-ID: 6f57d720-0029-b643-ad3d-c631657f4c16 () m00nbsd ! net
[Download RAW message or body]

An issue I found some time ago: xen_failsafe_handler panics, but the
interrupt it is called from can be triggered by userland.

For example, userland can make iretq fault by changing the %eip of a traced
32bit process, and making it point to > VM_MAXUSER_ADDRESS32. Xen then
jumps into failsafe_callback, which calls xen_failsafe_handler. See [1]:

	$ gcc -m32 child32 child32.c
	$ gcc -o ptrace ptrace.c
	$ ./child32 &
	$ ./ptrace pid_of_child32
	-> panic

I tried to fix it, by returning into the original context but in resume_iret
that would reconstruct the frame and call trap with T_PROTFLT. But I remember
that it produced some bizarre behavior that I didn't understand, and it was
too tiring to reverse engineer the undocumented xen code.

I'm posting this here with the hope someone interested enough can fix it...

Maxime

[1] http://m00nbsd.net/garbage/xen/
[prev in list] [next in list] [prev in thread] [next in thread]