Re: Randomization from the bootblocks

2013-12-28 Thread Theo de Raadt
> At least i386, amd64, macppc, sparc64, hppa, and loongson > are supported. Hopefully the others are not far behind. Oh someone will ask how to verify this is working correctly. Well, you can't really tell. The following kernel diff will let you know that the propolice cookie has come from dat

i386 switched to PIE

2013-12-28 Thread Theo de Raadt
The i386 architecture has now been switched to PIE. There is a small performance hit, but this part of ASLR is valuable combined with W^X and the stack protector. This is a non-trivial upgrade, so please be careful. Check the FAQ for details or use a snapshot.

Randomization from the bootblocks

2013-12-28 Thread Theo de Raadt
Over the holidays I've written code to do something we've talked about for a long time but never gotten around to. The bootblocks are now capable of providing entropy to the kernel very early on. This requires an upgrade of the bootblocks and at least /etc/rc (which saves an entropy file for futu

Re: Alter daemon scheduling priority with renice for rc.d

2013-12-28 Thread sven falempin
On Sat, Dec 28, 2013 at 6:23 PM, Craig R. Skinner wrote: > On 2013-12-28 Sat 21:16 PM |, Craig R. Skinner wrote: > > On 2013-12-19 Thu 13:43 PM |, Craig R. Skinner wrote: > > > Enhance rc.d/rc.subr with lowered/raised daemon running priority. > > > > > > > Take 2: > > > > Replace /etc/rc.d/ rc_ren

Re: Alter daemon scheduling priority with renice for rc.d

2013-12-28 Thread Craig R. Skinner
On 2013-12-28 Sat 15:13 PM |, Theo de Raadt wrote: > > > Enhance rc.d/rc.subr with lowered/raised daemon running priority. > > You still have done nothing to prove the case for this extra > complexity. > When I managed customer's dedicated servers, it would have been useful, for example, to have

Re: Alter daemon scheduling priority with renice for rc.d

2013-12-28 Thread Craig R. Skinner
On 2013-12-28 Sat 21:16 PM |, Craig R. Skinner wrote: > On 2013-12-19 Thu 13:43 PM |, Craig R. Skinner wrote: > > Enhance rc.d/rc.subr with lowered/raised daemon running priority. > > > > Take 2: > > Replace /etc/rc.d/ rc_renice=X with > /etc/rc.conf.local _nice=X > Take 3 - simplify: Use nic

Re: rgephy(4): Always use RL_GMEDIASTAT for reading link/media status for re(4) PHY

2013-12-28 Thread Theo de Raadt
> > This moves rgephy(4) back to using RL_GMEDIASTAT to read the link/media > > status for re(4) attached Realtek PHY as was done before rev 1.25. rev > > 1.25 was to add support for external rgephy(4) attached to other MAC > > such as nfe(4), but the PHY Specific Status register doesn't seem to >

Re: Alter daemon scheduling priority with renice for rc.d

2013-12-28 Thread Theo de Raadt
> > Enhance rc.d/rc.subr with lowered/raised daemon running priority. You still have done nothing to prove the case for this extra complexity. It's a custom thing you need, and noone else needs it.

Re: more predictable package installations

2013-12-28 Thread Vadim Zhukov
2013/12/29 Mark Kettenis : >> Date: Sat, 28 Dec 2013 22:37:52 +0100 >> From: Marc Espie >> Reply-To: es...@nerim.net >> >> I'm thinking I'd like to impose a PATH for running @exec/@unexec >> style lines in packing-lists. >> >> Some people have their default path ignoring /usr/local, which is just

Re: more predictable package installations

2013-12-28 Thread Mark Kettenis
> Date: Sat, 28 Dec 2013 22:37:52 +0100 > From: Marc Espie > Reply-To: es...@nerim.net > > I'm thinking I'd like to impose a PATH for running @exec/@unexec > style lines in packing-lists. > > Some people have their default path ignoring /usr/local, which is just > fine, but the packages expect t

Re: more predictable package installations

2013-12-28 Thread Philip Guenther
On Saturday, December 28, 2013, Marc Espie wrote: > I'm thinking I'd like to impose a PATH for running @exec/@unexec > style lines in packing-lists. ... > setting PATH explicitly to > > /bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:${LOCALBASE}/bin:${LOCALBASE}/sbin > before running @exec/@unexec

more predictable package installations

2013-12-28 Thread Marc Espie
I'm thinking I'd like to impose a PATH for running @exec/@unexec style lines in packing-lists. Some people have their default path ignoring /usr/local, which is just fine, but the packages expect things to run in a "correct" way, so currently any local command requires /usr/local/bin/cmd to be run

Re: Alter daemon scheduling priority with renice for rc.d

2013-12-28 Thread Ingo Schwarze
Hi, Craig R. Skinner wrote on Sat, Dec 28, 2013 at 09:16:23PM +: > On 2013-12-19 Thu 13:43 PM |, Craig R. Skinner wrote: >> Enhance rc.d/rc.subr with lowered/raised daemon running priority. > Replace /etc/rc.d/ rc_renice=X with > /etc/rc.conf.local _nice=X I'd hate this, or anything similar,

Re: Alter daemon scheduling priority with renice for rc.d

2013-12-28 Thread Craig R. Skinner
On 2013-12-19 Thu 13:43 PM |, Craig R. Skinner wrote: > Enhance rc.d/rc.subr with lowered/raised daemon running priority. > Take 2: Replace /etc/rc.d/ rc_renice=X with /etc/rc.conf.local _nice=X $ fgrep _nice /etc/rc.conf.local sshd_nice=-10 dhcpd_nice=15 inetd_nice=YES greyscanner_nice=YES

Re: rgephy(4): Always use RL_GMEDIASTAT for reading link/media status for re(4) PHY

2013-12-28 Thread Mark Kettenis
> Date: Sat, 28 Dec 2013 15:42:12 -0500 > From: Brad Smith > > This moves rgephy(4) back to using RL_GMEDIASTAT to read the link/media > status for re(4) attached Realtek PHY as was done before rev 1.25. rev > 1.25 was to add support for external rgephy(4) attached to other MAC > such as nfe(4),

rgephy(4): Always use RL_GMEDIASTAT for reading link/media status for re(4) PHY

2013-12-28 Thread Brad Smith
This moves rgephy(4) back to using RL_GMEDIASTAT to read the link/media status for re(4) attached Realtek PHY as was done before rev 1.25. rev 1.25 was to add support for external rgephy(4) attached to other MAC such as nfe(4), but the PHY Specific Status register doesn't seem to work properly with

Re: PATCH: fix bug in handling genmask

2013-12-28 Thread Kieran Devlin
maybe, one problem at a time? first, whether there is actually a bug there, this patch fix it? and then this removing genmask discussion as i understand, unless you guys had already reached a conclusion once, there might be no immediate result and as blambert@ mentioned, whether it is really a b

Re: PATCH: fix bug in handling genmask

2013-12-28 Thread Bret Lambert
IIRC, I'd talked to both claudio and sthen about removing genmask, as it's unused and slightly nonsensical. Maybe we should just do it, if there are actual bugs lurking therein? On Sat, Dec 28, 2013 at 03:57:04AM +0800, Kieran Devlin wrote: > re-send this patch, loop in claudio@ > > maybe someone