Re: PATCH: fix bug in handling genmask
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 could verify commit this patch
a. fix a bug
b. get rid of junk in ?mask_rnhead'
c. forbid unprivileged user to insert mask into ?mask_rnhead'
bug is in this line
Bcmp((caddr_t *)genmask + 1, (caddr_t *)t-rn_key + 1, ((struct
sockaddr *)t-rn_key)-sa_len)
to make this right, at least, it should look like this
Bcmp((caddr_t)genmask + 1, (caddr_t)t-rn_key + 1, ((struct sockaddr
*)t-rn_key)-sa_len - 1)
after doing this, the whole checking seems completely unnecessary, is
expected result from ?rn_addmask?.
Index: net/rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.131
diff -p -u -r1.131 rtsock.c
--- net/rtsock.c 1 Nov 2013 20:09:14 - 1.131
+++ net/rtsock.c 27 Dec 2013 14:08:44 -
@@ -593,18 +593,22 @@ route_output(struct mbuf *m, ...)
error = EINVAL;
goto flush;
}
- if (genmask) {
- struct radix_node *t;
- t = rn_addmask(genmask, 0, 1);
- if (t genmask-sa_len =
- ((struct sockaddr *)t-rn_key)-sa_len
- Bcmp((caddr_t *)genmask + 1, (caddr_t *)t-rn_key + 1,
- ((struct sockaddr *)t-rn_key)-sa_len) - 1)
- genmask = (struct sockaddr *)(t-rn_key);
- else {
+ if (genmask rtm-rtm_type != RTM_GET) {
+ if (!(rnh = rt_gettable(dst-sa_family, tableid))) {
+ error = EINVAL;
+ goto flush;
+ }
+ if (!(rn = rn_addmask(genmask, 0, rnh-rnh_treetop-rn_off))) {
error = ENOBUFS;
goto flush;
}
+ if (!((struct sockaddr *)rn-rn_key)-sa_len) {
+ error = EINVAL;
+ goto flush;
+ }
+ genmask = (struct sockaddr *)rn-rn_key;
+ } else {
+ genmask = NULL;
}
#ifdef MPLS
info.rti_mpls = rtm-rtm_mpls;
Re: PATCH: fix bug in handling genmask
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 bug might matter
Kieran
On Dec 28, 2013, at 5:19 PM, Bret Lambert blamb...@openbsd.org wrote:
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 could verify commit this patch
a. fix a bug
b. get rid of junk in ?mask_rnhead'
c. forbid unprivileged user to insert mask into ?mask_rnhead'
bug is in this line
Bcmp((caddr_t *)genmask + 1, (caddr_t *)t-rn_key + 1, ((struct
sockaddr *)t-rn_key)-sa_len)
to make this right, at least, it should look like this
Bcmp((caddr_t)genmask + 1, (caddr_t)t-rn_key + 1, ((struct sockaddr
*)t-rn_key)-sa_len - 1)
after doing this, the whole checking seems completely unnecessary, is
expected result from ?rn_addmask?.
Index: net/rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.131
diff -p -u -r1.131 rtsock.c
--- net/rtsock.c 1 Nov 2013 20:09:14 - 1.131
+++ net/rtsock.c 27 Dec 2013 14:08:44 -
@@ -593,18 +593,22 @@ route_output(struct mbuf *m, ...)
error = EINVAL;
goto flush;
}
-if (genmask) {
-struct radix_node *t;
-t = rn_addmask(genmask, 0, 1);
-if (t genmask-sa_len =
-((struct sockaddr *)t-rn_key)-sa_len
-Bcmp((caddr_t *)genmask + 1, (caddr_t *)t-rn_key + 1,
-((struct sockaddr *)t-rn_key)-sa_len) - 1)
-genmask = (struct sockaddr *)(t-rn_key);
-else {
+if (genmask rtm-rtm_type != RTM_GET) {
+if (!(rnh = rt_gettable(dst-sa_family, tableid))) {
+error = EINVAL;
+goto flush;
+}
+if (!(rn = rn_addmask(genmask, 0, rnh-rnh_treetop-rn_off))) {
error = ENOBUFS;
goto flush;
}
+if (!((struct sockaddr *)rn-rn_key)-sa_len) {
+error = EINVAL;
+goto flush;
+}
+genmask = (struct sockaddr *)rn-rn_key;
+} else {
+genmask = NULL;
}
#ifdef MPLS
info.rti_mpls = rtm-rtm_mpls;
rgephy(4): Always use RL_GMEDIASTAT for reading link/media status for re(4) PHY
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 some integrated PHY with re(4).
Tested with..
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 4
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 5
and some newer PHY where this was problematic but existing 8169 PHY
rev board combos are affected too.
From FreeBSD and matches what the Linux driver does.
Index: rgephy.c
===
RCS file: /home/cvs/src/sys/dev/mii/rgephy.c,v
retrieving revision 1.30
diff -u -p -r1.30 rgephy.c
--- rgephy.c28 May 2013 09:46:06 - 1.30
+++ rgephy.c19 Dec 2013 11:13:54 -
@@ -145,6 +145,9 @@ rgephy_service(struct mii_softc *sc, str
{
struct ifmedia_entry *ife = mii-mii_media.ifm_cur;
int anar, reg, speed, gig = 0;
+ char *devname;
+
+ devname = sc-mii_dev.dv_parent-dv_cfdata-cf_driver-cd_name;
switch (cmd) {
case MII_POLLSTAT:
@@ -249,7 +252,7 @@ setit:
* need to restart the autonegotiation process. Read
* the BMSR twice in case it's latched.
*/
- if (sc-mii_rev 2) {
+ if (strcmp(devname, re) == 0) {
reg = PHY_READ(sc, RL_GMEDIASTAT);
if (reg RL_GMEDIASTAT_LINK) {
sc-mii_ticks = 0;
@@ -298,13 +301,15 @@ rgephy_status(struct mii_softc *sc)
{
struct mii_data *mii = sc-mii_pdata;
int bmsr, bmcr, gtsr;
+ char *devname;
+
+ devname = sc-mii_dev.dv_parent-dv_cfdata-cf_driver-cd_name;
mii-mii_media_status = IFM_AVALID;
mii-mii_media_active = IFM_ETHER;
- if (sc-mii_rev 2) {
+ if (strcmp(devname, re) == 0) {
bmsr = PHY_READ(sc, RL_GMEDIASTAT);
-
if (bmsr RL_GMEDIASTAT_LINK)
mii-mii_media_status |= IFM_ACTIVE;
} else {
@@ -328,7 +333,7 @@ rgephy_status(struct mii_softc *sc)
}
}
- if (sc-mii_rev 2) {
+ if (strcmp(devname, re) == 0) {
bmsr = PHY_READ(sc, RL_GMEDIASTAT);
if (bmsr RL_GMEDIASTAT_1000MBPS)
mii-mii_media_active |= IFM_1000_T;
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: rgephy(4): Always use RL_GMEDIASTAT for reading link/media status for re(4) PHY
Date: Sat, 28 Dec 2013 15:42:12 -0500
From: Brad Smith b...@comstyle.com
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 some integrated PHY with re(4).
Tested with..
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 4
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 5
and some newer PHY where this was problematic but existing 8169 PHY
rev board combos are affected too.
From FreeBSD and matches what the Linux driver does.
I hate mii(4) drivers that look at the name of their parent!
Index: rgephy.c
===
RCS file: /home/cvs/src/sys/dev/mii/rgephy.c,v
retrieving revision 1.30
diff -u -p -r1.30 rgephy.c
--- rgephy.c 28 May 2013 09:46:06 - 1.30
+++ rgephy.c 19 Dec 2013 11:13:54 -
@@ -145,6 +145,9 @@ rgephy_service(struct mii_softc *sc, str
{
struct ifmedia_entry *ife = mii-mii_media.ifm_cur;
int anar, reg, speed, gig = 0;
+ char *devname;
+
+ devname = sc-mii_dev.dv_parent-dv_cfdata-cf_driver-cd_name;
switch (cmd) {
case MII_POLLSTAT:
@@ -249,7 +252,7 @@ setit:
* need to restart the autonegotiation process. Read
* the BMSR twice in case it's latched.
*/
- if (sc-mii_rev 2) {
+ if (strcmp(devname, re) == 0) {
reg = PHY_READ(sc, RL_GMEDIASTAT);
if (reg RL_GMEDIASTAT_LINK) {
sc-mii_ticks = 0;
@@ -298,13 +301,15 @@ rgephy_status(struct mii_softc *sc)
{
struct mii_data *mii = sc-mii_pdata;
int bmsr, bmcr, gtsr;
+ char *devname;
+
+ devname = sc-mii_dev.dv_parent-dv_cfdata-cf_driver-cd_name;
mii-mii_media_status = IFM_AVALID;
mii-mii_media_active = IFM_ETHER;
- if (sc-mii_rev 2) {
+ if (strcmp(devname, re) == 0) {
bmsr = PHY_READ(sc, RL_GMEDIASTAT);
-
if (bmsr RL_GMEDIASTAT_LINK)
mii-mii_media_status |= IFM_ACTIVE;
} else {
@@ -328,7 +333,7 @@ rgephy_status(struct mii_softc *sc)
}
}
- if (sc-mii_rev 2) {
+ if (strcmp(devname, re) == 0) {
bmsr = PHY_READ(sc, RL_GMEDIASTAT);
if (bmsr RL_GMEDIASTAT_1000MBPS)
mii-mii_media_active |= IFM_1000_T;
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: Alter daemon scheduling priority with renice for rc.d
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/daemon rc_renice=X with
/etc/rc.conf.local daemon_nice=X
$ fgrep _nice /etc/rc.conf.local
sshd_nice=-10
dhcpd_nice=15
inetd_nice=YES
greyscanner_nice=YES
$ sudo /etc/rc.d/dhcpd -d restart
doing rc_read_runfile
doing rc_read_runfile
doing rc_check
dhcpd
doing rc_stop
doing rc_wait stop
doing rc_check
doing rc_rm_runfile
(ok)
doing rc_read_runfile
doing rc_check
dhcpd
doing rc_pre
doing rc_start
doing rc_write_runfile
doing rc_reprioritise
6142: old priority 0, new priority 15
(ok)
$ ps -l -U _dhcp
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
77 6142 1 0 2 15 672 880 pollINs ??0:00.00
/usr/sbin/dhcpd
Index: rc.subr
===
RCS file: /cvs/src/etc/rc.d/rc.subr,v
retrieving revision 1.70
diff -u -u -p -r1.70 rc.subr
--- rc.subr 11 Jul 2013 09:34:33 - 1.70
+++ rc.subr 28 Dec 2013 21:02:51 -
@@ -1,4 +1,4 @@
-# $OpenBSD: rc.subr,v 1.70 2013/07/11 09:34:33 otto Exp $
+# $OpenBSD: rc.subr,v 1.14 2013/12/28 20:46:25 skinner Exp $
#
# Copyright (c) 2010, 2011 Antoine Jacoutot ajacou...@openbsd.org
# Copyright (c) 2010, 2011 Ingo Schwarze schwa...@openbsd.org
@@ -104,6 +104,28 @@ rc_wait() {
return 1
}
+rc_reprioritise()
+{
+ [[ ${_rcnice} == 'YES' ]] ||
+ {
+ # nice(1): The priority can be adjusted over a
+ # range of -20 (the highest) to 20 (the lowest).
+ for _renice_level in $(jot 40 20 -20)
+ do
+ [[ ${_rcnice} == ${_renice_level} ]]
+ {
+ _scheduling_priority=${_rcnice}
+ break
+ }
+ done
+ }
+
+ # nice(1): an increment of 10 is assumed.
+ [[ -z ${_scheduling_priority} ]] _scheduling_priority='10'
+
+ renice -n ${_scheduling_priority} -p $(pgrep -f ^${pexp})
+}
+
rc_cmd() {
local _bg _n
@@ -136,6 +158,20 @@ rc_cmd() {
fi
[ -z ${INRC} ] rc_do rc_check exit 0
echo $_n ${INRC:+ }${_name}
+
+ # sanitise _rcnice (only used for start) once before loop below
+ [[ ${_rcnice} == 'YES' ]] ||
+ {
+ # if digits present
+ printf %d ${_rcnice} /dev/null 21
+ {
+ # strip non-digits for
+ # comparison in rc_reprioritise()
+ _rcnice=$(printf %d ${_rcnice})
+ [[ ${_rcnice} -eq 0 ]] unset _rcnice
+ }
+ }
+
while true; do # no real loop, only needed to break
if type rc_pre /dev/null; then
rc_do rc_pre || break
@@ -148,6 +184,7 @@ rc_cmd() {
rc_do rc_wait start || break
fi
rc_do rc_write_runfile
+ [[ -n ${_rcnice} ]] rc_do rc_reprioritise
rc_exit ok
done
# handle failure
@@ -203,6 +240,7 @@ _RC_RUNFILE=${_RC_RUNDIR}/${_name}
eval _rcflags=\${${_name}_flags}
eval _rcuser=\${${_name}_user}
+eval _rcnice=\${${_name}_nice}
getcap -f /etc/login.conf ${_name} 1/dev/null 21 \
daemon_class=${_name}
@@ -213,6 +251,7 @@ getcap -f /etc/login.conf ${_name} 1/de
[ -n ${_RC_FORCE} ] [ X${_rcflags} = XNO ] unset _rcflags
[ -n ${_rcflags} ] daemon_flags=${_rcflags}
[ -n ${_rcuser} ] daemon_user=${_rcuser}
+[[ ${_rcnice} == 'NO' ]] unset _rcnice
# sanitize
daemon_flags=$(printf ' %s' ${daemon_flags})
Cheers,
--
Craig Skinner | http://www.bbc.co.uk/programmes/b03mtrg9/clips
Re: Alter daemon scheduling priority with renice for rc.d
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/daemon rc_renice=X with /etc/rc.conf.local daemon_nice=X I'd hate this, or anything similar, to go in. Adding more knobs is exactly the direction i do not want rc.d(8) to take, it was to prevent that that i originally got involved, back at the time in Budapest when it first came up. I consider the general direction of this patch pointless complexity and useless knobs. In order not to end up with SysV-init-like bloat, i say, nip it in the bud. Yours, Ingo
more predictable package installations
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 (and does that).
setting PATH explicitly to
/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:${LOCALBASE}/bin:${LOCALBASE}/sbin
before running @exec/@unexec would allow for reproducibility in package
installations, and simplify some of the command lines.
Re: more predictable package installations
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 would allow for reproducibility in package
installations, and simplify some of the command lines.
I completely agree.
Philip Guenther
Re: more predictable package installations
Date: Sat, 28 Dec 2013 22:37:52 +0100
From: Marc Espie es...@nerim.net
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 things to run in a correct way, so currently
any local command requires /usr/local/bin/cmd to be run (and does that).
setting PATH explicitly to
/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:${LOCALBASE}/bin:${LOCALBASE}/sbin
before running @exec/@unexec would allow for reproducibility in package
installations, and simplify some of the command lines.
Sounds completely reasonable.
Re: more predictable package installations
2013/12/29 Mark Kettenis mark.kette...@xs4all.nl:
Date: Sat, 28 Dec 2013 22:37:52 +0100
From: Marc Espie es...@nerim.net
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 things to run in a correct way, so currently
any local command requires /usr/local/bin/cmd to be run (and does that).
setting PATH explicitly to
/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:${LOCALBASE}/bin:${LOCALBASE}/sbin
before running @exec/@unexec would allow for reproducibility in package
installations, and simplify some of the command lines.
Sounds completely reasonable.
+1 here.
--
WBR,
Vadim Zhukov
Re: Alter daemon scheduling priority with renice for rc.d
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: rgephy(4): Always use RL_GMEDIASTAT for reading link/media status for re(4) PHY
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 some integrated PHY with re(4). Tested with.. rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 4 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 5 and some newer PHY where this was problematic but existing 8169 PHY rev board combos are affected too. From FreeBSD and matches what the Linux driver does. I hate mii(4) drivers that look at the name of their parent! Unfortunately it is a harsh reality that some of these PHY's are sometimes integrated unified-fashion into a MAC chip, without evident register changes to identify them, and then they have a subtly different behaviour. It happens in Broadcom products too.
Re: Alter daemon scheduling priority with renice for rc.d
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/daemon rc_renice=X with
/etc/rc.conf.local daemon_nice=X
Take 3 - simplify:
Use nice directly between ${rcexec} ${daemon} with rc_start(),
rather than renice post start.
Change rc_reprioritise() to rc_validate_rcnice()
Backgrounding still works as expected.
This now works with privilege separated binaries, such as ntpd:
$ fgrep ntp /etc/rc.conf.local
ntpd_flags=-s
ntpd_nice=YES
$ ps -l -U _ntp
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
83 4226 1 0 2 10 708 1136 pollSNs ??0:00.09 ntpd: ntp
engine (ntpd)
83 22421 4226 3 2 10 644 1020 pollINs ??0:00.01 ntpd: dns
engine (ntpd)
Index: rc.subr
===
RCS file: /cvs/src/etc/rc.d/rc.subr,v
retrieving revision 1.70
diff -u -u -p -r1.70 rc.subr
--- rc.subr 11 Jul 2013 09:34:33 - 1.70
+++ rc.subr 28 Dec 2013 23:10:14 -
@@ -1,4 +1,4 @@
-# $OpenBSD: rc.subr,v 1.70 2013/07/11 09:34:33 otto Exp $
+# $OpenBSD: rc.subr,v 1.15 2013/12/28 22:57:21 skinner Exp $
#
# Copyright (c) 2010, 2011 Antoine Jacoutot ajacou...@openbsd.org
# Copyright (c) 2010, 2011 Ingo Schwarze schwa...@openbsd.org
@@ -54,7 +54,8 @@ rc_rm_runfile() {
}
rc_start() {
- ${rcexec} ${daemon} ${daemon_flags} ${_bg}
+ [[ -n ${_rcnice} ]] _nice=$(which nice) -n ${_rcnice}
+ ${rcexec} ${_nice} ${daemon} ${daemon_flags} ${_bg}
}
rc_check() {
@@ -104,6 +105,46 @@ rc_wait() {
return 1
}
+rc_validate_rcnice()
+{
+ [[ -x $(which nice) ]] ||
+ {
+ # /usr not mounted?
+ unset _rcnice
+ return
+ }
+
+ [[ ${_rcnice} == 'YES' ]]
+ {
+ # nice(1): an increment of 10 is assumed.
+ _rcnice=10
+ return
+ }
+
+ # if digits present
+ printf %d ${_rcnice} /dev/null 21
+ {
+ # strip non-digits for comparison
+ _rcnice=$(printf %d ${_rcnice})
+ [[ ${_rcnice} -eq 0 ]]
+ {
+ unset _rcnice
+ return
+ }
+ }
+
+ # nice(1): The priority can be adjusted over a
+ # range of -20 (the highest) to 20 (the lowest).
+ for _nice_level in $(jot 40 20 -20)
+ do
+ [[ ${_rcnice} == ${_nice_level} ]] return
+ done
+
+ # Shouldn't get this far:
+ print -u2 $0: ignoring invalid ${_name}_nice level: ${_rcnice}
+ unset _rcnice
+}
+
rc_cmd() {
local _bg _n
@@ -136,6 +177,9 @@ rc_cmd() {
fi
[ -z ${INRC} ] rc_do rc_check exit 0
echo $_n ${INRC:+ }${_name}
+
+ [[ -n ${_rcnice} ]] rc_validate_rcnice
+
while true; do # no real loop, only needed to break
if type rc_pre /dev/null; then
rc_do rc_pre || break
@@ -203,6 +247,7 @@ _RC_RUNFILE=${_RC_RUNDIR}/${_name}
eval _rcflags=\${${_name}_flags}
eval _rcuser=\${${_name}_user}
+eval _rcnice=\${${_name}_nice}
getcap -f /etc/login.conf ${_name} 1/dev/null 21 \
daemon_class=${_name}
@@ -213,6 +258,7 @@ getcap -f /etc/login.conf ${_name} 1/de
[ -n ${_RC_FORCE} ] [ X${_rcflags} = XNO ] unset _rcflags
[ -n ${_rcflags} ] daemon_flags=${_rcflags}
[ -n ${_rcuser} ] daemon_user=${_rcuser}
+[[ ${_rcnice} == 'NO' ]] unset _rcnice
# sanitize
daemon_flags=$(printf ' %s' ${daemon_flags})
Cheers,
--
Craig Skinner | http://www.bbc.co.uk/programmes/b03mtrg9/clips
Re: Alter daemon scheduling priority with renice for rc.d
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 sshd running at a higher priority than apache, so when their box bogged with some sad customer web-app, more than one ssh keystoke could be typed per minute to kill off their stuff. Maybe a general purpose box could have SpamAssassin running at a lower priority as working a queued mail spool is not user interactive. Cheers, -- Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
Re: Alter daemon scheduling priority with renice for rc.d
On Sat, Dec 28, 2013 at 6:23 PM, Craig R. Skinner
skin...@britvault.co.ukwrote:
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/daemon rc_renice=X with
/etc/rc.conf.local daemon_nice=X
Take 3 - simplify:
Use nice directly between ${rcexec} ${daemon} with rc_start(),
rather than renice post start.
Change rc_reprioritise() to rc_validate_rcnice()
Backgrounding still works as expected.
This now works with privilege separated binaries, such as ntpd:
$ fgrep ntp /etc/rc.conf.local
ntpd_flags=-s
ntpd_nice=YES
$ ps -l -U _ntp
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME
COMMAND
83 4226 1 0 2 10 708 1136 pollSNs ??0:00.09
ntpd: ntp engine (ntpd)
83 22421 4226 3 2 10 644 1020 pollINs ??0:00.01
ntpd: dns engine (ntpd)
Index: rc.subr
===
RCS file: /cvs/src/etc/rc.d/rc.subr,v
retrieving revision 1.70
diff -u -u -p -r1.70 rc.subr
--- rc.subr 11 Jul 2013 09:34:33 - 1.70
+++ rc.subr 28 Dec 2013 23:10:14 -
@@ -1,4 +1,4 @@
-# $OpenBSD: rc.subr,v 1.70 2013/07/11 09:34:33 otto Exp $
+# $OpenBSD: rc.subr,v 1.15 2013/12/28 22:57:21 skinner Exp $
#
# Copyright (c) 2010, 2011 Antoine Jacoutot ajacou...@openbsd.org
# Copyright (c) 2010, 2011 Ingo Schwarze schwa...@openbsd.org
@@ -54,7 +54,8 @@ rc_rm_runfile() {
}
rc_start() {
- ${rcexec} ${daemon} ${daemon_flags} ${_bg}
+ [[ -n ${_rcnice} ]] _nice=$(which nice) -n ${_rcnice}
+ ${rcexec} ${_nice} ${daemon} ${daemon_flags} ${_bg}
}
rc_check() {
@@ -104,6 +105,46 @@ rc_wait() {
return 1
}
+rc_validate_rcnice()
+{
+ [[ -x $(which nice) ]] ||
+ {
+ # /usr not mounted?
+ unset _rcnice
+ return
+ }
+
+ [[ ${_rcnice} == 'YES' ]]
+ {
+ # nice(1): an increment of 10 is assumed.
+ _rcnice=10
+ return
+ }
+
+ # if digits present
+ printf %d ${_rcnice} /dev/null 21
+ {
+ # strip non-digits for comparison
+ _rcnice=$(printf %d ${_rcnice})
+ [[ ${_rcnice} -eq 0 ]]
+ {
+ unset _rcnice
+ return
+ }
+ }
+
case ${_rcnice} in
+([[:digit:]]))
;;
YES
;;
*)
print meeeh
;;
+ # nice(1): The priority can be adjusted over a
+ # range of -20 (the highest) to 20 (the lowest).
+ for _nice_level in $(jot 40 20 -20)
+ do
+ [[ ${_rcnice} == ${_nice_level} ]] return
+ done
+
+ # Shouldn't get this far:
+ print -u2 $0: ignoring invalid ${_name}_nice level: ${_rcnice}
+ unset _rcnice
+}
+
If i understood a bit better the (great) local philosophy checking if the
digit in arg is good is doing a work that nice will do , so all of this is
useless, all you want in something like
$var match yes or (-)1/2 digit. And it he first digit is 0, 1 or 2 you
already reduce to -29 to 29
rc_cmd() {
local _bg _n
@@ -136,6 +177,9 @@ rc_cmd() {
fi
[ -z ${INRC} ] rc_do rc_check exit 0
echo $_n ${INRC:+ }${_name}
+
+ [[ -n ${_rcnice} ]] rc_validate_rcnice
+
while true; do # no real loop, only needed to break
if type rc_pre /dev/null; then
rc_do rc_pre || break
@@ -203,6 +247,7 @@ _RC_RUNFILE=${_RC_RUNDIR}/${_name}
eval _rcflags=\${${_name}_flags}
eval _rcuser=\${${_name}_user}
+eval _rcnice=\${${_name}_nice}
getcap -f /etc/login.conf ${_name} 1/dev/null 21 \
daemon_class=${_name}
@@ -213,6 +258,7 @@ getcap -f /etc/login.conf ${_name} 1/de
[ -n ${_RC_FORCE} ] [ X${_rcflags} = XNO ] unset _rcflags
[ -n ${_rcflags} ] daemon_flags=${_rcflags}
[ -n ${_rcuser} ] daemon_user=${_rcuser}
+[[ ${_rcnice} == 'NO' ]] unset _rcnice
# sanitize
daemon_flags=$(printf ' %s' ${daemon_flags})
Cheers,
--
Craig Skinner | http://www.bbc.co.uk/programmes/b03mtrg9/clips
--
-
() ascii ribbon campaign - against html e-mail
/\
Randomization from the bootblocks
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 future use). Some bootblocks will be able to use machine-dependent features to improve the entropy even further (for instance using random instructions or fast-running counters or such). As a result, the kernel can start using arc4random() exceedingly early on, even before interrupt entropy is collected. The randomization subsystem can hopefully become simpler due to this early entropy.. there is more work do here. At least i386, amd64, macppc, sparc64, hppa, and loongson are supported. Hopefully the others are not far behind.
i386 switched to PIE
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.
Re: Randomization from the bootblocks
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 data supplied early on by the bootblocks, otherwise it
has to replace it:
Index: init_main.c
===
RCS file: /cvs/src/sys/kern/init_main.c,v
retrieving revision 1.196
diff -u -p -u -r1.196 init_main.c
--- init_main.c 28 Dec 2013 20:52:48 - 1.196
+++ init_main.c 28 Dec 2013 22:55:27 -
@@ -412,11 +409,13 @@ main(void *framep)
#endif
#if !defined(NO_PROPOLICE)
+ printf(original %lx\n, __guard_local);
if (__guard_local == 0) {
volatile long newguard;
arc4random_buf((void *)newguard, sizeof newguard);
__guard_local = newguard;
+ printf(new %lx\n, __guard_local);
}
#endif
This might help someone add support to a missing architecture; it
is a good hint anyways.
