| Age | Commit message (Collapse) | Author |
|---|
|
cause the serial console to hang.
ok jason@
|
|
|
|
|
|
stack protection when building kernels. Intended to be used on installation
media, with tight space constraints - currently, only added where
SMALL_KERNEL was already defined.
Not thoroughly tested, but requested by deraadt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
it's now possible to tag packets with an arbitary tag and filter based on
that tag later on other interfaces:
pass in quick on fxp0 keep state tag blah
pass out quick on wi0 keep state with tag blah
can be used to express trust between interfaces, to distinguish between
NATed connections and connection originating from teh firewall itself
and much more
ok dhartmei@ frantzen@ pb@ mcbride@
|
|
ok hin@
|
|
This is at least necessary for the sparc microtime() function, and was
only working before by goat luck. The recent commons removal triggered it.
__atribute__ syntax borrowed from NetBSD.
|
|
millert@ ok
|
|
|
|
separate step, since it's built with crunch (from Pedro Bastos)
- whitespace at EOL
ok deraadt@ marc@
|
|
blinded you to the fact you were breaking ALL of our install media!
|
|
those tags later on.
ok dhartmei@ pb@ mcbride@ frantzen@
|
|
|
|
configuration lines.
|
|
- add license (/me wrote it)
ok jmc@
|
|
dp->d_namlen == 0. Shouldn't be possible but the check prevents
any possibilty of using an array index of -1.
|
|
non-thread-safe dl functions. Only enabled for ELF architectures
at this time as needed dlxxx support has not yet been added to the
a.out run time loader.
'doesn't break xmms at least' tedu@. Tested by others with no comment
|
|
|
|
|
|
http://www.caldera.com/developers/gabi/2000-07-17/ch4.eheader.html
EI_BRAND is gone, we now have EI_OSABI and EI_ABIVERSION
Add ELFOSABI_* defines that correspond to what binutils uses. Note
that we don't currently set e_ident[EI_OSABI] to ELFOSABI_OPENBSD,
though we probably should.
|
|
|
|
file operations.
|
|
to some developers, but include files are not just used by the kernel.
there are applications that pull them in as well. this change broke
tcpdump, and who knows what else. i've been talking for 24 hours now
about tree breakage and let this be official: I am prepared to lock the
tree entirely if need be. YOU WILL GET OK PERMISSION FROM EVERYONE, NOT
JUST FROM ONE PERSON
|
|
markus ok
|
|
ok deraadt@
|
|
some style input itojun@ tdeval@ toby@
tested, mostly by deraadt, on i386, macppc, vax, sparc64
ok deraadt@ miod@
|
|
bad. suggested by deraadt and naddy
|
|
(FDDI, ieee1394, ...). follows netbsd practice.
2 jasons, dhartmei, thierry ok
|
|
|
|
|
|
|
|
|
|
correct. It breaks down if we're trying to jump through a function
pointer. The protection fault trap on i386 must be one of the most
braindead traps ever invented in the history of humankind. It doesn't
give you any information about what went wrong except the instruction
that faulted. Since the problem we're trying to deal with is a
segmentation problem, we don't get the desitination that we want to
jump to, we just get the instruction and we won't add a disassembler
to trap handling just to try to figure out what went wrong.
What we want to do is to handle this as a normal fault to let noexec
accounting in pmap_enter deal with the changes to the code
segment. Unfortunately that's impossible. We don't know the faulting
address, so we need to change how the exec accounting works. Basically
the code segment must already cover the address we want to execute
before we can fault it in.
New scheme:
o Start with conservative code segment.
o If we get a protection fault, go through all mappings in the process
and find the highest executable mapping, fix up the code segment and
record that address. If the code segment didn't change, the protection
fault wasn't fixable - just die.
o If the highest executable mapping is removed, just reset the code
segment to something conservative and let the next protection fault
deal with it. We can't read all the vm mappings of the process from
the pmap because of locking hell.
This should allow floating code segment whenever someone implements that.
Also, fix the pmap_protect function to behave more like the other
pmaps we have and be slightly more agressive to force more proper
protection changes.
ok:ed by various people.
|
|
Noticed by mho@ and drahn@
|
|
|
|
|
|
|
|
|
|
|
|
(from KIU Shueng Chuan)
ok dhartmei
|
|
|
|
|
|
|
