Re: kernel reordering and config -e
On Mon, 20 Nov 2017, Theo de Raadt wrote: If someone wants to solve this fully there have been some proposals for keeping track of the instruction sequence, and attempting to reapply it upon each relink in the build directory. There just hasn't been any scripting changes to do that from anyone, and it isn't on my radar as important. How about making reorder_kernel do something like: $ if test -f /etc/ukc.conf; then Hmm... I can't seem to find a patch in there anywhere. No patch from OP yet, so how about this: for someone needing config -e it's probably sufficient if /usr/libexec/reorder_kernel checks for a post-processing script, and invokes it if present and executable. If the patch is acceptable, I'll post a sample post-processing script that, for config -f -e, should only need one parameter change for specific needs. Patch (against 6.2 stable): --- usr/libexec/reorder_kernel.orig Tue Oct 3 23:13:27 2017 +++ usr/libexec/reorder_kernel Wed Nov 22 09:30:27 2017 @@ -30,6 +30,8 @@ LOGFILE=$COMPILE_DIR/$KERNEL/relink.log PROGNAME=${0##*/} SHA256=/var/db/kernel.SHA256 +# optional local postprocessing, e.g. config -e +POSTPROC=/etc/after-karl # Create kernel compile dir and redirect stdout/stderr to a logfile. mkdir -m 700 -p $COMPILE_DIR/$KERNEL @@ -55,6 +57,11 @@ cd $COMPILE_DIR/$KERNEL make newbsd make newinstall + +# optional local postprocessing, e.g. config -e +if [[ -f $POSTPROC && -x $POSTPROC ]]; then + "$POSTPROC" /bsd "$SHA256" /dev/stdout +fi echo "\nKernel has been relinked and is active on next reboot.\n" cat $SHA256
Re: DHCPv6 server - send_packet6: Network is unreachable
[ I tried sending this Monday morning; I just a DSN for failure -- so trying again, from different address. ] On Mon, 24 Aug 2015, Claus Lensbøl wrote: > On 18-08-2015 21:32, Ed Hynan wrote: >> >>> From: Claus Lensbøl >>> I am running openbsd 5.6 GENERIC.MP#333 amd64. >>> Using isc-dhcp-server 4.3.0. >> >> I had no route to host w/ ISC DHCP 4.3.0 on OpenBSD 4.9 -- the >> patch at end of message got it working. Hint was need for >> '%' using ping6. >> >> I applied the patch on OpenBSD 5.5 w/o checking whether >> it's needed -- still works. I don't know about 5.6 (as he >> ducks his head). >> >> NOTE: patch applies to ISC tar archive -- I did not start from >> ports, so I don't know if it'll apply to patched ports source. >> Try it if you like. Good luck. >> >> -Ed >> >> # BEGIN PATCH >> diff -u -r dhcp-4.3.0-orig/common/socket.c dhcp-4.3.0/common/socket.c >> --- dhcp-4.3.0-orig/common/socket.cFri Jan 31 14:20:49 2014 >> +++ dhcp-4.3.0/common/socket.cTue Aug 18 15:11:42 2015 >> @@ -787,9 +787,19 @@ >> memcpy(&dst, to, sizeof(dst)); >> m.msg_name = &dst; >> m.msg_namelen = sizeof(dst); >> +/* >> + * For OpenBSD 4.9, needing interface index: this works in >> + * my usage on small LAN; might not be complete or correct >> + * Works w/ OpenBSD 5.5 -- did not check if still needed! >> + * The preprocessor test is added . . . >> + */ >> +#if defined(__OpenBSD__) >> +dst.sin6_scope_id = ifindex = if_nametoindex(interface->name); >> +#else /* ! defined(__OpenBSD__) */ >> ifindex = if_nametoindex(interface->name); >> if (no_global_v6_socket) >> dst.sin6_scope_id = ifindex; >> +#endif /* ! defined(__OpenBSD__) */ >> >> /* >> * Set the data buffer we're sending. (Using this wacky > Hi Ed > > Where is this patch from? Me. > And could you give me some building guidelines? I haven't tried building on > OpenBSD before. OpenBSD ports(7) -- get ports source, cd to package dir, then # make patch then, substituting suitably # ( cd /usr/ports/pobj// && patch -p 1 < $PATCHFILE ) then, if patch applied cleanly[*] # make update [* else get source from ISC, extract, cd , # patch -p 1 < $PATCHFILE then edit bind/bind-9.9.5/lib/isc/random.c and comment out line 'arc4random_addrandom((u_char *) &seed, sizeof(isc_uint32_t));' then preferably configure with install --prefix other than /usr/local. # make && make install ] > > Thank you! > Claus > You're welcome, Ed -- Constantly choosing the lesser of two evils is still choosing evil. - Jerry Garcia, Rolling Stone magazine, November 30, 1989
Re: DHCPv6 server - send_packet6: Network is unreachable
> From: Claus Lensbøl > I am running openbsd 5.6 GENERIC.MP#333 amd64. > Using isc-dhcp-server 4.3.0. I had no route to host w/ ISC DHCP 4.3.0 on OpenBSD 4.9 -- the patch at end of message got it working. Hint was need for '%' using ping6. I applied the patch on OpenBSD 5.5 w/o checking whether it's needed -- still works. I don't know about 5.6 (as he ducks his head). NOTE: patch applies to ISC tar archive -- I did not start from ports, so I don't know if it'll apply to patched ports source. Try it if you like. Good luck. -Ed # BEGIN PATCH diff -u -r dhcp-4.3.0-orig/common/socket.c dhcp-4.3.0/common/socket.c --- dhcp-4.3.0-orig/common/socket.c Fri Jan 31 14:20:49 2014 +++ dhcp-4.3.0/common/socket.c Tue Aug 18 15:11:42 2015 @@ -787,9 +787,19 @@ memcpy(&dst, to, sizeof(dst)); m.msg_name = &dst; m.msg_namelen = sizeof(dst); + /* +* For OpenBSD 4.9, needing interface index: this works in +* my usage on small LAN; might not be complete or correct +* Works w/ OpenBSD 5.5 -- did not check if still needed! +* The preprocessor test is added . . . +*/ +#if defined(__OpenBSD__) + dst.sin6_scope_id = ifindex = if_nametoindex(interface->name); +#else /* ! defined(__OpenBSD__) */ ifindex = if_nametoindex(interface->name); if (no_global_v6_socket) dst.sin6_scope_id = ifindex; +#endif /* ! defined(__OpenBSD__) */ /* * Set the data buffer we're sending. (Using this wacky
Re: ifconfig command for IPv6 tunnel
On Wed, 20 Aug 2014, Charles Musser wrote: On Aug 20, 2014, at 4:15 AM, Ed Hynan wrote: On Tue, 19 Aug 2014, Charles Musser wrote: - ::1 is the local address of the interface on the IPv6 network. No, *::2 is local. Ah, yes. Despite my best efforts at copyediting, I had the meanings of *::1 and *::2 reversed. - The "alias" parameter is superfluous in this case. I tried it without that and got the same result: an operating tunnel. If it works, ifconfig is being smart, but why not make your intent explicit? The tunnel is across the ip4 addresses; this command adds aliases, or close enough. Stated another way: the alias keyword doesn't do any harm here, but using it makes things harder to understand because this isn't actually an alias; it's a local address and a remote address and this pair comprises the endpoints of a point-to-point link. Although this is a little more complex on gif than e.g. an ethernet interface, alias is at least similar. On a more straightforward type interface, alias is used adding additional addresses (BTW, not OpenBSD specific, the alias keyword is similar for {Net,Free}BSD; and, apparently dissimilar on Linux). Think of the IPv6 addrs as 'additional' after IPv4 tunnel addrs for conceptual satisfaction. It's ambiguous when you write "the server IP" because the remote end of the tunnel is a server, and if you're configuring a router rather than a host then that's a server too. Addr *:2 is local in that it's an address of your gif(4) interface. The ifconfig(8) synopsis is simpler than gif configuration, but yes *::2 is like "dest_address". Just to clarify, this setup is currently a host, not a router. Given all that, ::2 is the local address and ::1 is remote. Doesn't that make ::1 the "dest_address"? Note: possible beating of dead horse here. Feel free to say: "stop obsessing over the syntax of this command, dummy." Yes, *::1 is like dest_address; I miswrote and should have said *::2 is like "address" in the synopsis (had just woke up). IAC *::2 is local, software on the machine may have that as source address, not *::1. Addr *::1 is remote. Try 'netstat -nvrf inet6 | grep 2001:' and find that *::1 has the G (gateway) flag, and host *::2 has a route to *::1. Output of that is: default2001:470:1f04:204::1 UGS6 146 - 8 gif0 2001:470:1f04:204::1 2001:470:1f04:204::2 UH 1 0 - 4 gif0 2001:470:1f04:204::2 link#6 UHL0 0 - 4 lo0 This is different than what you describe, but it makes sense. I think. Is it different? Your output shows what I intended to describe. Line 1 with G flag shows that 'gateway' addr *::1 is default route and line 2 with H flag shows 'host' addr *::2 has/is a route to *::1 (didn't I suggest that clearly on my 1st coffee? I think I did). Also look at something using the interface, maybe ntpd. Look at the address with 'netstat -nvf inet6 | grep 123' (no -r there), and see that *::2 is local. Output is: Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address(state) tcp6 0 0 2001:470:1f04:204::2.32069 2001:200:dff:fff1:216:3eff:feb1:44d7.80 ESTABLISHED tcp6 0 0 2001:470:1f04:204::2.7 2001:200:dff:fff1:216:3eff:feb1:44d7.80 ESTABLISHED tcp6 0 0 2001:470:1f04:204::2.30221 2001:200:dff:fff1:216:3eff:feb1:44d7.80 ESTABLISHED tcp6 0 0 2001:470:1f04:204::2.3173 2001:200:dff:fff1:216:3eff:feb1:44d7.80 ESTABLISHED tcp6 0 0 2001:470:1f04:204::2.27980 2001:200:dff:fff1:216:3eff:feb1:44d7.80 ESTABLISHED tcp6 0 0 2001:470:1f04:204::2.48945 2001:200:dff:fff1:216:3eff:feb1:44d7.80 ESTABLISHED This seems to confirm what you said. The local endpoint is indeed *::2. Looks good. Since this is a host never mind rtadvd (I had mentioned that). You'll want to handle IPv6 in pf generally. Since you didn't mention it I suppose you're not strictly firewalling; you would have mentioned allowing proto 41 for the ip4 remote endpoint or maybe you've got that all set. -Ed -- Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson
Re: ifconfig command for IPv6 tunnel
On Tue, 19 Aug 2014, Charles Musser wrote: Hi, I'm experimenting with using IPv6 via a tunnel broker provided by an ISP. The tunnel works, but I want to confirm my understanding of the commands they gave me to set it up. These are the commands: ifconfig gif0 tunnel 50.1.94.112 72.52.104.74 ifconfig gif0 inet6 alias 2001:470:1f04:204::2 2001:470:1f04:204::1 prefixlen 128 route -n add -inet6 default 2001:470:1f04:204::1 The first and third commands make sense to me; they set up an IPv4 tunnel interface and a default route for IPv6. After reading the ifconfig(8) man page) I think I sort of understand what the second one does. Side note: the two IPv6 addresses provided by the tunnel broker are defined, in their terminology, as follows: ::1 is the "server IPv6 address" and ::2 is the "client IPv6 address". Given that, I think the following is true: - ::1 is the local address of the interface on the IPv6 network. No, *::2 is local. - The "alias" parameter is superfluous in this case. I tried it without that and got the same result: an operating tunnel. If it works, ifconfig is being smart, but why not make your intent explicit? The tunnel is across the ip4 addresses; this command adds aliases, or close enough. - Because gif0 is a point-to-point interface, ::2 (the server IP) is interpreted as the "dest_address" parameter mentioned in the ifconfig(8) man page. It's ambiguous when you write "the server IP" because the remote end of the tunnel is a server, and if you're configuring a router rather than a host then that's a server too. Addr *:2 is local in that it's an address of your gif(4) interface. The ifconfig(8) synopsis is simpler than gif configuration, but yes *::2 is like "dest_address". Addr *::1 is remote. Try 'netstat -nvrf inet6 | grep 2001:' and find that *::1 has the G (gateway) flag, and host *::2 has a route to *::1. Also look at something using the interface, maybe ntpd. Look at the address with 'netstat -nvf inet6 | grep 123' (no -r there), and see that *::2 is local. HE likely provided you a /64 prefix for your use, or maybe you have to request it (I have an HE tunnel but don't remember all details; their website is helpful). Those addrs would be in a different /48 than the tunnel addrs. If you're setting up a router your assigned /64 prefix can be assigned to an internal interface with "alias" like 'inet6 alias 64'. Then point rtadvd at that interface. -Ed
dlsym(): same symbols in prog and lib, segfault
This is with 5.5 release on i386 (32 bit). When main program has more than one function pointer declared with the *same names* as functions in a shared library, and initializes one (at least) with the symbol from that library with dlsym(), and references the second in some way (take address, dereference/call. etc.), and the shared library calls the second function, then the program segfaults at the point of the lib making that call, but after ld.so has printed messages like: "WARNING: symbol(fn_02) size mismatch, relink your program" apparently one for each reference to that symbol in either the main program or library. This is reliably repeatable, and is probably easier to understand in code than in my description, so a near-minimal program and Makefile are appended to this message. For the test prog try: # bug % make clean; make # workaround 1 -- initialize symbol in main prog % make clean; make fix # workaround 2 -- do not reference symbol in prog % make clean; make fix2 # still bug, different output (FPIC defaults empty) % make clean; make FPIC="-fPIC" I'm sure this was not a problem with OpenBSD 4.9 because the code that raised the issue was fine on that. -Ed FILES: /** BEGIN dltst.c */ #include #ifdef BUILDPROG #ifdef LOADRUNTIME #include void (*fn_01)(); #if FIXHACK == 1 void (*fn_02)() = 0; #else void (*fn_02)(); #endif void loadsyms() { /* * RTLD_LAZY reorders "size mismatch, relink your program" * message and backtrace is different, but segfaults IAC */ void* handle = dlopen(DLTST_SONAME, RTLD_NOW); fn_01 = dlsym(handle, "fn_01"); /* a reference to fn_02 (here and main()) will trigger bug */ #if FIXHACK != 2 fn_02 = dlsym(handle, "fn_02"); #endif } #else /* LOADRUNTIME */ void fn_01(); void fn_02(); void loadsyms() { } #endif /* LOADRUNTIME */ int main() { loadsyms(); /* look at addresses *of* and *in* pointers */ printf("From main prog; fn_01 at %p points to %p\n", &fn_01, fn_01); #if FIXHACK != 2 printf("From main prog; fn_02 at %p points to %p\n", &fn_02, fn_02); #endif /* call 1st func only; it calls the 2nd within so */ fn_01(); return 0; } #else /* BUILDPROG */ /* this section compiles for shared lib */ void fn_02() { void (*p)() = fn_02; /* look at this func address */ printf("From shared lib; %s at %p\n", __FUNCTION__, p); } void fn_01() { void (*p)() = fn_01; /* look at this func address */ printf("From shared lib; %s at %p\n", __FUNCTION__, p); p = fn_02; /* look at *2nd* func address; before segfault */ printf("From shared lib; %s -- fn_02 is at %p\n", __FUNCTION__, p); fn_02(); } #endif /* BUILDPROG */ /** END dltst.c */ ## BEGIN Makefile NAME = dltst SONAME = lib$(NAME) SRC = $(NAME).c SOSRC = so_$(NAME).c PROG = $(NAME)_lt PROGRT = $(NAME)_rt SO = $(SONAME).so # not for OpenBSD, but others use -ldl #LIBS = -ldl LIBS = # pic difference? yes, but still gets message and segfault #FPIC = -fPIC FPIC = # default: build and run program w/ runtime loading that will segfault all: run_rt # 1st run prog w/o runtime loading (no core), then as above both check compare: run_lt run_rt # workaround: initialize (assign 0) pertinent global symbol: no segfault fix: rm -f $(PROGRT) make CFLAGS="$(CFLAGS) -DFIXHACK=1" run_rt # workaround: declare but do not reference pertinent global symbol: no segfault fix2: rm -f $(PROGRT) make CFLAGS="$(CFLAGS) -DFIXHACK=2" run_rt run_rt: $(PROGRT) @echo === running $(PROGRT) -- runtime load LD_LIBRARY_PATH=$$PWD ./$(PROGRT) run_lt: $(PROG) @echo === running $(PROG) -- implicit link LD_LIBRARY_PATH=$$PWD ./$(PROG) $(SO) mk_so: $(SOSRC) $(CC) $(CFLAGS) -shared $(FPIC) -o $(SO) $(SOSRC) $(PROG) mk_prog_lt: $(SRC) $(SO) $(CC) $(CFLAGS) -DBUILDPROG -o $(PROG) $(SRC) $(LIBS) -L$$PWD -l$(NAME) # make program using runtime loading $(PROGRT) mk_prog_rt: $(SRC) $(SO) $(CC) $(CFLAGS) -DBUILDPROG -DLOADRUNTIME -DDLTST_SONAME=\"$(SO)\" -o $(PROGRT) $(SRC) $(LIBS) # copy source to new name for so; this is for clarity in gdb $(SOSRC): $(SRC) @rm -f $@; cp -p $(SRC) $@ clean: rm -f $(PROG) $(PROGRT) $(SO) $(SOSRC) *.core core ## END Makefile
Re: OpenSSL static
On Mon, 11 Aug 2014, Theo de Raadt wrote: Do any of the system's static binaries use lib(ssl|crypto).a? A few use -lcrypto: iked isakmpd dc ftp Only one uses -lssl and -lcrypto: ftp Thanks for the prompt reply. dc! That caught me by surprise. -Ed
OpenSSL static
The latest openssl patch was announced on the announce list. Do any of the system's static binaries use lib(ssl|crypto).a? -Ed
Re: login.conf default openfiles
On Tue, 5 Aug 2014, Philip Guenther wrote: On Tue, Aug 5, 2014 at 6:49 AM, Ed Hynan wrote: Failure to set the resource limits isn't considered fatal for setusercontext(). It would be Bad if a typo there could leave you unable to login or su to root... Agreed. My case is a less drastic example: it's good that that su succeeded so the job could run. The new log message is good too, I'm glad I saw it and could respond. BTW, setusercontext(3) does not mention that setting resource failure is not fatal. So, the absence openfiles-max in the original login.conf is intentional? Before that log message, I was never prompted to think this through this far. It wasn't necessary to set them, so why over-specify them? IIRC, we had actually increased the defaults not too long ago to handle the increased demands of stuff like gnome and firefox. If we wrote out all the limits, then upgrades would be more painful as more lines would have to change. I suppose higher limits are easier all around, particularly re. the sort of software you mention. I recall changing menus to use a wrapper script because firefox was exceeding a files soft limit (NetBSD 2.0 I think, but that's beside the point). OTOH, lower limits expose more bad code. Just mentioning that, not suggesting OpenBSD shouldn't increase limits. -Ed
Re: login.conf default openfiles
On Mon, 4 Aug 2014, Philip Guenther wrote: On Sat, Aug 2, 2014 at 7:06 AM, Ed Hynan wrote: Saturday morning, saw this in /var/log/messages: "Aug 2 08:29:12 lucy su: default: setting resource limit openfiles: Invalid argument" (BTW, I quoted a line I produced by hand: the time is wrong, should have been approx. 03:30. The rest is the same.) That indicates that the requested -cur value was greater than the requested -max value, if any, or the current -max value if no change to the max was requested. Yes... -cur in the default class is 512, and ... # echo "ulimit -n" | su -m nobody 256 # echo "ulimit -nH" | su -m nobody 384 I'm running the commands in a root shell. I set openfiles-cur=256 and openfiles-max=384 for the daemon class, which is root's class according to userinfo root. [*] So, after putting the original login.conf in place, and su - root again on another pty, ulimit -nH is 768 (although the value 768 does not appear in the original login.conf). Soft limit is 128. OK, it seems I've triggered the log message by reducing openfiles-max in the daemon class, which is root's, but the interesting thing is that the su command succeeds. That's from /etc/weekly, which uses 'su -m nobody' for locate db update on line 52. The log message can be produced by hand with, e.g.: # echo /bin/echo FOO | SHELL=/bin/sh nice -5 su -m nobody invoked by root. Hmm, I'm unable to reproduce that on my 5.6 system. Compare the output of ulimit -nH and the openfiles-cur value in the login.conf. On my system, the normal hard (i.e., -max) limit is 1024; is that not the case on yours? If so, where is the smaller value coming from? The root .profile? Some other system config file? Inherited from a lower limit on your personal account when you su'ed to root? See above. [*] why such limits, you may ask. Simply old and limited hardware, in the role of home lan gateway router. I wanted to try tighter limits, and use so far suggests they are not a problem for the daemons in use. Last uptime before switch to 5.5: 408 days, but would have been about 3 years if not for power failures outlasting the UPS. So, I feel confident in those limits. Actually, those limits were in place before 4.9, but I forget when. They seem OK. BTW, I jumped from 4.9 to 5.5 so the 4.9 login.conf is the most recent I have handy. The 4.9 login.conf likewise has only openfiles-cur in default:, but I don't think I've seen that log message before. Some verbosity recently added? The setrlimit() syscall was changed to comply with POSIX and return an error instead of (iirc) silently clamping the soft limit to the hard limit. OK, I see the message is logged in lib/libc/gen/login_cap.c::gsetrl() after setrlimit() fails (gsetrl() then returns -1). Thanks for pointing that out; message is clear now. setusercontext(3) does not fail at the gsetrl() failure; it proceeds anyway. That explains why the log message is the only symptom and the /etc/weekly job succeeds. So, the absence openfiles-max in the original login.conf is intentional? Before that log message, I was never prompted to think this through this far. -Ed
login.conf default openfiles
Saturday morning, saw this in /var/log/messages: "Aug 2 08:29:12 lucy su: default: setting resource limit openfiles: Invalid argument" That's from /etc/weekly, which uses 'su -m nobody' for locate db update on line 52. The log message can be produced by hand with, e.g.: # echo /bin/echo FOO | SHELL=/bin/sh nice -5 su -m nobody invoked by root. Checking userinfo nobody shows no login class, so presumably default: applies. I installed the original login.conf from etc55.tgz. Same message; anyway, I hadn't edited default:. The default: entry has openfiles-cur, but not -max. According to login.conf(5) resource limit entries without -{cur,max} will specify both, but using -{cur,max} specifies that limit individually. So, using only foo-cur leaves foo-max unspecified. Adding openfiles-max and checking again, no message is logged. BTW, I jumped from 4.9 to 5.5 so the 4.9 login.conf is the most recent I have handy. The 4.9 login.conf likewise has only openfiles-cur in default:, but I don't think I've seen that log message before. Some verbosity recently added? -Ed -- The rights you have are the rights given you by this Committee [the House Un-American Activities Committee]. We will determine what rights you have and what rights you have not got. -- J. Parnell Thomas