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 cl...@fab-it.dk 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 '%IF' 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 pkgname suitably # ( cd /usr/ports/pobj/pkgname/pkgname patch -p 1 $PATCHFILE ) then, if patch applied cleanly[*] # make update [* else get source from ISC, extract, cd pkgdir, # 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 cl...@fab-it.dk 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 '%IF' 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 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: prefix::1 is the server IPv6 address and prefix::2 is the client IPv6 address. Given that, I think the following is true: - prefix::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, prefix::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 net prefix 64'. Then point rtadvd at that interface. -Ed
Re: ifconfig command for IPv6 tunnel
On Wed, 20 Aug 2014, Charles Musser wrote:
On Aug 20, 2014, at 4:15 AM, Ed Hynan eh_l...@optonline.net wrote:
On Tue, 19 Aug 2014, Charles Musser wrote:
- prefix::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.
grin 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
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 stdio.h
#ifdef BUILDPROG
#ifdef LOADRUNTIME
#include dlfcn.h
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
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: 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
Re: login.conf default openfiles
On Mon, 4 Aug 2014, Philip Guenther wrote: On Sat, Aug 2, 2014 at 7:06 AM, Ed Hynan eh_l...@optonline.net 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
Re: login.conf default openfiles
On Tue, 5 Aug 2014, Philip Guenther wrote: On Tue, Aug 5, 2014 at 6:49 AM, Ed Hynan eh_l...@optonline.net 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
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
