pf route-to issues
every few years i try and use route-to in pf, and every time it goes badly. i tried it again last week in a slightly different setting, and actually tried to understand the sharp edges i hit this time instead of giving up. it turns out there are 2 or 3 different things together that have cause me trouble, which is why the diff below is so big. the first and i would argue most fundamental problem is a semantic problem. if you ask a random person who has some clue about networks and routing what they would expect the "argument" to route-to or reply-to to be, they would say "a nexthop address" or "a gateway address". eg, say i want to force packets to a specific backend server without using NAT, i would write a rule like this: n_servers="192.0.2.128/27" pass out on $if_internal to $n_servers route-to 192.168.0.1 pfctl will happily parse this, shove it into the kernel, let you read the rules back out again with pfctl -sr, and it all looks plausible, but it turns out that it's using the argument to route-to as an interface name. because rulesets can refer to interfaces that don't exist yet, pf just passes the IP address around as a string, hoping i'll plug in an interface with a driver name that looks like an ip address. i spent literally a day trying to figure out why a rule like this wasn't working. i happened to be talking to pascoe@ at the time, and his vague memory was that the idea was to try and switch the interface a packet was going to travel over, but to try and reuse the arp lookup from the parent one. neither of us could figure out why that would be a good idea though. the best i can say about this is that it only really makes some kind of sense if you're moving a packet into a tunnel. tunnels don't really care about nexthops and will happily route anything you give them. if you were trying to add a route to the routing table to do this, you'd be specifying the peer address on a tunnel interface as the gateway. pf has a if0:peer syntax that makes this convenient to write. so i want to change route-to in pfctl so it takes a nexthop instead of an interface. you could argue that pf already lets you do this, because there's some bs nexthop@interface syntax. my counter argument is that the interface the nexthop is reachable over is redundant, and it makes fixing some of the other problems harder if we keep it. the second and third problems i hit are when route-to is used on a pair of boxes that have pfsync and pfsync defer set up. when defer is enabled, pfsync takes the packet away from the forwarding path, and when it has some confidence that the peer is aware of the state, then it tries to push the packet back out. to understand the following, be aware that route-to, reply-to, and dup-to are implemented in pf in a pair of functions called pf_route and pf_route6. if i say pf_route, just assume i'm talking about both of these functions. the second problem is that the pf_route calls from pfsync don't have all the information it is supposed to have. more specifically, an ifp pointer isn't set which leads to a segfault. the ifp pointer isn't set because pfsync doesnt track which interface a packet is going out, it assumes the ip layer will get it right again later, or a rule provided something usable. the third problem is that pf_route relies on information from rules to work correctly. this is a problem in a pfsync environment because you cannot have the same ruleset on both firewalls 100% of the time, which means you cannot have route-to/reply-to behave consistently on a pair of firwalls 100% of the time. my solution to both these problems is reduce the amount of information pf_route needs to work with, to make sure that the info it does need is in the pf state structure, and that pfsync handles it properly. if we limit the information needed for pf_route to a nexthop address, and which direction the address is used, this is doable. both the pf_state and pfsync_state structs already contain an address to store a nexthop in, i just had to move the route-to direction from the rule into the state. this is easy with pf_state, but i used a spare pad field in pfsync_state for this. the pf_state struct has had which interface the route is using removed. there's no simple way to sync interface information between pfsync peers on the wire, and the need for them is marginal at best. things are much simpler if we can get away with not having this info. a bonus problem i hit is that there's code in pf_match that appears to try and short circuit some processing of states when route-to/reply-to is in effect. this has two consequences. first, if you're using route-to with tcp states, half the tcp state machine is is skipped. when you look at these states with pfctl -vvss, one half of the TCP state never moves forward. secondly, because the processing is short circuited, it never falls through to the end of pf_test where the actual call to pf_route is done. so the first packet is properly handled by
Re: [EXTERNAL] Happy 25th Birthday OpenBSD!
Congratulations. I remember trying to install OpenBSD sometime right after Theo started it. For the at the time FreeBSD user I struggled with the OpenBSD install. I remember sending an email to Theo and he basically told me if I couldn't figure out how to install OpenBSD I shouldn't be using it. Instead of getting pissed off I figured out how to install OpenBSD and have been running it ever since. diana -Original Message- From: owner-t...@openbsd.org On Behalf Of Bob Beck Sent: Sunday, October 18, 2020 9:45 AM To: tech@openbsd.org Subject: [EXTERNAL] Happy 25th Birthday OpenBSD! Yeah, it's just a number. But it's been a pretty wild ride. Thanks everyone for 25 years. -Bob
Re: Happy 25th Birthday OpenBSD!
Happy birthday puffy!! Neon King wrote: > 25 years as free , functional and secure . Happy birthday ! > > Jerome > > Le dim. 18 oct. 2020 à 18:48, Bryan Steele a écrit : > > > On Sun, Oct 18, 2020 at 09:44:52AM -0600, Bob Beck wrote: > > > > > > Yeah, it's just a number. > > > > > > But it's been a pretty wild ride. Thanks everyone for 25 years. > > > > > > -Bob > > > > > > > > > > > > > > > > Happy 25th everybody! \o/ > > > > -Bryan. > > > >
Re: net.inet.ip.forwarding=0 vs lo(4)
On Sun, Oct 18, 2020 at 08:57:34PM +0100, Stuart Henderson wrote:
> On 2020/10/18 14:04, David Gwynne wrote:
> > the problem i'm hitting is that i have a multihomed box where the
> > service it provides listens on an IP address that's assigned to lo1.
> > it's a host running a service, it's not a router, so the
> > net.inet.ip.forwarding sysctl is not set to 1.
>
> I ran into this, I just turned on the forwarding sysctl to avoid the
> problem.
>
> > i came up with this diff, which adds even more special casing for
> > loopback interfaces. it says addreesses on loopbacks are globally
> > reachable, even if ip forwarding is disabled.
>
> I don't see why loopbacks should be special. Another place this
> might show up is services running on carp addresses (I haven't updated
> those machines yet but there's a fair chance they'll be affected too).
> I would prefer an explicit sysctl to disable "strong host model".
loopback is already special. if a packet comes from an loopback
interface, we allow it to talk to any IP on the local machine. i think
this is mostly to cope with the semantic we've had where local traffic
get's tied to a loopback interface instead of going anywhere near the
physical ones.
carp is also special.
let me paste the ip_laddr function instead of the diff to it, it's a bit
more obvious what's going on:
int
ip_laddr(struct ifnet *ifp, struct mbuf *m, struct rtentry *rt)
{
struct ifnet *rtifp;
int match = 0;
if (rt->rt_ifidx == ifp->if_index ||
ifp->if_type == IFT_ENC ||
ISSET(ifp->if_flags, IFF_LOOPBACK) ||
ISSET(m->m_pkthdr.pf.flags, PF_TAG_TRANSLATE_LOCALHOST))
return (1);
/* received on a different interface. */
rtifp = if_get(rt->rt_ifidx);
if (rtifp != NULL) {
if (ISSET(rtifp->if_flags, IFF_LOOPBACK))
match = 1;
#if NCARP > 0
/*
* Virtual IPs on carp interfaces need to be checked also
* against the parent interface and other carp interfaces
* sharing the same parent.
*/
else if (carp_strict_addr_chk(rtifp, ifp))
match = 1;
#endif
}
if_put(rtifp);
return (match);
}
the only thing i've added above is the
ISSET(rtifp->if_flags, IFF_LOOPBACK) check. everything else is already
in place.
here's the code for carp_strict_addr_chk:
/*
* If two carp interfaces share same physical interface, then we pretend all IP
* addresses belong to single interface.
*/
static inline int
carp_strict_addr_chk(struct ifnet *ifp_a, struct ifnet *ifp_b)
{
return ((ifp_a->if_type == IFT_CARP &&
ifp_b->if_index == ifp_a->if_carpdevidx) ||
(ifp_b->if_type == IFT_CARP &&
ifp_a->if_index == ifp_b->if_carpdevidx) ||
(ifp_a->if_type == IFT_CARP && ifp_b->if_type == IFT_CARP &&
ifp_a->if_carpdevidx == ifp_b->if_carpdevidx));
}
back to loopback and receiving packets. loopback is special because it
is not connected to the outside world. it is impossible to send a packet
via a loopback interface from another host, so configuring a globally
(externally) routable IP on it is currently pointless unless you enable
forwarding. i think making loopback more special and allowing it
to be globally reachable makes sense. i can't think of any downsides to
this at the moment, except that the behaviour would be subtle/not
obvious
is there a need to configure a globally reachable IP on a non-loopback
interface on a host (not router)? if so, then i'd be more convinced that
we need a separate lever to pull.
Re: net.inet.ip.forwarding=0 vs lo(4)
On 2020/10/18 14:04, David Gwynne wrote: > the problem i'm hitting is that i have a multihomed box where the > service it provides listens on an IP address that's assigned to lo1. > it's a host running a service, it's not a router, so the > net.inet.ip.forwarding sysctl is not set to 1. I ran into this, I just turned on the forwarding sysctl to avoid the problem. > i came up with this diff, which adds even more special casing for > loopback interfaces. it says addreesses on loopbacks are globally > reachable, even if ip forwarding is disabled. I don't see why loopbacks should be special. Another place this might show up is services running on carp addresses (I haven't updated those machines yet but there's a fair chance they'll be affected too). I would prefer an explicit sysctl to disable "strong host model".
arm64: save/restore FPCR in setjmp/longjmp
There are some free slots, so we can just save it directly after the FPU registers. This is needed to fix the lib/libc/setjmp-fpu regress on arm64. But it isn't enough. Because the hardware doesn't implement the floating-point exception trap control bits, checking those bits can't work on arm64 (and armv7). So the 2nd part of this diff sprinkles some #if/#endif to skip the parts that check those bits. ok? Index: lib/libc/arch/aarch64/gen/_setjmp.S === RCS file: /cvs/src/lib/libc/arch/aarch64/gen/_setjmp.S,v retrieving revision 1.3 diff -u -p -r1.3 _setjmp.S --- lib/libc/arch/aarch64/gen/_setjmp.S 1 Oct 2018 22:49:50 - 1.3 +++ lib/libc/arch/aarch64/gen/_setjmp.S 18 Oct 2020 19:22:40 - @@ -53,7 +53,9 @@ ENTRY(_setjmp) stp d8, d9, [x0], #16 stp d10, d11, [x0], #16 stp d12, d13, [x0], #16 - stp d14, d15, [x0] + stp d14, d15, [x0], #16 + mrs x1, fpcr + str x1, [x0] #endif /* Return value */ @@ -92,7 +94,9 @@ ENTRY(_longjmp) ldp d8, d9, [x0], #16 ldp d10, d11, [x0], #16 ldp d12, d13, [x0], #16 - ldp d14, d15, [x0] + ldp d14, d15, [x0], #16 + ldr x2, [x0] + msr fpcr, x2 #endif /* Load the return value */ Index: lib/libc/arch/aarch64/gen/setjmp.S === RCS file: /cvs/src/lib/libc/arch/aarch64/gen/setjmp.S,v retrieving revision 1.3 diff -u -p -r1.3 setjmp.S --- lib/libc/arch/aarch64/gen/setjmp.S 1 Oct 2018 22:49:50 - 1.3 +++ lib/libc/arch/aarch64/gen/setjmp.S 18 Oct 2020 19:22:40 - @@ -61,7 +61,9 @@ ENTRY(setjmp) stp d8, d9, [x0], #16 stp d10, d11, [x0], #16 stp d12, d13, [x0], #16 - stp d14, d15, [x0] + stp d14, d15, [x0], #16 + mrs x1, fpcr + str x1, [x0] /* Return value */ mov x0, #0 @@ -108,7 +110,9 @@ ENTRY(longjmp) ldp d8, d9, [x0], #16 ldp d10, d11, [x0], #16 ldp d12, d13, [x0], #16 - ldp d14, d15, [x0] + ldp d14, d15, [x0], #16 + ldr x1, [x0] + msr fpcr, x1 /* Load the return value */ cmp w3, #0 Index: regress/lib/libc/setjmp-fpu/fpu.c === RCS file: /cvs/src/regress/lib/libc/setjmp-fpu/fpu.c,v retrieving revision 1.1 diff -u -p -r1.1 fpu.c --- regress/lib/libc/setjmp-fpu/fpu.c 16 Jan 2020 13:04:02 - 1.1 +++ regress/lib/libc/setjmp-fpu/fpu.c 18 Oct 2020 19:34:28 - @@ -34,10 +34,12 @@ main(int argc, char *argv[]) rv = fegetround(); if (rv != FE_UPWARD) errx(1, "fegetround returned %d, not FE_UPWARD", rv); +#if !defined(__arm__) && !defined(__aarch64__) rv = fegetexcept(); if (rv != FE_DIVBYZERO) errx(1, "fegetexcept returned %d, not FE_DIVBYZERO", rv); +#endif /* Verify that the FPU exception flags weren't clobbered. */ flag = 0; Index: regress/lib/libc/setjmp-fpu/setjmp-fpu.c === RCS file: /cvs/src/regress/lib/libc/setjmp-fpu/setjmp-fpu.c,v retrieving revision 1.5 diff -u -p -r1.5 setjmp-fpu.c --- regress/lib/libc/setjmp-fpu/setjmp-fpu.c16 Jan 2020 13:04:02 - 1.5 +++ regress/lib/libc/setjmp-fpu/setjmp-fpu.c18 Oct 2020 19:34:28 - @@ -42,10 +42,12 @@ TEST_SETJMP(void) rv = fegetround(); if (rv != FE_UPWARD) errx(1, "fegetround returned %d, not FE_UPWARD", rv); +#if !defined(__arm__) && !defined(__aarch64__) rv = fegetexcept(); if (rv != FE_DIVBYZERO) errx(1, "fegetexcept returned %d, not FE_DIVBYZERO", rv); +#endif /* Verify that the FPU exception flags weren't clobbered. */ flag = 0;
Re: Happy 25th Birthday OpenBSD!
25 years as free , functional and secure . Happy birthday ! Jerome Le dim. 18 oct. 2020 à 18:48, Bryan Steele a écrit : > On Sun, Oct 18, 2020 at 09:44:52AM -0600, Bob Beck wrote: > > > > Yeah, it's just a number. > > > > But it's been a pretty wild ride. Thanks everyone for 25 years. > > > > -Bob > > > > > > > > > > Happy 25th everybody! \o/ > > -Bryan. > >
Re: Happy 25th Birthday OpenBSD!
On Sun, Oct 18, 2020 at 09:44:52AM -0600, Bob Beck wrote: > > Yeah, it's just a number. > > But it's been a pretty wild ride. Thanks everyone for 25 years. > > -Bob > > > > Happy 25th everybody! \o/ -Bryan.
Happy 25th Birthday OpenBSD!
Yeah, it's just a number. But it's been a pretty wild ride. Thanks everyone for 25 years. -Bob
Re: net.inet.ip.forwarding=0 vs lo(4)
On Sun, Oct 18, 2020 at 02:04:31PM +1000, David Gwynne wrote: > or is there a way i can do this without a diff already? > I am also curious... > thoughts? > The diff works as advertise.
Re: httpd(8): server/location directory index question
It appears the patch can be far more simple.
Comments are welcome.
Index: usr.sbin/httpd/config.c
===
RCS file: /cvs/src/usr.sbin/httpd/config.c,v
retrieving revision 1.61
diff -u -p -u -p -r1.61 config.c
--- usr.sbin/httpd/config.c 21 Sep 2020 09:42:07 - 1.61
+++ usr.sbin/httpd/config.c 18 Oct 2020 12:09:36 -
@@ -489,7 +489,12 @@ config_getserver_config(struct httpd *en
/* Inherit configuration from the parent */
f = SRVFLAG_INDEX|SRVFLAG_NO_INDEX;
if ((srv_conf->flags & f) == 0) {
- srv_conf->flags |= parent->flags & f;
+ /*
+* Inherit index flags from parent server only if
+* auto-index flag of location is not set
+*/
+ if ((srv_conf->flags & SRVFLAG_AUTO_INDEX) == 0)
+ srv_conf->flags |= parent->flags & f;
(void)strlcpy(srv_conf->index, parent->index,
sizeof(srv_conf->index));
}
On 2020-10-17 14:49, m...@fn.de wrote:
> Given the following httpd.conf snippet
>
> server "example.com" {
> ...
> directory no index
> ...
> location "/foo" {
> ...
> directory auto index
> ...
> }
> }
>
> the URL http://example.com/foo surprisingly results in a 403
> response.
>
> With the directory option of the "/foo" location changed to
>
> location "/foo" {
> directory {
> index "index.html"
> auto index
> }
> }
>
> the auto-index is being generated (as expected).
>
> I was wondering if there is any reason why the 'auto index' of
> the location shouldn't implicitly override the 'no index' option
> of the enclosing server (as it happens with the patch below).
>
>
>
> Index: usr.sbin/httpd/config.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/config.c,v
> retrieving revision 1.61
> diff -u -p -u -p -r1.61 config.c
> --- usr.sbin/httpd/config.c 21 Sep 2020 09:42:07 - 1.61
> +++ usr.sbin/httpd/config.c 17 Oct 2020 12:26:20 -
> @@ -488,11 +488,10 @@ config_getserver_config(struct httpd *en
> if (srv_conf->flags & SRVFLAG_LOCATION) {
> /* Inherit configuration from the parent */
> f = SRVFLAG_INDEX|SRVFLAG_NO_INDEX;
> - if ((srv_conf->flags & f) == 0) {
> + if ((srv_conf->flags & f) == 0)
> srv_conf->flags |= parent->flags & f;
> - (void)strlcpy(srv_conf->index, parent->index,
> - sizeof(srv_conf->index));
> - }
> + (void)strlcpy(srv_conf->index, parent->index,
> + sizeof(srv_conf->index));
>
> f = SRVFLAG_AUTO_INDEX|SRVFLAG_NO_AUTO_INDEX;
> if ((srv_conf->flags & f) == 0)
> Index: usr.sbin/httpd/parse.y
> ===
> RCS file: /cvs/src/usr.sbin/httpd/parse.y,v
> retrieving revision 1.118
> diff -u -p -u -p -r1.118 parse.y
> --- usr.sbin/httpd/parse.y11 Oct 2020 03:21:44 - 1.118
> +++ usr.sbin/httpd/parse.y17 Oct 2020 12:26:20 -
> @@ -1006,6 +1006,8 @@ dirflags: INDEX STRING {
> srv_conf->flags |= SRVFLAG_NO_INDEX;
> }
> | AUTO INDEX{
> + srv_conf->flags &= ~SRVFLAG_NO_INDEX;
> + srv_conf->flags |= SRVFLAG_INDEX;
> srv_conf->flags &= ~SRVFLAG_NO_AUTO_INDEX;
> srv_conf->flags |= SRVFLAG_AUTO_INDEX;
> }
>
Re: fonttosfnt: merge changes to fix fonts for new pango
On Fri, Oct 09, 2020 at 09:39:37AM +0200, Christopher Zimmermann wrote: > > Hi Matthieu, > > you already gave an ok some time ago to merge changes to fonttosfnt. Now > that my changes have been tested and merged upstream I'd like to integrate > them into xenocara. May I ask for another ok? Sorry I should have reacted faster. I've asked Peter Hutterer to make a formal release of xfonttosfnt 1.1.1 with your commits upstreams. In the long run it makes things easier to follow if we can just upgrade to the upstream version. May I ask you for a few more days of waiting ? If nothing happens on the xorg side in the next 3 days, then ok to commit the changes locally. -- Matthieu Herrb
