Now
netbsd-8 commitmail json YAML
src/sys/arch/amd64/amd64/machdep.c@1.255.6.3
/
diff
/
nxr@1.255.6.3
src/sys/arch/amd64/include/segments.h@1.29.6.1 / diff / nxr@1.29.6.1
src/sys/arch/i386/i386/machdep.c@1.782.6.2 / diff / nxr@1.782.6.2
src/sys/arch/i386/include/segments.h@1.59.6.1 / diff / nxr@1.59.6.1
src/sys/arch/x86/x86/vm_machdep.c@1.28.6.1 / diff / nxr@1.28.6.1
src/sys/arch/amd64/include/segments.h@1.29.6.1 / diff / nxr@1.29.6.1
src/sys/arch/i386/i386/machdep.c@1.782.6.2 / diff / nxr@1.782.6.2
src/sys/arch/i386/include/segments.h@1.59.6.1 / diff / nxr@1.59.6.1
src/sys/arch/x86/x86/vm_machdep.c@1.28.6.1 / diff / nxr@1.28.6.1
Pull up following revision(s) (requested by maxv in ticket #477):
sys/arch/amd64/amd64/machdep.c: revision 1.280
sys/arch/amd64/include/segments.h: revision 1.34
sys/arch/i386/i386/machdep.c: revision 1.800
sys/arch/i386/include/segments.h: revision 1.64 via patch
sys/arch/x86/x86/vm_machdep.c: revision 1.30
Fix a huge privilege separation vulnerability in Xen-amd64.
On amd64 the kernel runs in ring3, like userland, and therefore SEL_KPL
equals SEL_UPL. While Xen can make a distinction between usermode and
kernelmode in %cs, it can't when it comes to iopl. Since we set SEL_KPL
in iopl, Xen sees SEL_UPL, and allows (unprivileged) userland processes
to read and write to the CPU ports.
It is easy, then, to completely escalate privileges; by reprogramming the
PIC, by reading the ATA disks, by intercepting the keyboard interrupts
(keylogger), etc.
Declare IOPL_KPL, set to 1 on Xen-amd64, which allows the kernel to use
the ports but not userland. I didn't test this change on i386, but it
seems fine enough.
sys/arch/amd64/amd64/machdep.c: revision 1.280
sys/arch/amd64/include/segments.h: revision 1.34
sys/arch/i386/i386/machdep.c: revision 1.800
sys/arch/i386/include/segments.h: revision 1.64 via patch
sys/arch/x86/x86/vm_machdep.c: revision 1.30
Fix a huge privilege separation vulnerability in Xen-amd64.
On amd64 the kernel runs in ring3, like userland, and therefore SEL_KPL
equals SEL_UPL. While Xen can make a distinction between usermode and
kernelmode in %cs, it can't when it comes to iopl. Since we set SEL_KPL
in iopl, Xen sees SEL_UPL, and allows (unprivileged) userland processes
to read and write to the CPU ports.
It is easy, then, to completely escalate privileges; by reprogramming the
PIC, by reading the ATA disks, by intercepting the keyboard interrupts
(keylogger), etc.
Declare IOPL_KPL, set to 1 on Xen-amd64, which allows the kernel to use
the ports but not userland. I didn't test this change on i386, but it
seems fine enough.