[patch] update unbound forwards with dhclient nameservers
Hello,
the following is a patch that adds an option called `update_unbound' to
dhclient.conf. With this option enabled, dhclient will call
unbound-control forwards ns1 ns2 ns3
instead of rewriting /etc/resolv.conf.
My usage scenario is that I'm running unbound on my laptop as a local
resolver. /etc/resolv.conf is configured to only use 127.0.0.1 as the
nameserver.
I use this because I have a few VPN connections that have custom DNS
namespaces, which I manage with Unbound's forward zones. Since
sometimes I am in networks that have a split horizon DNS (e.g.
University, hackerspace, etc...), I can't use a statically configured
fallback forward zone for all my requests. Manually calling using
unbound-control to change the forward DNS became too annoying, so I
wrote this patch.
Does the patch make sense in OpenBSD or should I keep it as a local
change?
--
Gregor Best
--
Index: clparse.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/clparse.c,v
retrieving revision 1.92
diff -u -p -r1.92 clparse.c
--- clparse.c 18 May 2015 17:51:21 - 1.92
+++ clparse.c 9 Jul 2015 15:00:05 -
@@ -75,6 +75,7 @@ read_client_conf(void)
config-backoff_cutoff = 15;
config-initial_interval = 3;
config-bootp_policy = ACCEPT;
+ config-update_unbound = 0;
config-requested_options
[config-requested_option_count++] = DHO_SUBNET_MASK;
config-requested_options
@@ -269,6 +270,10 @@ parse_client_statement(FILE *cfile)
case TOK_NEXT_SERVER:
if (parse_ip_addr(cfile, config-next_server))
parse_semi(cfile);
+ break;
+ case TOK_UPDATE_UNBOUND:
+ config-update_unbound = 1;
+ parse_semi(cfile);
break;
default:
parse_warn(expecting a statement.);
Index: conflex.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/conflex.c,v
retrieving revision 1.32
diff -u -p -r1.32 conflex.c
--- conflex.c 18 May 2015 17:51:21 - 1.32
+++ conflex.c 9 Jul 2015 14:54:56 -
@@ -341,7 +341,8 @@ static const struct keywords {
{ send, TOK_SEND },
{ server-name,TOK_SERVER_NAME },
{ supersede, TOK_SUPERSEDE },
- { timeout,TOK_TIMEOUT }
+ { timeout,TOK_TIMEOUT },
+ { update_unbound, TOK_UPDATE_UNBOUND }
};
intkw_cmp(const void *k, const void *e);
Index: dhclient.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.361
diff -u -p -r1.361 dhclient.c
--- dhclient.c 18 May 2015 14:59:42 - 1.361
+++ dhclient.c 9 Jul 2015 15:52:41 -
@@ -97,6 +97,7 @@ intres_hnok(const char *dn);
voidfork_privchld(int, int);
voidget_ifname(char *);
+voidupdate_unbound_forwards(struct option_data *);
char *resolv_conf_contents(struct option_data *,
struct option_data *);
voidwrite_resolv_conf(u_int8_t *, size_t);
@@ -903,8 +904,12 @@ bind_lease(void)
goto newlease;
}
- client-new-resolv_conf = resolv_conf_contents(
- options[DHO_DOMAIN_NAME], options[DHO_DOMAIN_NAME_SERVERS]);
+ if (config-update_unbound) {
+ update_unbound_forwards(options[DHO_DOMAIN_NAME_SERVERS]);
+ } else {
+ client-new-resolv_conf = resolv_conf_contents(
+ options[DHO_DOMAIN_NAME],
options[DHO_DOMAIN_NAME_SERVERS]);
+ }
/* Replace the old active lease with the new one. */
client-active = client-new;
@@ -2042,6 +2047,88 @@ get_ifname(char *arg)
close(s);
} else if (strlcpy(ifi-name, arg, IFNAMSIZ) = IFNAMSIZ)
error(Interface name too long);
+}
+
+/*
+ * Update unbound forwarder list
+ */
+void
+update_unbound_forwards(struct option_data *nameservers)
+{
+ char *ns;
+ int rslt;
+
+ if (!nameservers-len) {
+ return;
+ }
+
+ ns = pretty_print_option(DHO_DOMAIN_NAME_SERVERS, nameservers, 0);
+
+ rslt = imsg_compose(unpriv_ibuf, IMSG_UPDATE_UNBOUND_FORWARDS,
+ 0, 0, -1, ns, strlen(ns) + 1);
+
+ if (rslt == -1) {
+ warning(update_unbound_forwards: imsg_compose: %s,
+ strerror(errno));
+ }
+
+ flush_unpriv_ibuf(update_unbound_forwards);
+}
+
+void
+priv_update_unbound_forwards(struct imsg *imsg)
+{
+ char *args[MAXNS + 3]; /* `unbound-control', `forward', final NULL */
+ char *ns, *p;
+ int i, rslt;
+ size_t sz;
+ pid_t child;
+
+ if (imsg-hdr.len
Re: Patch to add -f flag to cat(1)
On 18/07/2015 07:40, Philip Guenther wrote: You have in mind a place where this would be used? Where are there bugs that this would resolve? Hi Philip, I originally thought it was meant to be a performance thing in busy environments but that's because I'd misinterpreted things due to O_NONBLOCK flag. The feature was actually added to ensure whatever cat was meant to be reading from was indeed a plain file and not another which could block a process. Use cat -f to avoid denial of service attacks by people who make .rhosts files fifos. http://mail-index.netbsd.org/source-changes/2000/01/14/0069.html This diff as it stands has 2 flaws: 1) The new flag doesn't actually work as intended because the OpenBSD fopen(3) doesn't support the f mode. 2) It passes the f flag to fopen by default, I need integrate the changes from r1.24 which makes it so that the flag is only passed if it has been specified by the use. I'm happy to follow up with a new diff, the question is, is the functionality it provides of interest? Sevan
Re: Patch to add -f flag to cat(1)
The place to solve this is in whatever is using cat for this purpose. check for the file type before blindly cat'ing. this solution is like soaking your clothing with antiseptic every morning because you are prone to stabbing yourself. On Sun, Jul 19, 2015 at 8:26 AM, Ted Unangst t...@tedunangst.com wrote: Sevan Janiyan wrote: The feature was actually added to ensure whatever cat was meant to be reading from was indeed a plain file and not another which could block a process. Use cat -f to avoid denial of service attacks by people who make .rhosts files fifos. http://mail-index.netbsd.org/source-changes/2000/01/14/0069.html hmm, well, security(8) in openbsd is a perl script that doesn't exec cat, so this wouldn't help solve that problem. now, looking at security, it seems there may be an issue if it tries to open a blocking file, but that will need solving there, not in cat.
Re: Thinkpad active cooling
On Fri, Jul 17, 2015 at 08:54:26PM +0200, Mark Kettenis wrote:
Tobias Ulmer schreef op 2015-07-15 02:33:
As we all know, some Thinkpads have problems with their EC fan control.
EC is not spinning up the fans to maximum speed, let alone blast mode.
They also do not offer ACPI methods to spin the fan up.
Previous diffs doing manual fan control were always rejected because
hooking into the sensors framework with fixed temp limits is crude and
there are concerns with slowing the fan down and frying the hardware.
This is an attempt to solve the problem slightly differently.
- Hook into acpitz and only speed the fan up when it is requesting active
cooling
- Never set the fan to a mode that would endanger the hardware should we
crash
PS: It would be nice if there was a function to add cooling methods to
acpitz eg: acpitz_add(void (*fn)(struct acpitz_softc *, void *), void
*arg)
I tried but getting struct acpitz_softc into a header is a bit messy.
Does the AML define any active cooling trip points (_AC0, _AC1, etc)?
No, not in my machines.
Aside from not checking for interference with ACPI, this diff can't
handle multiple thermal zones in a sensible manner.
There's also the problem of not throttling the CPU fast enough for the
little thermal mass in some machines. And I suspect acpitz_refresh()
is not running frequent enough to regulate properly.
I need to play with this some more, not feeling good about it just yet..
Index: acpithinkpad.c
===
RCS file: /home/vcs/cvs/openbsd/src/sys/dev/acpi/acpithinkpad.c,v
retrieving revision 1.44
diff -u -p -r1.44 acpithinkpad.c
--- acpithinkpad.c 24 Apr 2015 14:44:17 - 1.44
+++ acpithinkpad.c 14 Jul 2015 23:52:14 -
@@ -104,6 +104,11 @@
#define THINKPAD_ECOFFSET_FANLO 0x84
#define THINKPAD_ECOFFSET_FANHI 0x85
+#define THINKPAD_ECOFFSET_FANLEVEL 0x2f
+#define THINKPAD_ECFANLEVEL_MAX 7
+#define THINKPAD_ECFANLEVEL_BLAST (16)
+#define THINKPAD_ECFANLEVEL_AUTO(17)
+
#define THINKPAD_ADAPTIVE_MODE_HOME 1
#define THINKPAD_ADAPTIVE_MODE_FUNCTION 3
@@ -119,6 +124,7 @@ struct acpithinkpad_softc {
};
extern void acpiec_read(struct acpiec_softc *, u_int8_t, int, u_int8_t
*);
+extern void (*acpitz_activecool)(int, int);
int thinkpad_match(struct device *, void *, void *);
voidthinkpad_attach(struct device *, struct device *, void *);
@@ -134,6 +140,7 @@ int thinkpad_brightness_up(struct acpith
int thinkpad_brightness_down(struct acpithinkpad_softc *);
int thinkpad_adaptive_change(struct acpithinkpad_softc *);
int thinkpad_activate(struct device *, int);
+voidthinkpad_activecool(int, int);
voidthinkpad_sensor_attach(struct acpithinkpad_softc *sc);
voidthinkpad_sensor_refresh(void *);
@@ -228,6 +235,7 @@ thinkpad_attach(struct device *parent, s
{
struct acpithinkpad_softc *sc = (struct acpithinkpad_softc *)self;
struct acpi_attach_args *aa = aux;
+u_int8_t level;
sc-sc_acpi = (struct acpi_softc *)parent;
sc-sc_devnode = aa-aaa_node;
@@ -241,6 +249,11 @@ thinkpad_attach(struct device *parent, s
/* Run thinkpad_hotkey on button presses */
aml_register_notify(sc-sc_devnode, aa-aaa_dev,
thinkpad_hotkey, sc, ACPIDEV_POLL);
+
+/* Make sure fan is in auto mode, otherwise we're not sure of support */
+acpiec_read(acpi_softc-sc_ec, THINKPAD_ECOFFSET_FANLEVEL, 1, level);
+if (level == THINKPAD_ECFANLEVEL_AUTO)
+acpitz_activecool = thinkpad_activecool;
}
int
@@ -546,4 +559,30 @@ thinkpad_activate(struct device *self, i
break;
}
return (0);
+}
+
+void
+thinkpad_activecool(int tmp, int psv)
+{
+static uint8_t level = THINKPAD_ECFANLEVEL_AUTO;
+uint8_t nlevel;
+
+if (tmp 0 || psv 0)
+return;
+
+if (tmp psv)
+nlevel = THINKPAD_ECFANLEVEL_BLAST;
+else if (tmp psv-50)
+/* EC firmware fan control is too slow in some models. When
+ * we're getting within 5C of active cooling mode, turn the
+ * fan to MAX. Helps with oscillation between blast and auto */
+nlevel = THINKPAD_ECFANLEVEL_MAX;
+else
+nlevel = THINKPAD_ECFANLEVEL_AUTO;
+
+if (nlevel != level) {
+acpiec_write(acpi_softc-sc_ec, THINKPAD_ECOFFSET_FANLEVEL, 1,
+nlevel);
+level = nlevel;
+}
}
Index: acpitz.c
===
RCS file: /home/vcs/cvs/openbsd/src/sys/dev/acpi/acpitz.c,v
retrieving revision 1.49
diff -u -p -r1.49 acpitz.c
--- acpitz.c 6 May 2015 01:41:55 - 1.49
+++ acpitz.c 14 Jul 2015 23:52:14 -
@@ -86,6 +86,7 @@ intacpitz_setfan(struct acpitz_softc *,
voidacpitz_init(struct acpitz_softc *, int);
Re: acpi fix needs testing
On 20.7.2015. 0:06, Mark Kettenis wrote: The acpi code that reads and writes pci config space is quite busted. It always does byte-sized reads and writes even if the aml specifies an access size of four bytes. This made vmware unhappy, because it expetcs to see a magic value being written into a 32-bit register and not the individual bytes. But even on real hardware registers with semantics like that exist. The diff below fixes this issue by respecting the access size. It still does read/modify write cycles for 16-bit and 8-bit writes, but those should be ok. I can't even imagine all the different acpi issues this might fix or introduce. So please try this on as many machines as you can and report any regressions. Hi, I have applied you patch on ibm x3550 m4 and box won't boot. I'm not sure is this because your patch or not. If yes I will post everything that i can in this thread, if not I will open other thread. Here's link to screenshot. http://kosjenka.srce.hr/~hrvoje/zaprocvat/ibm_x3550_m4_01
Re: acpi fix needs testing
I'm pretty sure that's a different problem. But thanks for pointing this out. -ml no, just update your tree please, I just committed the fix
Re: acpi fix needs testing
On 20.7.2015. 0:53, Bob Beck wrote: I'm pretty sure that's a different problem. But thanks for pointing this out. -ml no, just update your tree please, I just committed the fix thank you, everything is working after your fix
Re: acpi fix needs testing
On 20.7.2015. 0:06, Mark Kettenis wrote: The acpi code that reads and writes pci config space is quite busted. It always does byte-sized reads and writes even if the aml specifies an access size of four bytes. This made vmware unhappy, because it expetcs to see a magic value being written into a 32-bit register and not the individual bytes. But even on real hardware registers with semantics like that exist. The diff below fixes this issue by respecting the access size. It still does read/modify write cycles for 16-bit and 8-bit writes, but those should be ok. I can't even imagine all the different acpi issues this might fix or introduce. So please try this on as many machines as you can and report any regressions. Hi, patch is applied on Dell R630 and IBM X3550 M4 and it seems that everything is ok. If there is anything that can be tested, please tell.
Re: Patch to add -f flag to cat(1)
Hi Philip,
Philip Guenther wrote on Sun, Jul 19, 2015 at 11:19:53AM -0700:
On Sun, Jul 19, 2015 at 11:04 AM, Ingo Schwarze schwa...@usta.de wrote:
Philip Guenther wrote on Sun, Jul 19, 2015 at 10:28:57AM -0700:
On Sun, Jul 19, 2015 at 10:24 AM, Ingo Schwarze schwa...@usta.de wrote:
I don't think we are vulnerable.
If my analysis is accurate, the only user-controlled files
we open in security(8) are ~/.rhosts and ~/.shosts
in check_rhosts_content(). However, there is
next unless -s $filename;
right before the open(), and for fifos, -s returns false:
TOCTOU race there. If they can hit the gap and move a fifo
over a normal file between the test and the open, the open
will hang. Should switch to sysopen() with O_NONBLOCK.
Oops, indeed.
Index: security
===
RCS file: /cvs/src/libexec/security/security,v
retrieving revision 1.35
diff -u -p -r1.35 security
--- security21 Apr 2015 10:24:22 - 1.35
+++ security19 Jul 2015 18:02:38 -
@@ -22,7 +22,7 @@ use strict;
use Digest::SHA qw(sha256_hex);
use Errno qw(ENOENT);
-use Fcntl qw(:mode);
+use Fcntl qw(O_RDONLY O_NONBLOCK :mode);
use File::Basename qw(basename);
use File::Compare qw(compare);
use File::Copy qw(copy);
@@ -371,7 +371,7 @@ sub check_rhosts_content {
foreach my $base (qw(rhosts shosts)) {
my $filename = $home/.$base;
next unless -s $filename;
- nag !open(my $fh, '', $filename),
+ nag !sysopen(my $fh, $filename, O_RDONLY | O_NONBLOCK),
open: $filename: $!
and next;
local $_;
You need to then test the resulting file handle to verify it was a
normal file. I think just
nag !-f $fh
?
I don't think that's very important. If users make their ~/.rhosts
file a fifo, the script won't warn because the -s above the open()
bails. If they go to the length of racing the -s to prevent that,
the above code will do about the same, in particular not warn either,
because the subsequent read won't return any data. So why should
we warn in that exotic case?
Then again, if you insist, nothing much is wrong with the patch
below, even though i'd probably mildly prefer the simpler one above.
Yours,
Ingo
Index: security
===
RCS file: /cvs/src/libexec/security/security,v
retrieving revision 1.35
diff -u -p -r1.35 security
--- security21 Apr 2015 10:24:22 - 1.35
+++ security20 Jul 2015 00:48:28 -
@@ -22,7 +22,7 @@ use strict;
use Digest::SHA qw(sha256_hex);
use Errno qw(ENOENT);
-use Fcntl qw(:mode);
+use Fcntl qw(O_RDONLY O_NONBLOCK :mode);
use File::Basename qw(basename);
use File::Compare qw(compare);
use File::Copy qw(copy);
@@ -371,8 +371,11 @@ sub check_rhosts_content {
foreach my $base (qw(rhosts shosts)) {
my $filename = $home/.$base;
next unless -s $filename;
- nag !open(my $fh, '', $filename),
+ nag !sysopen(my $fh, $filename, O_RDONLY | O_NONBLOCK),
open: $filename: $!
+ and next;
+ nag !(-f $fh),
+ $filename is not a regular file
and next;
local $_;
nag /^\+\s*$/,
move pflow(4) to sosend(9)
so pflow(4) shoving it's data with ip_output into the network stack
seems wrong. this converts it to use sosend(9) and might even give us
non-legacy IP support.
tests from (heavy) pflow(4) users would be appriciated.
diff --git if_pflow.c if_pflow.c
index 4f3ac5e..624fdaf 100644
--- if_pflow.c
+++ if_pflow.c
@@ -28,6 +28,8 @@
#include sys/timeout.h
#include sys/ioctl.h
#include sys/kernel.h
+#include sys/socket.h
+#include sys/socketvar.h
#include sys/sysctl.h
#include net/if.h
@@ -94,7 +96,6 @@ int pflow_pack_flow(struct pf_state *, struct pf_state_key
*,
struct pflow_softc *);
intpflow_pack_flow_ipfix(struct pf_state *, struct pf_state_key *,
struct pflow_softc *);
-intpflow_get_dynport(void);
intexport_pflow_if(struct pf_state*, struct pf_state_key *,
struct pflow_softc *);
intcopy_flow_to_m(struct pflow_flow *flow, struct pflow_softc *sc);
@@ -107,6 +108,8 @@ struct if_clone pflow_cloner =
IF_CLONE_INITIALIZER(pflow, pflow_clone_create,
pflow_clone_destroy);
+extern struct proc proc0;
+
void
pflowattach(int npflow)
{
@@ -119,22 +122,51 @@ pflow_clone_create(struct if_clone *ifc, int unit)
{
struct ifnet*ifp;
struct pflow_softc *pflowif;
+ struct socket *so;
+ struct sockaddr_in *sin;
+ struct mbuf *m;
+ int error;
+
+ error = 0;
+ m = NULL;
+
+ error = socreate(AF_INET, so, SOCK_DGRAM, 0);
+ if (error)
+ return (error);
+
+ MGET(m, M_WAIT, MT_SONAME);
+ sin = mtod(m, struct sockaddr_in *);
+ sin-sin_len = m-m_len = sizeof (struct sockaddr_in);
+ sin-sin_family = AF_INET;
+ sin-sin_addr.s_addr = INADDR_ANY;
+ sin-sin_port = htons(0);
+ error = sobind(so, m, proc0);
+ m_freem(m);
+ if (error) {
+ soclose(so);
+ pflowif-so = NULL;
+ return (error);
+ }
if ((pflowif = malloc(sizeof(*pflowif),
- M_DEVBUF, M_NOWAIT|M_ZERO)) == NULL)
- return (ENOMEM);
-
- if ((pflowif-sc_imo.imo_membership = malloc(
- (sizeof(struct in_multi *) * IP_MIN_MEMBERSHIPS), M_IPMOPTS,
- M_WAITOK|M_ZERO)) == NULL) {
- free(pflowif, M_DEVBUF, 0);
+ M_DEVBUF, M_NOWAIT|M_ZERO)) == NULL) {
+ soclose(so);
+ pflowif-so = NULL;
return (ENOMEM);
}
- pflowif-sc_imo.imo_max_memberships = IP_MIN_MEMBERSHIPS;
+
+ pflowif-so = so;
+
+ MGET(pflowif-send_nam, M_WAIT, MT_SONAME);
+ sin = mtod(pflowif-send_nam, struct sockaddr_in *);
+ sin-sin_len = m-m_len = sizeof (struct sockaddr_in);
+ sin-sin_family = AF_INET;
+ sin-sin_addr.s_addr = INADDR_ANY;
+ sin-sin_port = 0;
+
pflowif-sc_receiver_ip.s_addr = INADDR_ANY;
pflowif-sc_receiver_port = 0;
pflowif-sc_sender_ip.s_addr = INADDR_ANY;
- pflowif-sc_sender_port = pflow_get_dynport();
pflowif-sc_version = PFLOW_PROTO_DEFAULT;
/* ipfix template init */
@@ -244,10 +276,6 @@ pflow_clone_create(struct if_clone *ifc, int unit)
if_attach(ifp);
if_alloc_sadl(ifp);
-#if NBPFILTER 0
- bpfattach(pflowif-sc_if.if_bpf, ifp, DLT_RAW, 0);
-#endif
-
/* Insert into list of pflows */
SLIST_INSERT_HEAD(pflowif_list, pflowif, sc_next);
return (0);
@@ -257,9 +285,15 @@ int
pflow_clone_destroy(struct ifnet *ifp)
{
struct pflow_softc *sc = ifp-if_softc;
- int s;
+ int s, error;
+
+ error = 0;
+ if (sc-so != NULL)
+ error = soclose(sc-so);
s = splnet();
+ sc-so = NULL;
+ m_freem(sc-send_nam);
if (timeout_initialized(sc-sc_tmo))
timeout_del(sc-sc_tmo);
if (timeout_initialized(sc-sc_tmo6))
@@ -269,10 +303,9 @@ pflow_clone_destroy(struct ifnet *ifp)
pflow_flush(sc);
if_detach(ifp);
SLIST_REMOVE(pflowif_list, sc, pflow_softc, sc_next);
- free(sc-sc_imo.imo_membership, M_IPMOPTS, 0);
free(sc, M_DEVBUF, 0);
splx(s);
- return (0);
+ return (error);
}
/*
@@ -312,6 +345,9 @@ pflowioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
struct pflow_softc *sc = ifp-if_softc;
struct ifreq*ifr = (struct ifreq *)data;
struct pflowreq pflowr;
+ struct socket *so;
+ struct sockaddr_in *sin;
+ struct mbuf *m;
int s, error;
switch (cmd) {
@@ -321,8 +357,7 @@ pflowioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
case SIOCSIFFLAGS:
if ((ifp-if_flags IFF_UP)
sc-sc_receiver_ip.s_addr != INADDR_ANY
- sc-sc_receiver_port != 0
-
Re: usb hang related to xhci
After applied the diff, my intel Series 7 PC could not attach any USB3.0 devices
to xHCI, as following (usbdevs output)
original
addr 1: xHCI root hub, Intel
addr 2: Keyboard Mouse Ver.0D0200, Microchip Technology Inc.
addr 3: AX88179, ASIX Elec. Corp.
addr 1: EHCI root hub, Intel
addr 2: Rate Matching Hub, Intel
addr 3: NEC HD WebCam, Chicony Electronics Co.,Ltd.
addr 4: Wireless Bluetooth, Intel
after applyed the diff
addr 1: xHCI root hub, Intel
addr 1: EHCI root hub, Intel
addr 2: Rate Matching Hub, Intel
addr 3: Keyboard Mouse Ver.0D0200, Microchip Technology Inc.
addr 6: AX88179, ASIX Elec. Corp.
addr 4: NEC HD WebCam, Chicony Electronics Co.,Ltd.
addr 5: Wireless Bluetooth, Intel
-- Yojiro UO
2015/07/18 20:25、David Hill dh...@mindcry.org :
Hello -
Whenever I plug a device into my USB ports, my machine locks hard. I
have the Intel Series 7 / C216 chip, so xhci attempts to route the port
from ehci to xhci.
The following diff is from FreeBSD and makes my USB devices work again.
https://github.com/freebsd/freebsd/blob/e79c62ff68fc74d88cb6f479859f6fae9baa5101/sys/dev/usb/controller/xhci_pci.c#L153-L176
Index: sys/dev/pci/xhci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/xhci_pci.c,v
retrieving revision 1.6
diff -u -p -r1.6 xhci_pci.c
--- sys/dev/pci/xhci_pci.c22 Jun 2015 08:43:27 - 1.6
+++ sys/dev/pci/xhci_pci.c19 Jul 2015 02:20:06 -
@@ -92,33 +92,45 @@ xhci_pci_match(struct device *parent, vo
static int
xhci_pci_port_route(struct xhci_pci_softc *psc)
{
- pcireg_t val;
+ pcireg_t val, usb2_mask, usb3_mask;
- /*
- * Check USB3 Port Routing Mask register that indicates the ports
- * can be changed from OS, and turn on by USB3 Port SS Enable register.
- */
- val = pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_USB3PRM);
- DPRINTF((%s: USB3PRM / USB3.0 configurable ports: 0x%08x\n,
- psc-sc.sc_bus.bdev.dv_xname, val));
+/*
+ * Check USB3 Port Routing Mask register that indicates the ports
+ * can be changed from OS, and turn on by USB3 Port SS Enable
register.
+ */
+usb3_mask = pci_conf_read(psc-sc_pc, psc-sc_tag,
+ PCI_XHCI_INTEL_USB3PRM);
+DPRINTF((%s: USB3PRM / USB3.0 configurable ports: 0x%08x\n,
+psc-sc.sc_bus.bdev.dv_xname, usb3_mask));
+
+/*
+ * Check USB2 Port Routing Mask register that indicates the USB2.0
+ * ports to be controlled by xHCI HC, and switch them to xHCI HC.
+ */
+usb2_mask = pci_conf_read(psc-sc_pc, psc-sc_tag,
+ PCI_XHCI_INTEL_XUSB2PRM);
+DPRINTF((%s: XUSB2PRM / USB2.0 ports can switch from EHCI to xHCI:
+0x%08x\n, psc-sc.sc_bus.bdev.dv_xname, val));
+
+ val = pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_USB3_PSSEN)
|
+ pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_XUSB2PR);
- pci_conf_write(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_USB3_PSSEN, val);
+
+ pci_conf_write(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_USB3_PSSEN,
+ val usb3_mask);
+#ifdef XHCI_DEBUG
val = pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_USB3_PSSEN);
DPRINTF((%s: USB3_PSSEN / Enabled USB3.0 ports under xHCI: 0x%08x\n,
psc-sc.sc_bus.bdev.dv_xname, val));
+#endif
- /*
- * Check USB2 Port Routing Mask register that indicates the USB2.0
- * ports to be controlled by xHCI HC, and switch them to xHCI HC.
- */
- val = pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_XUSB2PRM);
- DPRINTF((%s: XUSB2PRM / USB2.0 ports can switch from EHCI to xHCI:
- 0x%08x\n, psc-sc.sc_bus.bdev.dv_xname, val));
-
- pci_conf_write(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_XUSB2PR, val);
+ pci_conf_write(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_XUSB2PR,
+ val usb2_mask);
+#ifdef XHCI_DEBUG
val = pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_XUSB2PR);
DPRINTF((%s: XUSB2PR / USB2.0 ports under xHCI: 0x%08x\n,
psc-sc.sc_bus.bdev.dv_xname, val));
+#endif
return (0);
}
Re: acpi fix needs testing
On Mon, Jul 20, 2015 at 12:38:19AM +0200, Hrvoje Popovski wrote: On 20.7.2015. 0:06, Mark Kettenis wrote: The acpi code that reads and writes pci config space is quite busted. It always does byte-sized reads and writes even if the aml specifies an access size of four bytes. This made vmware unhappy, because it expetcs to see a magic value being written into a 32-bit register and not the individual bytes. But even on real hardware registers with semantics like that exist. The diff below fixes this issue by respecting the access size. It still does read/modify write cycles for 16-bit and 8-bit writes, but those should be ok. I can't even imagine all the different acpi issues this might fix or introduce. So please try this on as many machines as you can and report any regressions. Hi, I have applied you patch on ibm x3550 m4 and box won't boot. I'm not sure is this because your patch or not. If yes I will post everything that i can in this thread, if not I will open other thread. Here's link to screenshot. http://kosjenka.srce.hr/~hrvoje/zaprocvat/ibm_x3550_m4_01 I'm pretty sure that's a different problem. But thanks for pointing this out. -ml
acpi fix needs testing
The acpi code that reads and writes pci config space is quite busted.
It always does byte-sized reads and writes even if the aml specifies
an access size of four bytes. This made vmware unhappy, because it
expetcs to see a magic value being written into a 32-bit register and
not the individual bytes. But even on real hardware registers with
semantics like that exist.
The diff below fixes this issue by respecting the access size. It
still does read/modify write cycles for 16-bit and 8-bit writes, but
those should be ok.
I can't even imagine all the different acpi issues this might fix or
introduce. So please try this on as many machines as you can and
report any regressions.
Index: acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.287
diff -u -p -r1.287 acpi.c
--- acpi.c 26 Mar 2015 01:30:22 - 1.287
+++ acpi.c 19 Jul 2015 21:27:08 -
@@ -218,6 +218,50 @@ struct acpi_softc *acpi_softc;
#define acpi_bus_space_map _bus_space_map
#define acpi_bus_space_unmap _bus_space_unmap
+uint8_t
+acpi_pci_conf_read_1(pci_chipset_tag_t pc, pcitag_t tag, int reg)
+{
+ uint32_t val = pci_conf_read(pc, tag, reg ~0x3);
+ return (val ((reg 0x3) 3));
+}
+
+uint16_t
+acpi_pci_conf_read_2(pci_chipset_tag_t pc, pcitag_t tag, int reg)
+{
+ uint32_t val = pci_conf_read(pc, tag, reg ~0x2);
+ return (val ((reg 0x2) 3));
+}
+
+uint32_t
+acpi_pci_conf_read_4(pci_chipset_tag_t pc, pcitag_t tag, int reg)
+{
+ return pci_conf_read(pc, tag, reg);
+}
+
+void
+acpi_pci_conf_write_1(pci_chipset_tag_t pc, pcitag_t tag, int reg, uint8_t val)
+{
+ uint32_t tmp = pci_conf_read(pc, tag, reg ~0x3);
+ tmp = ~(0xff ((reg 0x3) 3));
+ tmp |= (val ((reg 0x3) 3));
+ pci_conf_write(pc, tag, reg ~0x3, tmp);
+}
+
+void
+acpi_pci_conf_write_2(pci_chipset_tag_t pc, pcitag_t tag, int reg, uint16_t
val)
+{
+ uint32_t tmp = pci_conf_read(pc, tag, reg ~0x2);
+ tmp = ~(0x ((reg 0x2) 3));
+ tmp |= (val ((reg 0x2) 3));
+ pci_conf_write(pc, tag, reg ~0x2, tmp);
+}
+
+void
+acpi_pci_conf_write_4(pci_chipset_tag_t pc, pcitag_t tag, int reg, uint32_t
val)
+{
+ pci_conf_write(pc, tag, reg, val);
+}
+
int
acpi_gasio(struct acpi_softc *sc, int iodir, int iospace, uint64_t address,
int access_size, int len, void *buffer)
@@ -227,7 +271,7 @@ acpi_gasio(struct acpi_softc *sc, int io
bus_space_handle_t ioh;
pci_chipset_tag_t pc;
pcitag_t tag;
- int reg, idx, ival, sval;
+ int reg, idx;
dnprintf(50, gasio: %.2x 0x%.8llx %s\n,
iospace, address, (iodir == ACPI_IOWRITE) ? write : read);
@@ -326,19 +370,47 @@ acpi_gasio(struct acpi_softc *sc, int io
ACPI_PCI_BUS(address), ACPI_PCI_DEV(address),
ACPI_PCI_FN(address));
- /* XXX: This is ugly. read-modify-write does a byte at a time */
reg = ACPI_PCI_REG(address);
- for (idx = reg; idx reg+len; idx++) {
- ival = pci_conf_read(pc, tag, idx ~0x3);
+ for (idx = 0; idx len; idx += access_size) {
if (iodir == ACPI_IOREAD) {
- *pb = ival (8 * (idx 0x3));
+ switch (access_size) {
+ case 1:
+ *(uint8_t *)(pb + idx) =
+ acpi_pci_conf_read_1(pc, tag, reg +
idx);
+ break;
+ case 2:
+ *(uint16_t *)(pb + idx) =
+ acpi_pci_conf_read_2(pc, tag, reg +
idx);
+ break;
+ case 4:
+ *(uint32_t *)(pb + idx) =
+ acpi_pci_conf_read_4(pc, tag, reg +
idx);
+ break;
+ default:
+ printf(%s: rdcfg: invalid size %d\n,
+ DEVNAME(sc), access_size);
+ return (-1);
+ }
} else {
- sval = *pb;
- ival = ~(0xFF (8* (idx 0x3)));
- ival |= sval (8* (idx 0x3));
- pci_conf_write(pc, tag, idx ~0x3, ival);
+ switch (access_size) {
+ case 1:
+ acpi_pci_conf_write_1(pc, tag, reg +
idx,
+ *(uint8_t *)(pb + idx));
+ break;
+
cardbus fix
Some (early) acpi machines leave the cardbus bridge unconfigured. In
particular, those machines don't configure the bus number for the
cardbus bus. This makes our driver skip attaching the 32-bit cardbus
handling and only support 16-bit pcmcia cards.
Diff below makes our driver assign an available bus number and
configure the bridge with it. This makes cardbus work on a machine in
the class mentioned above.
ok?
Index: pccbb.c
===
RCS file: /cvs/src/sys/dev/pci/pccbb.c,v
retrieving revision 1.94
diff -u -p -r1.94 pccbb.c
--- pccbb.c 19 Jul 2015 05:37:38 - 1.94
+++ pccbb.c 19 Jul 2015 23:59:24 -
@@ -372,6 +372,7 @@ pccbbattach(struct device *parent, struc
pci_chipset_tag_t pc = pa-pa_pc;
pci_intr_handle_t ih;
const char *intrstr = NULL;
+ u_long busnum;
int flags;
pccbb_attach_hook(parent, self, pa);
@@ -447,8 +448,19 @@ pccbbattach(struct device *parent, struc
printf(: %s, intrstr);
/*
-* When bus number isn't set correctly, give up using 32-bit CardBus
-* mode.
+* When the bus number isn't configured, try to allocate one
+* ourselves.
+*/
+ if ((sc-sc_busnum 0x0000) == 0 pa-pa_busex
+ extent_alloc(pa-pa_busex, 1, 1, 0, 0, EX_NOWAIT, busnum) == 0) {
+ sc-sc_busnum |= (busnum 8);
+ sc-sc_busnum |= (busnum 16);
+ pci_conf_write(pc, pa-pa_tag, PCI_BUSNUM, sc-sc_busnum);
+ }
+
+ /*
+* When the bus number still isn't set correctly, give up
+* using 32-bit CardBus mode.
*/
if (((sc-sc_busnum 8) 0xff) == 0) {
printf(, CardBus support disabled);
Re: potential memory leak when pf_create_state() fails
On Mon, Jul 20, 2015 at 04:27:45AM +0900, Ryan McBride wrote:
ok mcbride@
err
I took a look at the patch one more time. I've realized PF must bind the rules
to state before STATE_INC_COUNTERS() gets called. Not doing so makes PF to
play games with dangling pointers to rule from state. State still references
rules via match_rules list, but it has not actually bumped states_cur for
them.
from caller point of view the PF_SYNPROXY_DROP actually means success.
we have a state in table, but want still drop the packet as we are proxying
handshake.
updated patch is below.
sorry for extra round trip...
regards
sasha
-888---8
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.931
diff -u -p -r1.931 pf.c
--- pf.c19 Jul 2015 05:48:11 - 1.931
+++ pf.c19 Jul 2015 21:08:31 -
@@ -3068,6 +3068,7 @@ pf_test_rule(struct pf_pdesc *pd, struct
int state_icmp = 0, icmp_dir = 0;
u_int16_tvirtual_type, virtual_id;
u_int8_t icmptype = 0, icmpcode = 0;
+ int action = PF_DROP;
bzero(act, sizeof(act));
bzero(sns, sizeof(sns));
@@ -3351,7 +3352,6 @@ pf_test_rule(struct pf_pdesc *pd, struct
if (pd-virtual_proto != PF_VPROTO_FRAGMENT
!state_icmp r-keep_state) {
- int action;
if (r-rule_flag PFRULE_SRCTRACK
pf_insert_src_node(sns[PF_SN_NONE], r, PF_SN_NONE, pd-af,
@@ -3370,7 +3370,7 @@ pf_test_rule(struct pf_pdesc *pd, struct
sm, tag, rules, act, sns);
if (action != PF_PASS)
- return (action);
+ goto cleanup;
if (sks != skw) {
struct pf_state_key *sk;
@@ -3428,7 +3428,7 @@ cleanup:
pool_put(pf_rule_item_pl, ri);
}
- return (PF_DROP);
+ return (action);
}
static __inline int
@@ -3451,7 +3451,6 @@ pf_create_state(struct pf_pdesc *pd, str
s-rule.ptr = r;
s-anchor.ptr = a;
s-natrule.ptr = nr;
- memcpy(s-match_rules, rules, sizeof(s-match_rules));
if (r-allow_opts)
s-state_flags |= PFSTATE_ALLOWOPTS;
if (r-rule_flag PFRULE_STATESLOPPY)
@@ -3580,6 +3579,11 @@ pf_create_state(struct pf_pdesc *pd, str
} else
*sm = s;
+ /*
+* Make state responsible for rules it binds here.
+*/
+ memcpy(s-match_rules, rules, sizeof(s-match_rules));
+ bzero(rules, sizeof(*rules));
STATE_INC_COUNTERS(s);
if (tag 0) {
Re: tame(2) WIP
Theo de Raadt deraadt at cvs.openbsd.org writes:
[replying via gmane, which apparently doesn't like text from the original
email to be quoted so I had to severely strip out text from the original
message, and also doesn't allow this bracketed message to be placed at the
top of my message]
Hi,
I was just reading through this and it looks like there is a bug in one of
your strncmp() calls in sys/kern/kern_tame.c:tame_namei() here:
if (strncmp(path, /var/yp/binding/, 14) == 0)
return (0);
/var/yp/binding/ is not 14 characters.
For what it's worth, I like this idea. It certainly makes using this
feature more accessible than seccomp-bpf in linux, and hence more likely to
be used. I'm more of a linux guy, but I've always appreciated OpenBSD's
focus on security (thanks for strlcpy/strlcat btw :-). It seems like your
tame interface could be implemented as a header-only interface on top of
linux's seccomp-bpf.
Cheers,
-Brandon
Index: sys/kern/kern_tame.c
===
RCS file: sys/kern/kern_tame.c
diff -N sys/kern/kern_tame.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sys/kern/kern_tame.c 18 Jul 2015 21:36:11 -
at at -0,0 +1,788 at at
snip
+ if (p-p_p-ps_tame _TM_GETPW) {
+ if (strcmp(path, /var/run/ypbind.lock) == 0) {
+ p-p_tamenote |= TMN_YPLOCK;
+ p-p_tameafter = 1;
+ return (0);
+ }
+ if (strncmp(path, /var/yp/binding/, 14) == 0)
Here, /var/yp/binding/ is not 14 characters.
+ return (0);
+ }
snip
Re: acpi fix needs testing
On 20.7.2015. 0:41, Mike Larkin wrote: On Mon, Jul 20, 2015 at 12:38:19AM +0200, Hrvoje Popovski wrote: On 20.7.2015. 0:06, Mark Kettenis wrote: The acpi code that reads and writes pci config space is quite busted. It always does byte-sized reads and writes even if the aml specifies an access size of four bytes. This made vmware unhappy, because it expetcs to see a magic value being written into a 32-bit register and not the individual bytes. But even on real hardware registers with semantics like that exist. The diff below fixes this issue by respecting the access size. It still does read/modify write cycles for 16-bit and 8-bit writes, but those should be ok. I can't even imagine all the different acpi issues this might fix or introduce. So please try this on as many machines as you can and report any regressions. Hi, I have applied you patch on ibm x3550 m4 and box won't boot. I'm not sure is this because your patch or not. If yes I will post everything that i can in this thread, if not I will open other thread. Here's link to screenshot. http://kosjenka.srce.hr/~hrvoje/zaprocvat/ibm_x3550_m4_01 I'm pretty sure that's a different problem. But thanks for pointing this out. -ml ok... to open other thread?
Re: acpi fix needs testing
On Mon, Jul 20, 2015 at 02:21:00AM +0200, Hrvoje Popovski wrote: On 20.7.2015. 0:53, Bob Beck wrote: I'm pretty sure that's a different problem. But thanks for pointing this out. -ml no, just update your tree please, I just committed the fix thank you, everything is working after your fix My fix was unrelated to Mark's diff however, I'm sure he would still appreciate your testing.
Re: usb hang related to xhci
On Sat, 18 Jul 2015, David Hill wrote:
Whenever I plug a device into my USB ports, my machine locks hard. I
have the Intel Series 7 / C216 chip, so xhci attempts to route the port
from ehci to xhci.
The following diff is from FreeBSD and makes my USB devices work again.
https://github.com/freebsd/freebsd/blob/e79c62ff68fc74d88cb6f479859f6fae9baa5101/sys/dev/usb/controller/xhci_pci.c#L153-L176
I didn't have the lockup but my Intel Series 9 laptop does not recognice a
USB 3.0 storage device if I insert it after a hot boot. If I insert it
after a cold boot, it works ok.
This behavior does not change with your patch.
Cheers,
Stefan
Index: sys/dev/pci/xhci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/xhci_pci.c,v
retrieving revision 1.6
diff -u -p -r1.6 xhci_pci.c
--- sys/dev/pci/xhci_pci.c22 Jun 2015 08:43:27 - 1.6
+++ sys/dev/pci/xhci_pci.c19 Jul 2015 02:20:06 -
@@ -92,33 +92,45 @@ xhci_pci_match(struct device *parent, vo
static int
xhci_pci_port_route(struct xhci_pci_softc *psc)
{
- pcireg_t val;
+ pcireg_t val, usb2_mask, usb3_mask;
- /*
- * Check USB3 Port Routing Mask register that indicates the ports
- * can be changed from OS, and turn on by USB3 Port SS Enable register.
- */
- val = pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_USB3PRM);
- DPRINTF((%s: USB3PRM / USB3.0 configurable ports: 0x%08x\n,
- psc-sc.sc_bus.bdev.dv_xname, val));
+/*
+ * Check USB3 Port Routing Mask register that indicates the ports
+ * can be changed from OS, and turn on by USB3 Port SS Enable
register.
+ */
+usb3_mask = pci_conf_read(psc-sc_pc, psc-sc_tag,
+ PCI_XHCI_INTEL_USB3PRM);
+DPRINTF((%s: USB3PRM / USB3.0 configurable ports: 0x%08x\n,
+psc-sc.sc_bus.bdev.dv_xname, usb3_mask));
+
+/*
+ * Check USB2 Port Routing Mask register that indicates the USB2.0
+ * ports to be controlled by xHCI HC, and switch them to xHCI HC.
+ */
+usb2_mask = pci_conf_read(psc-sc_pc, psc-sc_tag,
+ PCI_XHCI_INTEL_XUSB2PRM);
+DPRINTF((%s: XUSB2PRM / USB2.0 ports can switch from EHCI to xHCI:
+0x%08x\n, psc-sc.sc_bus.bdev.dv_xname, val));
+
+ val = pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_USB3_PSSEN)
|
+ pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_XUSB2PR);
- pci_conf_write(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_USB3_PSSEN, val);
+
+ pci_conf_write(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_USB3_PSSEN,
+ val usb3_mask);
+#ifdef XHCI_DEBUG
val = pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_USB3_PSSEN);
DPRINTF((%s: USB3_PSSEN / Enabled USB3.0 ports under xHCI: 0x%08x\n,
psc-sc.sc_bus.bdev.dv_xname, val));
+#endif
- /*
- * Check USB2 Port Routing Mask register that indicates the USB2.0
- * ports to be controlled by xHCI HC, and switch them to xHCI HC.
- */
- val = pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_XUSB2PRM);
- DPRINTF((%s: XUSB2PRM / USB2.0 ports can switch from EHCI to xHCI:
- 0x%08x\n, psc-sc.sc_bus.bdev.dv_xname, val));
-
- pci_conf_write(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_XUSB2PR, val);
+ pci_conf_write(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_XUSB2PR,
+ val usb2_mask);
+#ifdef XHCI_DEBUG
val = pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_XUSB2PR);
DPRINTF((%s: XUSB2PR / USB2.0 ports under xHCI: 0x%08x\n,
psc-sc.sc_bus.bdev.dv_xname, val));
+#endif
return (0);
}
Re: usb hang related to xhci
2015/07/19 19:16、Stefan Fritsch s...@sfritsch.de :
On Sat, 18 Jul 2015, David Hill wrote:
Whenever I plug a device into my USB ports, my machine locks hard. I
have the Intel Series 7 / C216 chip, so xhci attempts to route the port
from ehci to xhci.
The following diff is from FreeBSD and makes my USB devices work again.
https://github.com/freebsd/freebsd/blob/e79c62ff68fc74d88cb6f479859f6fae9baa5101/sys/dev/usb/controller/xhci_pci.c#L153-L176
I didn't have the lockup but my Intel Series 9 laptop does not recognice a
USB 3.0 storage device if I insert it after a hot boot. If I insert it
after a cold boot, it works ok.
This behaviour is same on my Intel Series 7 PC.
This behavior does not change with your patch.
As the patch prevent to attach any USB3.0 devices to xhci, the problem
is not occurs on my PC (all device will be attached to EHCI, and EHCI
is works well :)
-- Yojiro UO
Cheers,
Stefan
Index: sys/dev/pci/xhci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/xhci_pci.c,v
retrieving revision 1.6
diff -u -p -r1.6 xhci_pci.c
--- sys/dev/pci/xhci_pci.c 22 Jun 2015 08:43:27 - 1.6
+++ sys/dev/pci/xhci_pci.c 19 Jul 2015 02:20:06 -
@@ -92,33 +92,45 @@ xhci_pci_match(struct device *parent, vo
static int
xhci_pci_port_route(struct xhci_pci_softc *psc)
{
-pcireg_t val;
+pcireg_t val, usb2_mask, usb3_mask;
-/*
- * Check USB3 Port Routing Mask register that indicates the ports
- * can be changed from OS, and turn on by USB3 Port SS Enable register.
- */
-val = pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_USB3PRM);
-DPRINTF((%s: USB3PRM / USB3.0 configurable ports: 0x%08x\n,
-psc-sc.sc_bus.bdev.dv_xname, val));
+/*
+ * Check USB3 Port Routing Mask register that indicates the ports
+ * can be changed from OS, and turn on by USB3 Port SS Enable
register.
+ */
+usb3_mask = pci_conf_read(psc-sc_pc, psc-sc_tag,
+PCI_XHCI_INTEL_USB3PRM);
+DPRINTF((%s: USB3PRM / USB3.0 configurable ports: 0x%08x\n,
+psc-sc.sc_bus.bdev.dv_xname, usb3_mask));
+
+/*
+ * Check USB2 Port Routing Mask register that indicates the USB2.0
+ * ports to be controlled by xHCI HC, and switch them to xHCI HC.
+ */
+usb2_mask = pci_conf_read(psc-sc_pc, psc-sc_tag,
+PCI_XHCI_INTEL_XUSB2PRM);
+DPRINTF((%s: XUSB2PRM / USB2.0 ports can switch from EHCI to xHCI:
+0x%08x\n, psc-sc.sc_bus.bdev.dv_xname, val));
+
+val = pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_USB3_PSSEN)
|
+pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_XUSB2PR);
-pci_conf_write(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_USB3_PSSEN, val);
+
+pci_conf_write(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_USB3_PSSEN,
+val usb3_mask);
+#ifdef XHCI_DEBUG
val = pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_USB3_PSSEN);
DPRINTF((%s: USB3_PSSEN / Enabled USB3.0 ports under xHCI: 0x%08x\n,
psc-sc.sc_bus.bdev.dv_xname, val));
+#endif
-/*
- * Check USB2 Port Routing Mask register that indicates the USB2.0
- * ports to be controlled by xHCI HC, and switch them to xHCI HC.
- */
-val = pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_XUSB2PRM);
-DPRINTF((%s: XUSB2PRM / USB2.0 ports can switch from EHCI to xHCI:
-0x%08x\n, psc-sc.sc_bus.bdev.dv_xname, val));
-
-pci_conf_write(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_XUSB2PR, val);
+pci_conf_write(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_XUSB2PR,
+val usb2_mask);
+#ifdef XHCI_DEBUG
val = pci_conf_read(psc-sc_pc, psc-sc_tag, PCI_XHCI_INTEL_XUSB2PR);
DPRINTF((%s: XUSB2PR / USB2.0 ports under xHCI: 0x%08x\n,
psc-sc.sc_bus.bdev.dv_xname, val));
+#endif
return (0);
}
Re: [patch] update unbound forwards with dhclient nameservers
On 2015/07/19 13:08, Gregor Best wrote:
Hello,
the following is a patch that adds an option called `update_unbound' to
dhclient.conf. With this option enabled, dhclient will call
unbound-control forwards ns1 ns2 ns3
instead of rewriting /etc/resolv.conf.
My usage scenario is that I'm running unbound on my laptop as a local
resolver. /etc/resolv.conf is configured to only use 127.0.0.1 as the
nameserver.
I'm doing this without patches, using a script run by entr (from packages)
to watch the lease file (written with -L /etc/dhclient.lease.ifname,
i.e. !dhclient -L /etc/dhclient.lease.iwn0 iwn0 in /etc/hostname.iwn0).
The code doing -L in dhclient takes care to keep the same inode for this
file specifically to support doing this.
$ cat dhcp-watcher
#!/bin/sh
gw=$(route -n get -inet 0.0.0.0 | awk '/interface/ {print $2}')
dns=$(awk '/domain-name-servers/ {gsub([;,], , $3); print $3;}'
/etc/dhclient.lease.$gw)
unbound-control forward_add . $dns /dev/null
echo default now on $gw: $(unbound-control list_forwards) | logger -t
dhcp-watcher
$ cat dhcp-watcher.run
#!/bin/sh
/etc/dhcp-watcher
echo /etc/dhclient.lease.* | tr ' ' '\n' | /usr/local/bin/entr /etc/dhcp-watcher
Re: Patch to add -f flag to cat(1)
On Sun, Jul 19, 2015 at 10:24 AM, Ingo Schwarze schwa...@usta.de wrote: ... I don't think we are vulnerable. If my analysis is accurate, the only user-controlled files we open in security(8) are ~/.rhosts and ~/.shosts in check_rhosts_content(). However, there is next unless -s $filename; right before the open(), and for fifos, -s returns false: TOCTOU race there. If they can hit the gap and move a fifo over a normal file between the test and the open, the open will hang. Should switch to sysopen() with O_NONBLOCK. Philip
Re: [patch] update unbound forwards with dhclient nameservers
On Sun, Jul 19, 2015 at 07:03:59PM +0100, Stuart Henderson wrote:
[...]
I'm uncertain about whether dhclient should do this at all, it seems
to be the opposite of the direction dhclient has been going in
recently,
[...]
I've had a similar intuition at first, but it's one less thing to run
versus the monitor lease file approach and it only calls one static
external command with relatively fixed parameters instead of what the
removed `script' option did. In the end, it's a matter of personal
taste, I think.
[...]
but if it is added, it probably wants to be disabled for the ramdisk.
[...]
I've attached an updated patch, in case this is still interesting to
someone. Do I need to add anything other than `#ifdef SMALL' in the
appropriate places?
--
Gregor Best
--
Index: clparse.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/clparse.c,v
retrieving revision 1.92
diff -u -p -r1.92 clparse.c
--- clparse.c 18 May 2015 17:51:21 - 1.92
+++ clparse.c 19 Jul 2015 18:44:12 -
@@ -75,6 +75,9 @@ read_client_conf(void)
config-backoff_cutoff = 15;
config-initial_interval = 3;
config-bootp_policy = ACCEPT;
+#ifndef SMALL
+ config-update_unbound = 0;
+#endif
config-requested_options
[config-requested_option_count++] = DHO_SUBNET_MASK;
config-requested_options
@@ -270,6 +273,12 @@ parse_client_statement(FILE *cfile)
if (parse_ip_addr(cfile, config-next_server))
parse_semi(cfile);
break;
+#ifndef SMALL
+ case TOK_UPDATE_UNBOUND:
+ config-update_unbound = 1;
+ parse_semi(cfile);
+ break;
+#endif
default:
parse_warn(expecting a statement.);
if (token != ';')
Index: conflex.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/conflex.c,v
retrieving revision 1.32
diff -u -p -r1.32 conflex.c
--- conflex.c 18 May 2015 17:51:21 - 1.32
+++ conflex.c 19 Jul 2015 18:48:00 -
@@ -341,7 +341,10 @@ static const struct keywords {
{ send, TOK_SEND },
{ server-name,TOK_SERVER_NAME },
{ supersede, TOK_SUPERSEDE },
- { timeout,TOK_TIMEOUT }
+ { timeout,TOK_TIMEOUT },
+#ifndef SMALL
+ { update-unbound, TOK_UPDATE_UNBOUND }
+#endif
};
intkw_cmp(const void *k, const void *e);
Index: dhclient.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.361
diff -u -p -r1.361 dhclient.c
--- dhclient.c 18 May 2015 14:59:42 - 1.361
+++ dhclient.c 19 Jul 2015 18:45:28 -
@@ -97,6 +97,9 @@ intres_hnok(const char *dn);
voidfork_privchld(int, int);
voidget_ifname(char *);
+#ifndef SMALL
+voidupdate_unbound_forwards(struct option_data *);
+#endif
char *resolv_conf_contents(struct option_data *,
struct option_data *);
voidwrite_resolv_conf(u_int8_t *, size_t);
@@ -903,8 +906,15 @@ bind_lease(void)
goto newlease;
}
- client-new-resolv_conf = resolv_conf_contents(
- options[DHO_DOMAIN_NAME], options[DHO_DOMAIN_NAME_SERVERS]);
+#ifndef SMALL
+ if (config-update_unbound) {
+ update_unbound_forwards(options[DHO_DOMAIN_NAME_SERVERS]);
+ } else
+#endif
+ {
+ client-new-resolv_conf = resolv_conf_contents(
+ options[DHO_DOMAIN_NAME],
options[DHO_DOMAIN_NAME_SERVERS]);
+ }
/* Replace the old active lease with the new one. */
client-active = client-new;
@@ -2043,6 +2053,91 @@ get_ifname(char *arg)
} else if (strlcpy(ifi-name, arg, IFNAMSIZ) = IFNAMSIZ)
error(Interface name too long);
}
+
+#ifndef SMALL
+/*
+ * Update unbound forwarder list
+ */
+void
+update_unbound_forwards(struct option_data *nameservers)
+{
+ char *ns;
+ int rslt;
+
+ if (!nameservers-len) {
+ return;
+ }
+
+ ns = pretty_print_option(DHO_DOMAIN_NAME_SERVERS, nameservers, 0);
+
+ rslt = imsg_compose(unpriv_ibuf, IMSG_UPDATE_UNBOUND_FORWARDS,
+ 0, 0, -1, ns, strlen(ns) + 1);
+
+ if (rslt == -1) {
+ warning(update_unbound_forwards: imsg_compose: %s,
+ strerror(errno));
+ }
+
+ flush_unpriv_ibuf(update_unbound_forwards);
+}
+
+void
+priv_update_unbound_forwards(struct imsg *imsg)
+{
+ char *args[MAXNS + 3]; /* `unbound-control', `forward', final NULL */
+ char *ns, *p, **srv;
+ int rslt, i = 0;
+ size_t sz;
+ pid_t child;
+
+ if
Re: [patch] update unbound forwards with dhclient nameservers
On Sun, Jul 19, 2015 at 01:08:46PM +0200, Gregor Best wrote:
Hello,
the following is a patch that adds an option called `update_unbound' to
dhclient.conf. With this option enabled, dhclient will call
unbound-control forwards ns1 ns2 ns3
instead of rewriting /etc/resolv.conf.
My usage scenario is that I'm running unbound on my laptop as a local
resolver. /etc/resolv.conf is configured to only use 127.0.0.1 as the
nameserver.
Oh god, yes please. I always wanted to write this diff myself ;)
More comments in the diff below.
I use this because I have a few VPN connections that have custom DNS
namespaces, which I manage with Unbound's forward zones. Since
sometimes I am in networks that have a split horizon DNS (e.g.
University, hackerspace, etc...), I can't use a statically configured
fallback forward zone for all my requests. Manually calling using
unbound-control to change the forward DNS became too annoying, so I
wrote this patch.
Does the patch make sense in OpenBSD or should I keep it as a local
change?
--
Gregor Best
--
Index: clparse.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/clparse.c,v
retrieving revision 1.92
diff -u -p -r1.92 clparse.c
--- clparse.c 18 May 2015 17:51:21 - 1.92
+++ clparse.c 9 Jul 2015 15:00:05 -
@@ -75,6 +75,7 @@ read_client_conf(void)
config-backoff_cutoff = 15;
config-initial_interval = 3;
config-bootp_policy = ACCEPT;
+ config-update_unbound = 0;
config-requested_options
[config-requested_option_count++] = DHO_SUBNET_MASK;
config-requested_options
@@ -269,6 +270,10 @@ parse_client_statement(FILE *cfile)
case TOK_NEXT_SERVER:
if (parse_ip_addr(cfile, config-next_server))
parse_semi(cfile);
+ break;
+ case TOK_UPDATE_UNBOUND:
+ config-update_unbound = 1;
+ parse_semi(cfile);
break;
default:
parse_warn(expecting a statement.);
Index: conflex.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/conflex.c,v
retrieving revision 1.32
diff -u -p -r1.32 conflex.c
--- conflex.c 18 May 2015 17:51:21 - 1.32
+++ conflex.c 9 Jul 2015 14:54:56 -
@@ -341,7 +341,8 @@ static const struct keywords {
{ send, TOK_SEND },
{ server-name,TOK_SERVER_NAME },
{ supersede, TOK_SUPERSEDE },
- { timeout,TOK_TIMEOUT }
+ { timeout,TOK_TIMEOUT },
+ { update_unbound, TOK_UPDATE_UNBOUND }
Use update-unbound (minus, not underscrore) for the keyword; also
update the man page.
};
int kw_cmp(const void *k, const void *e);
Index: dhclient.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.361
diff -u -p -r1.361 dhclient.c
--- dhclient.c18 May 2015 14:59:42 - 1.361
+++ dhclient.c9 Jul 2015 15:52:41 -
@@ -97,6 +97,7 @@ int res_hnok(const char *dn);
void fork_privchld(int, int);
void get_ifname(char *);
+void update_unbound_forwards(struct option_data *);
char *resolv_conf_contents(struct option_data *,
struct option_data *);
void write_resolv_conf(u_int8_t *, size_t);
@@ -903,8 +904,12 @@ bind_lease(void)
goto newlease;
}
- client-new-resolv_conf = resolv_conf_contents(
- options[DHO_DOMAIN_NAME], options[DHO_DOMAIN_NAME_SERVERS]);
+ if (config-update_unbound) {
+ update_unbound_forwards(options[DHO_DOMAIN_NAME_SERVERS]);
+ } else {
+ client-new-resolv_conf = resolv_conf_contents(
+ options[DHO_DOMAIN_NAME],
options[DHO_DOMAIN_NAME_SERVERS]);
+ }
/* Replace the old active lease with the new one. */
client-active = client-new;
@@ -2042,6 +2047,88 @@ get_ifname(char *arg)
close(s);
} else if (strlcpy(ifi-name, arg, IFNAMSIZ) = IFNAMSIZ)
error(Interface name too long);
+}
+
+/*
+ * Update unbound forwarder list
+ */
+void
+update_unbound_forwards(struct option_data *nameservers)
+{
+ char *ns;
+ int rslt;
+
+ if (!nameservers-len) {
+ return;
+ }
+
+ ns = pretty_print_option(DHO_DOMAIN_NAME_SERVERS, nameservers, 0);
+
+ rslt = imsg_compose(unpriv_ibuf, IMSG_UPDATE_UNBOUND_FORWARDS,
+ 0, 0, -1, ns, strlen(ns) + 1);
+
+ if (rslt == -1) {
+ warning(update_unbound_forwards: imsg_compose: %s,
+ strerror(errno));
+ }
+
+
Re: mpsafe pmaps
Mark Kettenis schreef op 2015-07-19 18:33:
So my unlocking the reaper diff that was committed the other day
breaks the MP architectures that don't have an mpsafe pmap yet (see
my commit message). Is seems hppa's pmap is actually safe enough, but
alpha, m88k, mips64 and powerpc aren't. The diff below fixes alpha
and powerpc with a big hammer. Theo is currently building snapshots
with this diff.
visa@, you'll probably want to add something similar.
miod@, mpi@, do you want me to move ahead and commit this temporary
fix?
Oops, the powerpc/include/pmap.h bit should not have been in there.
Index: alpha/alpha/pmap.c
===
RCS file: /home/cvs/src/sys/arch/alpha/alpha/pmap.c,v
retrieving revision 1.77
diff -u -p -r1.77 pmap.c
--- alpha/alpha/pmap.c 23 Jun 2015 19:50:48 - 1.77
+++ alpha/alpha/pmap.c 18 Jul 2015 18:09:42 -
@@ -1190,7 +1190,9 @@ pmap_remove(pmap_t pmap, vaddr_t sva, va
printf(pmap_remove(%p, %lx, %lx)\n, pmap, sva, eva);
#endif
+ KERNEL_LOCK();
pmap_do_remove(pmap, sva, eva, TRUE);
+ KERNEL_UNLOCK();
}
/*
Index: powerpc/include/pmap.h
===
RCS file: /home/cvs/src/sys/arch/powerpc/include/pmap.h,v
retrieving revision 1.57
diff -u -p -r1.57 pmap.h
--- powerpc/include/pmap.h 5 Jun 2015 11:38:19 - 1.57
+++ powerpc/include/pmap.h 12 Jun 2015 09:57:14 -
@@ -164,10 +164,12 @@ int reserve_dumppages(caddr_t p);
#endif /* _KERNEL */
struct vm_page_md {
+ struct mutex pv_mtx;
LIST_HEAD(,pte_desc) pv_list;
};
#define VM_MDPAGE_INIT(pg) do { \
+ mtx_init((pg)-mdpage.pv_mtx, IPL_VM); \
LIST_INIT(((pg)-mdpage.pv_list)); \
} while (0)
Index: powerpc/powerpc/pmap.c
===
RCS file: /home/cvs/src/sys/arch/powerpc/powerpc/pmap.c,v
retrieving revision 1.159
diff -u -p -r1.159 pmap.c
--- powerpc/powerpc/pmap.c 5 Jun 2015 10:15:54 - 1.159
+++ powerpc/powerpc/pmap.c 18 Jul 2015 17:37:54 -
@@ -642,6 +642,7 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
struct pte_desc *pted;
vaddr_t va;
+ KERNEL_LOCK();
PMAP_VP_LOCK(pm);
for (va = sva; va eva; va += PAGE_SIZE) {
pted = pmap_vp_lookup(pm, va);
@@ -649,6 +650,7 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
pmap_remove_pted(pm, pted);
}
PMAP_VP_UNLOCK(pm);
+ KERNEL_UNLOCK();
}
/*
Re: [patch] update unbound forwards with dhclient nameservers
On Sun, Jul 19, 2015 at 03:31:33PM +, Florian Obser wrote:
[...]
Oh god, yes please. I always wanted to write this diff myself ;)
More comments in the diff below.
[...]
Great to read. I've attached an updated patch.
--
Gregor Best
Index: clparse.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/clparse.c,v
retrieving revision 1.92
diff -u -p -r1.92 clparse.c
--- clparse.c 18 May 2015 17:51:21 - 1.92
+++ clparse.c 9 Jul 2015 15:00:05 -
@@ -75,6 +75,7 @@ read_client_conf(void)
config-backoff_cutoff = 15;
config-initial_interval = 3;
config-bootp_policy = ACCEPT;
+ config-update_unbound = 0;
config-requested_options
[config-requested_option_count++] = DHO_SUBNET_MASK;
config-requested_options
@@ -269,6 +270,10 @@ parse_client_statement(FILE *cfile)
case TOK_NEXT_SERVER:
if (parse_ip_addr(cfile, config-next_server))
parse_semi(cfile);
+ break;
+ case TOK_UPDATE_UNBOUND:
+ config-update_unbound = 1;
+ parse_semi(cfile);
break;
default:
parse_warn(expecting a statement.);
Index: conflex.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/conflex.c,v
retrieving revision 1.32
diff -u -p -r1.32 conflex.c
--- conflex.c 18 May 2015 17:51:21 - 1.32
+++ conflex.c 19 Jul 2015 17:31:13 -
@@ -341,7 +341,8 @@ static const struct keywords {
{ send, TOK_SEND },
{ server-name,TOK_SERVER_NAME },
{ supersede, TOK_SUPERSEDE },
- { timeout,TOK_TIMEOUT }
+ { timeout,TOK_TIMEOUT },
+ { update-unbound, TOK_UPDATE_UNBOUND }
};
intkw_cmp(const void *k, const void *e);
Index: dhclient.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.361
diff -u -p -r1.361 dhclient.c
--- dhclient.c 18 May 2015 14:59:42 - 1.361
+++ dhclient.c 19 Jul 2015 17:48:11 -
@@ -97,6 +97,7 @@ intres_hnok(const char *dn);
voidfork_privchld(int, int);
voidget_ifname(char *);
+voidupdate_unbound_forwards(struct option_data *);
char *resolv_conf_contents(struct option_data *,
struct option_data *);
voidwrite_resolv_conf(u_int8_t *, size_t);
@@ -903,8 +904,12 @@ bind_lease(void)
goto newlease;
}
- client-new-resolv_conf = resolv_conf_contents(
- options[DHO_DOMAIN_NAME], options[DHO_DOMAIN_NAME_SERVERS]);
+ if (config-update_unbound) {
+ update_unbound_forwards(options[DHO_DOMAIN_NAME_SERVERS]);
+ } else {
+ client-new-resolv_conf = resolv_conf_contents(
+ options[DHO_DOMAIN_NAME],
options[DHO_DOMAIN_NAME_SERVERS]);
+ }
/* Replace the old active lease with the new one. */
client-active = client-new;
@@ -2042,6 +2047,89 @@ get_ifname(char *arg)
close(s);
} else if (strlcpy(ifi-name, arg, IFNAMSIZ) = IFNAMSIZ)
error(Interface name too long);
+}
+
+/*
+ * Update unbound forwarder list
+ */
+void
+update_unbound_forwards(struct option_data *nameservers)
+{
+ char *ns;
+ int rslt;
+
+ if (!nameservers-len) {
+ return;
+ }
+
+ ns = pretty_print_option(DHO_DOMAIN_NAME_SERVERS, nameservers, 0);
+
+ rslt = imsg_compose(unpriv_ibuf, IMSG_UPDATE_UNBOUND_FORWARDS,
+ 0, 0, -1, ns, strlen(ns) + 1);
+
+ if (rslt == -1) {
+ warning(update_unbound_forwards: imsg_compose: %s,
+ strerror(errno));
+ }
+
+ flush_unpriv_ibuf(update_unbound_forwards);
+}
+
+void
+priv_update_unbound_forwards(struct imsg *imsg)
+{
+ char *args[MAXNS + 3]; /* `unbound-control', `forward', final NULL */
+ char *ns, *p, **srv;
+ int rslt, i = 0;
+ size_t sz;
+ pid_t child;
+
+ if (imsg-hdr.len IMSG_HEADER_SIZE) {
+ warning(short IMSG_UPDATE_UNBOUND_FORWARDS);
+ return;
+ }
+
+ ns = imsg-data;
+ sz = imsg-hdr.len - IMSG_HEADER_SIZE;
+ ns[sz] = '\0'; /* Make sure we're terminated properly */
+
+ /* Construct unbound-control arguments */
+ memset(args, 0, sizeof(args));
+ args[0] = unbound-control;
+ args[1] = forward;
+ srv = args[2];
+ while (i MAXNS) {
+ p = strsep(ns, );
+ if (p == NULL)
+ break;
+ if (*p == '\0')
+ continue;
+ rslt =
Re: Patch to add -f flag to cat(1)
Hi Philip,
Philip Guenther wrote on Sun, Jul 19, 2015 at 10:28:57AM -0700:
On Sun, Jul 19, 2015 at 10:24 AM, Ingo Schwarze schwa...@usta.de wrote:
I don't think we are vulnerable.
If my analysis is accurate, the only user-controlled files
we open in security(8) are ~/.rhosts and ~/.shosts
in check_rhosts_content(). However, there is
next unless -s $filename;
right before the open(), and for fifos, -s returns false:
TOCTOU race there. If they can hit the gap and move a fifo
over a normal file between the test and the open, the open
will hang. Should switch to sysopen() with O_NONBLOCK.
Oops, indeed.
OK?
Ingo
Index: security
===
RCS file: /cvs/src/libexec/security/security,v
retrieving revision 1.35
diff -u -p -r1.35 security
--- security21 Apr 2015 10:24:22 - 1.35
+++ security19 Jul 2015 18:02:38 -
@@ -22,7 +22,7 @@ use strict;
use Digest::SHA qw(sha256_hex);
use Errno qw(ENOENT);
-use Fcntl qw(:mode);
+use Fcntl qw(O_RDONLY O_NONBLOCK :mode);
use File::Basename qw(basename);
use File::Compare qw(compare);
use File::Copy qw(copy);
@@ -371,7 +371,7 @@ sub check_rhosts_content {
foreach my $base (qw(rhosts shosts)) {
my $filename = $home/.$base;
next unless -s $filename;
- nag !open(my $fh, '', $filename),
+ nag !sysopen(my $fh, $filename, O_RDONLY | O_NONBLOCK),
open: $filename: $!
and next;
local $_;
Re: [patch] update unbound forwards with dhclient nameservers
On Sun, Jul 19, 2015 at 08:53:04PM +0200, Gregor Best wrote: On Sun, Jul 19, 2015 at 07:03:59PM +0100, Stuart Henderson wrote: [...] I'm uncertain about whether dhclient should do this at all, it seems to be the opposite of the direction dhclient has been going in recently, [...] I've had a similar intuition at first, but it's one less thing to run versus the monitor lease file approach and it only calls one static external command with relatively fixed parameters instead of what the removed `script' option did. In the end, it's a matter of personal taste, I think. Indeed, I prodded krw@ to have a look / final say. If it's inaproriate for dhclient we might re-consider this for the magical manage-network-daemon if/when it shows up. As far as I'm concerned having unbound run on localhost is a sensible setup. Btw. my use case is for stupid networks that require that you use their resolvers. -- I'm not entirely sure you are real.
Re: Patch to add -f flag to cat(1)
On 19/07/2015 16:13, Ted Unangst wrote: I could maybe be convinced. However, fopen is the C standard stdio function. One reason you may be using stdio is because you want portability, so adding nonportable extensions to it seems counter productive. Understood, I'll leave it as it's not required. If you need to know about all sorts of fifos vs sockets vs files, there are a variety of posix APIs for that, portable to all posix systems. Noted :) Thanks. Sevan
Re: [patch] update unbound forwards with dhclient nameservers
I really like this idea, modulo the comments that Florian made.
On 2015 Jul 19 (Sun) at 13:08:46 +0200 (+0200), Gregor Best wrote:
:Hello,
:
:the following is a patch that adds an option called `update_unbound' to
:dhclient.conf. With this option enabled, dhclient will call
:
: unbound-control forwards ns1 ns2 ns3
:
:instead of rewriting /etc/resolv.conf.
:
:My usage scenario is that I'm running unbound on my laptop as a local
:resolver. /etc/resolv.conf is configured to only use 127.0.0.1 as the
:nameserver.
:
:I use this because I have a few VPN connections that have custom DNS
:namespaces, which I manage with Unbound's forward zones. Since
:sometimes I am in networks that have a split horizon DNS (e.g.
:University, hackerspace, etc...), I can't use a statically configured
:fallback forward zone for all my requests. Manually calling using
:unbound-control to change the forward DNS became too annoying, so I
:wrote this patch.
:
:Does the patch make sense in OpenBSD or should I keep it as a local
:change?
:
:--
: Gregor Best
:--
:
:Index: clparse.c
:===
:RCS file: /mnt/media/cvs/src/sbin/dhclient/clparse.c,v
:retrieving revision 1.92
:diff -u -p -r1.92 clparse.c
:--- clparse.c 18 May 2015 17:51:21 - 1.92
:+++ clparse.c 9 Jul 2015 15:00:05 -
:@@ -75,6 +75,7 @@ read_client_conf(void)
: config-backoff_cutoff = 15;
: config-initial_interval = 3;
: config-bootp_policy = ACCEPT;
:+ config-update_unbound = 0;
: config-requested_options
: [config-requested_option_count++] = DHO_SUBNET_MASK;
: config-requested_options
:@@ -269,6 +270,10 @@ parse_client_statement(FILE *cfile)
: case TOK_NEXT_SERVER:
: if (parse_ip_addr(cfile, config-next_server))
: parse_semi(cfile);
:+ break;
:+ case TOK_UPDATE_UNBOUND:
:+ config-update_unbound = 1;
:+ parse_semi(cfile);
: break;
: default:
: parse_warn(expecting a statement.);
:Index: conflex.c
:===
:RCS file: /mnt/media/cvs/src/sbin/dhclient/conflex.c,v
:retrieving revision 1.32
:diff -u -p -r1.32 conflex.c
:--- conflex.c 18 May 2015 17:51:21 - 1.32
:+++ conflex.c 9 Jul 2015 14:54:56 -
:@@ -341,7 +341,8 @@ static const struct keywords {
: { send, TOK_SEND },
: { server-name,TOK_SERVER_NAME },
: { supersede, TOK_SUPERSEDE },
:- { timeout,TOK_TIMEOUT }
:+ { timeout,TOK_TIMEOUT },
:+ { update_unbound, TOK_UPDATE_UNBOUND }
: };
:
: int kw_cmp(const void *k, const void *e);
:Index: dhclient.c
:===
:RCS file: /mnt/media/cvs/src/sbin/dhclient/dhclient.c,v
:retrieving revision 1.361
:diff -u -p -r1.361 dhclient.c
:--- dhclient.c 18 May 2015 14:59:42 - 1.361
:+++ dhclient.c 9 Jul 2015 15:52:41 -
:@@ -97,6 +97,7 @@ int res_hnok(const char *dn);
:
: void fork_privchld(int, int);
: void get_ifname(char *);
:+void update_unbound_forwards(struct option_data *);
: char *resolv_conf_contents(struct option_data *,
:struct option_data *);
: void write_resolv_conf(u_int8_t *, size_t);
:@@ -903,8 +904,12 @@ bind_lease(void)
: goto newlease;
: }
:
:- client-new-resolv_conf = resolv_conf_contents(
:- options[DHO_DOMAIN_NAME], options[DHO_DOMAIN_NAME_SERVERS]);
:+ if (config-update_unbound) {
:+ update_unbound_forwards(options[DHO_DOMAIN_NAME_SERVERS]);
:+ } else {
:+ client-new-resolv_conf = resolv_conf_contents(
:+ options[DHO_DOMAIN_NAME],
options[DHO_DOMAIN_NAME_SERVERS]);
:+ }
:
: /* Replace the old active lease with the new one. */
: client-active = client-new;
:@@ -2042,6 +2047,88 @@ get_ifname(char *arg)
: close(s);
: } else if (strlcpy(ifi-name, arg, IFNAMSIZ) = IFNAMSIZ)
: error(Interface name too long);
:+}
:+
:+/*
:+ * Update unbound forwarder list
:+ */
:+void
:+update_unbound_forwards(struct option_data *nameservers)
:+{
:+ char *ns;
:+ int rslt;
:+
:+ if (!nameservers-len) {
:+ return;
:+ }
:+
:+ ns = pretty_print_option(DHO_DOMAIN_NAME_SERVERS, nameservers, 0);
:+
:+ rslt = imsg_compose(unpriv_ibuf, IMSG_UPDATE_UNBOUND_FORWARDS,
:+ 0, 0, -1, ns, strlen(ns) + 1);
:+
:+ if (rslt == -1) {
:+ warning(update_unbound_forwards: imsg_compose: %s,
:+ strerror(errno));
:+ }
:+
:+ flush_unpriv_ibuf(update_unbound_forwards);
:+}
:+
:+void
:+priv_update_unbound_forwards(struct imsg
Re: mpsafe pmaps
On 19/07/15(Sun) 18:33, Mark Kettenis wrote:
So my unlocking the reaper diff that was committed the other day
breaks the MP architectures that don't have an mpsafe pmap yet (see
my commit message). Is seems hppa's pmap is actually safe enough, but
alpha, m88k, mips64 and powerpc aren't. The diff below fixes alpha
and powerpc with a big hammer. Theo is currently building snapshots
with this diff.
visa@, you'll probably want to add something similar.
miod@, mpi@, do you want me to move ahead and commit this temporary fix?
Yes please, at least for the powerpc pmap.
Index: alpha/alpha/pmap.c
===
RCS file: /home/cvs/src/sys/arch/alpha/alpha/pmap.c,v
retrieving revision 1.77
diff -u -p -r1.77 pmap.c
--- alpha/alpha/pmap.c23 Jun 2015 19:50:48 - 1.77
+++ alpha/alpha/pmap.c18 Jul 2015 18:09:42 -
@@ -1190,7 +1190,9 @@ pmap_remove(pmap_t pmap, vaddr_t sva, va
printf(pmap_remove(%p, %lx, %lx)\n, pmap, sva, eva);
#endif
+ KERNEL_LOCK();
pmap_do_remove(pmap, sva, eva, TRUE);
+ KERNEL_UNLOCK();
}
/*
Index: powerpc/include/pmap.h
===
RCS file: /home/cvs/src/sys/arch/powerpc/include/pmap.h,v
retrieving revision 1.57
diff -u -p -r1.57 pmap.h
--- powerpc/include/pmap.h5 Jun 2015 11:38:19 - 1.57
+++ powerpc/include/pmap.h12 Jun 2015 09:57:14 -
@@ -164,10 +164,12 @@ int reserve_dumppages(caddr_t p);
#endif /* _KERNEL */
struct vm_page_md {
+ struct mutex pv_mtx;
LIST_HEAD(,pte_desc) pv_list;
};
#define VM_MDPAGE_INIT(pg) do { \
+ mtx_init((pg)-mdpage.pv_mtx, IPL_VM); \
LIST_INIT(((pg)-mdpage.pv_list)); \
} while (0)
Index: powerpc/powerpc/pmap.c
===
RCS file: /home/cvs/src/sys/arch/powerpc/powerpc/pmap.c,v
retrieving revision 1.159
diff -u -p -r1.159 pmap.c
--- powerpc/powerpc/pmap.c5 Jun 2015 10:15:54 - 1.159
+++ powerpc/powerpc/pmap.c18 Jul 2015 17:37:54 -
@@ -642,6 +642,7 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
struct pte_desc *pted;
vaddr_t va;
+ KERNEL_LOCK();
PMAP_VP_LOCK(pm);
for (va = sva; va eva; va += PAGE_SIZE) {
pted = pmap_vp_lookup(pm, va);
@@ -649,6 +650,7 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
pmap_remove_pted(pm, pted);
}
PMAP_VP_UNLOCK(pm);
+ KERNEL_UNLOCK();
}
/*
Re: [patch] update unbound forwards with dhclient nameservers
On 2015/07/19 19:53, Gregor Best wrote: On Sun, Jul 19, 2015 at 03:31:33PM +, Florian Obser wrote: [...] Oh god, yes please. I always wanted to write this diff myself ;) More comments in the diff below. [...] Great to read. I've attached an updated patch. I'm uncertain about whether dhclient should do this at all, it seems to be the opposite of the direction dhclient has been going in recently, but if it is added, it probably wants to be disabled for the ramdisk.
Re: Patch to add -f flag to cat(1)
On Sun, Jul 19, 2015 at 11:04 AM, Ingo Schwarze schwa...@usta.de wrote:
Philip Guenther wrote on Sun, Jul 19, 2015 at 10:28:57AM -0700:
On Sun, Jul 19, 2015 at 10:24 AM, Ingo Schwarze schwa...@usta.de wrote:
I don't think we are vulnerable.
If my analysis is accurate, the only user-controlled files
we open in security(8) are ~/.rhosts and ~/.shosts
in check_rhosts_content(). However, there is
next unless -s $filename;
right before the open(), and for fifos, -s returns false:
TOCTOU race there. If they can hit the gap and move a fifo
over a normal file between the test and the open, the open
will hang. Should switch to sysopen() with O_NONBLOCK.
Oops, indeed.
OK?
Ingo
Index: security
===
RCS file: /cvs/src/libexec/security/security,v
retrieving revision 1.35
diff -u -p -r1.35 security
--- security21 Apr 2015 10:24:22 - 1.35
+++ security19 Jul 2015 18:02:38 -
@@ -22,7 +22,7 @@ use strict;
use Digest::SHA qw(sha256_hex);
use Errno qw(ENOENT);
-use Fcntl qw(:mode);
+use Fcntl qw(O_RDONLY O_NONBLOCK :mode);
use File::Basename qw(basename);
use File::Compare qw(compare);
use File::Copy qw(copy);
@@ -371,7 +371,7 @@ sub check_rhosts_content {
foreach my $base (qw(rhosts shosts)) {
my $filename = $home/.$base;
next unless -s $filename;
- nag !open(my $fh, '', $filename),
+ nag !sysopen(my $fh, $filename, O_RDONLY | O_NONBLOCK),
open: $filename: $!
and next;
local $_;
You need to then test the resulting file handle to verify it was a
normal file. I think just
nag !-f $fh
?
Philip
Re: enable unbound-control in default config
ok
Stuart Henderson(st...@openbsd.org) on 2015.07.19 17:55:00 +0100:
In the past, the only option for unbound-control was a TCP socket
using SSL/TLS, but nowadays it also supports unix domain sockets,
so it seems like it would be reasonable to enable it by default
in our configuration so that users added to the _unbound group
can access stats and do various types of runtime reconfiguration.
We can then also get rid of the not-squeaky-clean config check
and cert generation from the rc script.
I've been using this for ages. Any comments? OK?
srw-rw 1 _unbound _unbound 0 Jul 18 08:43 /var/run/unbound.sock
Index: rc.d/unbound
===
RCS file: /cvs/src/etc/rc.d/unbound,v
retrieving revision 1.2
diff -u -p -r1.2 unbound
--- rc.d/unbound 29 Dec 2014 11:17:43 - 1.2
+++ rc.d/unbound 19 Jul 2015 16:47:12 -
@@ -10,14 +10,6 @@ daemon_flags=-c /var/unbound/etc/unboun
pexp=unbound${daemon_flags:+ ${daemon_flags}}
rc_pre() {
- if grep '^[[:space:]]*control-enable:[[:space:]]*yes' \
- /var/unbound/etc/unbound.conf /dev/null 21 \
- ! [[ -f /var/unbound/etc/unbound_server.key ||
- -f /var/unbound/etc/unbound_server.pem ||
- -f /var/unbound/etc/unbound_control.key ||
- -f /var/unbound/etc/unbound_control.pem ]]; then
- /usr/sbin/unbound-control-setup 2 /dev/null
- fi
if grep '^[[:space:]]*auto-trust-anchor-file:' \
/var/unbound/etc/unbound.conf /dev/null 21; then
/usr/sbin/unbound-anchor -v || true
Index: unbound.conf
===
RCS file: /cvs/src/etc/unbound.conf,v
retrieving revision 1.4
diff -u -p -r1.4 unbound.conf
--- unbound.conf 2 Apr 2014 21:43:30 - 1.4
+++ unbound.conf 19 Jul 2015 16:47:12 -
@@ -37,6 +37,11 @@ server:
#
#tcp-upstream: yes
+remote-control:
+ control-enable: yes
+ control-use-cert: no
+ control-interface: /var/run/unbound.sock
+
# Use an upstream forwarder (recursive resolver) for specific zones.
# Example addresses given below are public resolvers valid as of 2014/03.
#
--
Re: Patch to add -f flag to cat(1)
Sevan Janiyan wrote: The feature was actually added to ensure whatever cat was meant to be reading from was indeed a plain file and not another which could block a process. Use cat -f to avoid denial of service attacks by people who make .rhosts files fifos. http://mail-index.netbsd.org/source-changes/2000/01/14/0069.html hmm, well, security(8) in openbsd is a perl script that doesn't exec cat, so this wouldn't help solve that problem. now, looking at security, it seems there may be an issue if it tries to open a blocking file, but that will need solving there, not in cat.
Re: Patch to add -f flag to cat(1)
Sevan Janiyan wrote: On 19/07/2015 15:35, Bob Beck wrote: The place to solve this is in whatever is using cat for this purpose. check for the file type before blindly cat'ing. Understood both your Ted's explanation regarding cat. Just so it's crisp clear, ignoring cat(1), having such a flag in fopen(2) is not of interest for use elsewhere either? I could maybe be convinced. However, fopen is the C standard stdio function. One reason you may be using stdio is because you want portability, so adding nonportable extensions to it seems counter productive. If you need to know about all sorts of fifos vs sockets vs files, there are a variety of posix APIs for that, portable to all posix systems.
mpsafe pmaps
So my unlocking the reaper diff that was committed the other day
breaks the MP architectures that don't have an mpsafe pmap yet (see
my commit message). Is seems hppa's pmap is actually safe enough, but
alpha, m88k, mips64 and powerpc aren't. The diff below fixes alpha
and powerpc with a big hammer. Theo is currently building snapshots
with this diff.
visa@, you'll probably want to add something similar.
miod@, mpi@, do you want me to move ahead and commit this temporary fix?
Index: alpha/alpha/pmap.c
===
RCS file: /home/cvs/src/sys/arch/alpha/alpha/pmap.c,v
retrieving revision 1.77
diff -u -p -r1.77 pmap.c
--- alpha/alpha/pmap.c 23 Jun 2015 19:50:48 - 1.77
+++ alpha/alpha/pmap.c 18 Jul 2015 18:09:42 -
@@ -1190,7 +1190,9 @@ pmap_remove(pmap_t pmap, vaddr_t sva, va
printf(pmap_remove(%p, %lx, %lx)\n, pmap, sva, eva);
#endif
+ KERNEL_LOCK();
pmap_do_remove(pmap, sva, eva, TRUE);
+ KERNEL_UNLOCK();
}
/*
Index: powerpc/include/pmap.h
===
RCS file: /home/cvs/src/sys/arch/powerpc/include/pmap.h,v
retrieving revision 1.57
diff -u -p -r1.57 pmap.h
--- powerpc/include/pmap.h 5 Jun 2015 11:38:19 - 1.57
+++ powerpc/include/pmap.h 12 Jun 2015 09:57:14 -
@@ -164,10 +164,12 @@ int reserve_dumppages(caddr_t p);
#endif /* _KERNEL */
struct vm_page_md {
+ struct mutex pv_mtx;
LIST_HEAD(,pte_desc) pv_list;
};
#define VM_MDPAGE_INIT(pg) do { \
+ mtx_init((pg)-mdpage.pv_mtx, IPL_VM); \
LIST_INIT(((pg)-mdpage.pv_list)); \
} while (0)
Index: powerpc/powerpc/pmap.c
===
RCS file: /home/cvs/src/sys/arch/powerpc/powerpc/pmap.c,v
retrieving revision 1.159
diff -u -p -r1.159 pmap.c
--- powerpc/powerpc/pmap.c 5 Jun 2015 10:15:54 - 1.159
+++ powerpc/powerpc/pmap.c 18 Jul 2015 17:37:54 -
@@ -642,6 +642,7 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
struct pte_desc *pted;
vaddr_t va;
+ KERNEL_LOCK();
PMAP_VP_LOCK(pm);
for (va = sva; va eva; va += PAGE_SIZE) {
pted = pmap_vp_lookup(pm, va);
@@ -649,6 +650,7 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
pmap_remove_pted(pm, pted);
}
PMAP_VP_UNLOCK(pm);
+ KERNEL_UNLOCK();
}
/*
enable unbound-control in default config
In the past, the only option for unbound-control was a TCP socket
using SSL/TLS, but nowadays it also supports unix domain sockets,
so it seems like it would be reasonable to enable it by default
in our configuration so that users added to the _unbound group
can access stats and do various types of runtime reconfiguration.
We can then also get rid of the not-squeaky-clean config check
and cert generation from the rc script.
I've been using this for ages. Any comments? OK?
srw-rw 1 _unbound _unbound 0 Jul 18 08:43 /var/run/unbound.sock
Index: rc.d/unbound
===
RCS file: /cvs/src/etc/rc.d/unbound,v
retrieving revision 1.2
diff -u -p -r1.2 unbound
--- rc.d/unbound29 Dec 2014 11:17:43 - 1.2
+++ rc.d/unbound19 Jul 2015 16:47:12 -
@@ -10,14 +10,6 @@ daemon_flags=-c /var/unbound/etc/unboun
pexp=unbound${daemon_flags:+ ${daemon_flags}}
rc_pre() {
- if grep '^[[:space:]]*control-enable:[[:space:]]*yes' \
- /var/unbound/etc/unbound.conf /dev/null 21 \
- ! [[ -f /var/unbound/etc/unbound_server.key ||
- -f /var/unbound/etc/unbound_server.pem ||
- -f /var/unbound/etc/unbound_control.key ||
- -f /var/unbound/etc/unbound_control.pem ]]; then
- /usr/sbin/unbound-control-setup 2 /dev/null
- fi
if grep '^[[:space:]]*auto-trust-anchor-file:' \
/var/unbound/etc/unbound.conf /dev/null 21; then
/usr/sbin/unbound-anchor -v || true
Index: unbound.conf
===
RCS file: /cvs/src/etc/unbound.conf,v
retrieving revision 1.4
diff -u -p -r1.4 unbound.conf
--- unbound.conf2 Apr 2014 21:43:30 - 1.4
+++ unbound.conf19 Jul 2015 16:47:12 -
@@ -37,6 +37,11 @@ server:
#
#tcp-upstream: yes
+remote-control:
+ control-enable: yes
+ control-use-cert: no
+ control-interface: /var/run/unbound.sock
+
# Use an upstream forwarder (recursive resolver) for specific zones.
# Example addresses given below are public resolvers valid as of 2014/03.
#
Re: Patch to add -f flag to cat(1)
Hi, Ted Unangst wrote on Sun, Jul 19, 2015 at 10:26:19AM -0400: Sevan Janiyan wrote: The feature was actually added to ensure whatever cat was meant to be reading from was indeed a plain file and not another which could block a process. Use cat -f to avoid denial of service attacks by people who make .rhosts files fifos. http://mail-index.netbsd.org/source-changes/2000/01/14/0069.html hmm, well, security(8) in openbsd is a perl script that doesn't exec cat, so this wouldn't help solve that problem. now, looking at security, it seems there may be an issue if it tries to open a blocking file, but that will need solving there, not in cat. I don't think we are vulnerable. If my analysis is accurate, the only user-controlled files we open in security(8) are ~/.rhosts and ~/.shosts in check_rhosts_content(). However, there is next unless -s $filename; right before the open(), and for fifos, -s returns false: Both test(1) and perl(1) consider fifos zero-length, so security(8) won't attempt to open such fifos. I confirmed that by creating such a fifo in my home directory, and security(8) did not hang, but it did complain about some permissions on the fifo. So, i don't see any need for action at this point. (Andrew, do you agree?) Yours, Ingo
