check that the subject has read/write access to the vnode using the
vnode MAC check.
MFC after: 3 weeks
Submitted by: Spencer Minear <spencer_minear at securecomputing dot com>
Obtained from: TrustedBSD Project
a link-layer multicast group membership.
Such memberships are needed in order to support protocols such as
IS-IS without putting the interface into PROMISC or ALLMULTI modes.
sa_equal() is not OK for comparing sockaddr_dl as it has deeper structure
than a simple byte array, so add sa_dl_equal() and use that instead.
Reviewed by: rwatson
Verified with: /usr/sbin/mtest
Bug found by: Jouke Witteveen
MFC after: 2 weeks
addition of SerDes support. According to the docs, the 5706C and 5708C
phys are supposed to use the same MII model that is separate from the
SerDes parts, but the 5706C actually uses the MII model of the SerDes
parts. To fix this, readd the old 5706C entry to miidevs and add a
special check in brgphy_probe() for phys that match the 5706C ID. If
the phy is supported by the gentbi(4) driver, then it's a SerDes phy, so
we fail the probe and let gentbi(4) grab it. Otherwise, it's a 5706C phy,
so we let brgphy(4) grab it.
In coordination with: dwhite
treated as multicast frames and filtered, but when only when "adopting"
running firmware. By "adopting", I mean using pre-existing firmware
loaded from eeprom at PCI reset, rather than firmware loaded by the
driver.
non consecutively numbered ports.
This should fix current SATA problems.
Support AHCI chips where the ports are not consecutively numbered as in
some incarnations of the ICH8 chip.
loaded into the system.
Change wording of comments to reflect the fact we should unconditionally
use KVM if the -M option is used to specify a core file.
Add comments to document the fact that IPv6 multicast forwarding
information display still relies on KVM for gathering information.
flash card reader.
Also remove an 'Opened da0 -> <random number>' which is not needed on a daily
basis (available through bootverbose).
Reviewed by: phk, ken
MFC after: 1 week
determine if this is a physical dir without an lstat().
While I'm in here, try to clarify the comments around
the _is_dir() and _is_physical_dir() tests.
first getting the current state with td_thr_getxmmregs_p. Without this,
debugging a threaded app that uses libthr resulted in kernel panics or
spurious SIGFPEs for me.
(As of revision 1.6, sys/i386/i386/ptrace_machdep.c masks off the
reserved bits in the mxcsr register, which prevents the kernel panics.)
Architectures without PT_GETXMMREGS are not affected.
MFC after: 1 week
and make it print under debug.iwi control same as other debugging stuff.
Remove the device_printf() in iwi_ioctl() and replace with this:
/*
* wait until pending iwi_cmd() are completed, to avoid races
* that could cause problems.
*/
while (sc->flags & IWI_FLAG_BUSY)
msleep(sc, &sc->sc_mtx, 0, "iwiioctl", hz);
This at least prevents what has become an almost systematic failure for my
system, presumably due to a previous iwi_cmd() not complete yet by the
time iwi_ioctl() is called.
It has been pointed to my attention that the real problem could be
calling ieee80211_ioctl() with the lock held. If that is true,
there might still be a possibility for a race condition e.g. an
interrupt coming while the ioctl is sleeping.
Need to investigate further on what changes are required to release
the lock before calling ieee80211_ioctl
+ do not release the dma-ble region used for downloading firmware.
This should fix the problems that some people were seeing, due to
memory becoming too fragmented which prevented subsequent allocations
of a suitable contiguous region of memory;
+ document the firmware format and usage in if_iwivar.h
+ use a loop to allocate the four tx rings, instead of replicating
the body of the loop.
+ add debugging code IWI_LOCK_ASSERT() to detect missing locks.
These only do a printf, and should go away once we figure out why
the driver sometimes freezes the system due to a (yet unidentified)
race condition.
+ add a device_printf() in iwi_ioctl() in certain conditions
(see comment in the code). This helps preventing the race condition
mentioned above, and makes the system survive. This printf will
also go away once fixing this bug is completed.
+ change iwi_getfw() to return 0 on success, 1 on error, consistently
with other functions.
+ fix the argument of a sizeof() in iwi_get_firmware()
+ use le32toh() to access little-endian fields
+ simplify error handling in iwi_load_firmware() and iwi_init_locked()
The bugs fixed by this commit (the freezing one especially) are serious
enough to call for a quick MFC
MFC after: 3 days
garbage collection complications from general discussion of UNIX domain
sockets.
Staticize unp_addsockcred().
Remove XXX comment regarding Giant and v_socket -- v_socket is protected
by the global UNIX domain socket lock.
System V shared memory, now believed fixed in sysv_shm.c:1.109:
date: 2006/11/06 13:42:01; author: rwatson; state: Exp; lines: +65 -37
Sweep kernel replacing suser(9) calls with priv(9) calls, assigning
specific privilege names to a broad range of privileges. These may
require some future tweaking.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
This restores fine-grained privilege support to System V IPC.
PR: 106078
ignored on other systems I investigated when accessing an existing
memory segment rather than creating a new one. This call to ipcperm()
is the only one to pass in a complete mode flag to the permission
checks rather than a simple access request mask, and caused problems
for the revised ipcperm() based on the priv(9) interface, which can
now be restored.
PR: 106078
VFS privilege namespace: exceedquota, getquota, and setquota. Leave
UFS-specific quota configuration privileges in the UFS name space.
This renumbers VFS and UFS privileges, so requires rebuilding modules
if you are using security policies aware of privilege identifiers.
This is likely no one at this point since none of the committed MAC
policies use the privilege checks.
