CVS log for src/sys/arch/amd64/include/segments.h

Up to [cvs.NetBSD.org] / src / sys / arch / amd64 / include

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

sys/arch/amd64: remove trailing whitespace

Introduce per-cpu IDTs

This is realized by following modifications:
- Add IDT pages and its allocation maps for each cpu in "struct cpu_info"
- Load per-cpu IDTs at cpu_init_idt(struct cpu_info*)
- Copy the IDT entries for cpu0 to other CPUs at attach
   - These are, for example, exceptions, db, system calls, etc.

And, added a kernel option named PCPU_IDT to enable the feature.

Sync with HEAD

We reorganise definitions for XEN source support as follows:

XEN - common sources required for baseline XEN support.
XENPV - sources required for support of XEN in PV mode.
XENPVHVM - sources required for support for XEN in HVM mode.
XENPVH - sources required for support for XEN in PVH mode.

Ssync with HEAD

Make XEN use the same api as native, for idt vector allocation
and registration.

lidt() placed in xenfunc() on maxv@ suggestion.

There should be no functional change due to this commit.

Tested on amd64 native and XEN.

Pull up following revision(s) (requested by maxv in ticket #1517):
	sys/arch/amd64/amd64/machdep.c: 1.280 via patch
	sys/arch/amd64/include/segments.h: 1.34 via patch
	sys/arch/i386/i386/machdep.c: 1.800
	sys/arch/i386/include/segments.h: 1.64
	sys/arch/x86/x86/vm_machdep.c: 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.

Pull up following revision(s) (requested by maxv in ticket #1517):
	sys/arch/amd64/amd64/machdep.c: 1.280 via patch
	sys/arch/amd64/include/segments.h: 1.34 via patch
	sys/arch/i386/i386/machdep.c: 1.800
	sys/arch/i386/include/segments.h: 1.64
	sys/arch/x86/x86/vm_machdep.c: 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.

Pull up following revision(s) (requested by maxv in ticket #1517):
	sys/arch/amd64/amd64/machdep.c: 1.280 via patch
	sys/arch/amd64/include/segments.h: 1.34 via patch
	sys/arch/i386/i386/machdep.c: 1.800
	sys/arch/i386/include/segments.h: 1.64
	sys/arch/x86/x86/vm_machdep.c: 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.

Pull up following revision(s) (requested by maxv in ticket #1550):
	sys/arch/amd64/amd64/machdep.c: revision 1.280 via patch
	sys/arch/amd64/include/segments.h: revision 1.34 via patch
	sys/arch/i386/i386/machdep.c: revision 1.800 via patch
	sys/arch/i386/include/segments.h: revision 1.64 via patch
	sys/arch/x86/x86/vm_machdep.c: revision 1.30 via patch
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.

Pull up following revision(s) (requested by maxv in ticket #1550):
	sys/arch/amd64/amd64/machdep.c: revision 1.280 via patch
	sys/arch/amd64/include/segments.h: revision 1.34 via patch
	sys/arch/i386/i386/machdep.c: revision 1.800 via patch
	sys/arch/i386/include/segments.h: revision 1.64 via patch
	sys/arch/x86/x86/vm_machdep.c: revision 1.30 via patch
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.

Pull up following revision(s) (requested by maxv in ticket #1550):
	sys/arch/amd64/amd64/machdep.c: revision 1.280 via patch
	sys/arch/amd64/include/segments.h: revision 1.34 via patch
	sys/arch/i386/i386/machdep.c: revision 1.800 via patch
	sys/arch/i386/include/segments.h: revision 1.64 via patch
	sys/arch/x86/x86/vm_machdep.c: revision 1.30 via patch
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.

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.

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.

update from HEAD

In XEN PV, the idt vector table is not required to be altered at
runtime, since only entries for exceptions/traps are registered with
the hypervisor and interrupts are managed via a completely different
mechanism.

This change uses the idt_vec_reserve() mechanism nevertheless,
modifying it slightly to only do namespace management in XEN, while on
native it will continue to do idt entry init as before.

Rationale: Consistent API usage and potential future merging of
XEN/non-XEN code.

There are no functional changes in this commit.

Remove unused macros and LDT entries.

Use two separate functions: cpu_segregs32_zero and cpu_segregs64_zero. The
way segment registers work on amd64 will diverge between 32bit and 64bit
LWPs.

Remove the second argument from USERMODE and KERNELMODE, it is unused
now that we don't have vm86 anymore.

Sync with HEAD

Sync with HEAD

Sync with HEAD

Remove misleading comment; these macros should not be used if a user LDT
is active.

Sync with HEAD

Give the structure sizes.

Remove idt_init.

Rename this value, and use it.

KNF, and typo.

resync with head

sync with head

rearrange the LDT entries so that (32-bit) COMPAT_10 binaries work again.
in long mode, call gates use two slots, so the first entry (a call gate)
would overlap the second one (the 32-bit user code descriptor).

sync with head

memseg_baseaddr() is only called from valid_user_selector() and
both only locally.
Make static, remove one of the functions, and remove the never-set args.
Code is still very dubious.

Sync with HEAD.

bring matt-nb5-mips64 up to date with netbsd-5-1-RELEASE (except compat).

Sync with HEAD. TODO before merge:
- shortcut for suspend code in sysmon, when powerd(8) is not running.
Borrow ``xs_watch'' thread context?
- bug hunting in xbd + xennet resume. Rings are currently thrashed upon
resume, so current implementation force flush them on suspend. It's not
really needed.

sync with head

Sync with HEAD

move macros for validating fs/gs to segments.h and use them
in the linux32 code as well.

Sync with HEAD

Sync with HEAD (-D20101022).

sync with head

Pull up following revision(s) (requested by chs in ticket #1449):
	sys/arch/amd64/amd64/netbsd32_machdep.c: revisions 1.66, 1.67
	sys/arch/amd64/include/segments.h: revision 1.21
in check_mcontext32(), accept the LDT selector for 32-bit user code
as well as the GDT selector.  fixes PR 43835.
accept the LDT selector in check_sigcontext32() too.

Pull up following revision(s) (requested by chs in ticket #1449):
	sys/arch/amd64/amd64/netbsd32_machdep.c: revisions 1.66, 1.67
	sys/arch/amd64/include/segments.h: revision 1.21
in check_mcontext32(), accept the LDT selector for 32-bit user code
as well as the GDT selector.  fixes PR 43835.
accept the LDT selector in check_sigcontext32() too.

in check_mcontext32(), accept the LDT selector for 32-bit user code
as well as the GDT selector.  fixes PR 43835.

Sync with HEAD.

sync with head.

add the guts of TLS support on amd64.  based on joerg's patch,
reworked by me to support 32-bit processes as well.
we now keep %fs and %gs loaded with the user values
while in the kernel, which means we don't need to
reload them when returning to user mode.

sync with head.

Sync with HEAD.

Update haad-dm branch to haad-dm-base2.

put the contents of these header files around #ifdef __x86_64__, and
#include the <i386/foo.h> in the #else clause, making these files
largely bit-size independant.

Sync with HEAD.

sync with head.

idt_* are not implemented for Xen. So don't provide the prototypes for Xen.

use POSIX integer types

Sync with HEAD.

sync with head

sync with HEAD

Sync with HEAD

Sync with head.

- share idt entry allocation code among x86.
- introduce a function to reserve an idt entry and use it instead of
  manipulating idt_allocmap directly.
- rename idt to xen_idt for amd64 xen.  add missing #ifdef XEN.

Convert many of the uses of __attribute__ to equivalent
__packed, __unused and __dead macros from cdefs.h

Sync with HEAD.

sync with head

Sync with HEAD.

Sync with HEAD. amd64 Xen support needs testing.

Include opt_xen.h #ifdef _KERNEL_OPT instead of custom logic.
Thanks to Izumi Tsutsui for pointing me at _KERNEL_OPT

Fix bouyer-xenamd64 merge fallout:
we can #include "opt_xen.h" when
#if defined(_KERNEL) && !defined(_RUMPKERNEL) && !defined(_LKM),
#ifdef _KERNEL isn't enough.

only include opt_xen.h #ifdef _KERNEL

Pull up the bouyer-xenamd64 branch to HEAD. This brings in amd64 support
to NetBSD/Xen, both Dom0 and DomU.

sync with HEAD

sync with head.

Sync with HEAD.

Follow the merge of pmap.c on i386 and amd64 and move
pmap_init_tmp_pgtbl into arch/x86/x86/pmap.c. Modify the ACPI wakeup
code to restore CR4 before jumping back into kernel space as the large
page option might cover that.

Sync with HEAD.

Sync with head.

merge yamt-x86pmap branch.

- reduce differences between amd64 and i386.  notably, share pmap.c
  between them.  it makes several i386 pmap improvements available to
  amd64, including tlb shootdown reduction and bug fixes from Stephan Uphoff.
- implement deferred pmap switching for amd64.
- remove LARGEPAGES option.  always use large pages if available.
  also, make it work on amd64.

remove unused GDT_SYS_OFFSET.

amd64 (aka x86-64) support for Xen. Based on the OpenBSD port done by
Mathieu Ropert in 2006.
DomU-only for now. An INSTALL_XEN3_DOMU kernel with a ramdisk will boot to
sysinst if you're lucky. Often it panics because a runable LWP has
a NULL stack (really, it's all of l->l_addr which is has been zeroed out
while the process was on the queue !)
TODO:
- bug fixes :)
- Most of the xpq_* functions should be shared with xen/i386
- The xen/i386 assembly bootstrap code should be remplaced with the C
  version in xenamd64/amd64/xpmap.c
- see if a config(5) trick could allow to merge xenamd64 back to xen or amd64.

Merge the ppcoea-renovation branch to HEAD.

This branch was a major cleanup and rototill of many of the various OEA
cpu based PPC ports that focused on sharing as much code as possible
between the various ports to eliminate near-identical copies of files in
every tree.  Additionally there is a new PIC system that unifies the
interface to interrupt code for all different OEA ppc arches.  The work
for this branch was done by a variety of people, too long to list here.

TODO:
bebox still needs work to complete the transition to -renovation.
ofppc still needs a bunch of work, which I will be looking at.
ev64260 still needs to be renovated
amigappc was not attempted.

NOTES:
pmppc was removed as an arch, and moved to a evbppc target.

Sync with head.

sync with head.

Sync with HEAD

Sync with HEAD.

in VALID_USER_DSEL3() only check the low 16 bits.

this fixes 32bit gmake from occasionally reporting "Error 255" after
a command has successfully run.

lots of help from ad@ and joerg@.

sync with head.

sync with head

sync with head.

de __P()

merge ktrace-lwp.

Sync with HEAD. Here we go again...

Optionally include saving and restoring the 64bit %gs and %fs base register
values in the PCB. Do this in pmap_activate for now (XXX not a good place
for it, but a convenient one).

Fix the sync with head I botched.

Sync with HEAD.

Sync with HEAD

Uppercase CPU, plural is CPUs.

Define a few macros to validate userspace selectors.

Move UCB-licensed code from 4-clause to 3-clause licence.

Patches provided by Joel Baker in PR 22364, verified by myself.

Rename the x86_64 port to amd64, as this is the actual name used for
the processor family now. x86_64 is kept as the MACHINE_ARCH value,
since it's already widely used (by e.g. the toolchain, etc), and
by other operating systems.