CVS commit: [netbsd-8] src/sys/arch

["Soren Jacobsen" <snj%netbsd.org@localhost>]

Module Name:    src
Committed By:   snj
Date:           Mon Jan  1 19:09:04 UTC 2018

Modified Files:
        src/sys/arch/amd64/amd64 [netbsd-8]: machdep.c
        src/sys/arch/amd64/include [netbsd-8]: segments.h
        src/sys/arch/i386/i386 [netbsd-8]: machdep.c
        src/sys/arch/i386/include [netbsd-8]: segments.h
        src/sys/arch/x86/x86 [netbsd-8]: vm_machdep.c

Log Message:
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.


To generate a diff of this commit:
cvs rdiff -u -r1.255.6.2 -r1.255.6.3 src/sys/arch/amd64/amd64/machdep.c
cvs rdiff -u -r1.29 -r1.29.6.1 src/sys/arch/amd64/include/segments.h
cvs rdiff -u -r1.782.6.1 -r1.782.6.2 src/sys/arch/i386/i386/machdep.c
cvs rdiff -u -r1.59 -r1.59.6.1 src/sys/arch/i386/include/segments.h
cvs rdiff -u -r1.28 -r1.28.6.1 src/sys/arch/x86/x86/vm_machdep.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.