Re: softraid(4): fix wrong malloc size and zero sized free calls
On Mon, May 13, 2019 at 07:25:37PM -0400, Ted Unangst wrote:
> Jan Klemkow wrote:
> > The diff mainly add sizes to free(9) calls. But, while here fix a
> > malloc(9) call with the wrong size in sr_ioctl_installboot().
> > omi->omi_som is allocated with size of struct sr_meta_crypto, but used
> > as struct sr_meta_boot later.
> >
> > One free(9) with size zero left over in sr_discipline_free(). As, the
> > allocated size of sd->sd_vol.sv_chunks is not ascertainable here without
> > larger changes.
> >
> > Build and run the kernel for testing.
>
> The change in installboot for the size is suspicious. I would leave that out.
> Especially if you haven't tested installboot to a crypto softraid. :)
Here is a diff with just the fixed free sizes. Malloc size fix comes
separately.
OK?
Index: dev/softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.392
diff -u -p -r1.392 softraid.c
--- dev/softraid.c 2 May 2018 02:24:55 - 1.392
+++ dev/softraid.c 14 May 2019 05:13:02 -
@@ -1470,28 +1470,29 @@ unwind:
for (bc1 = SLIST_FIRST(>sbv_chunks); bc1 != NULL;
bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
- free(bc1->sbc_metadata, M_DEVBUF, 0);
- free(bc1, M_DEVBUF, 0);
+ free(bc1->sbc_metadata, M_DEVBUF,
+ sizeof(*bc1->sbc_metadata));
+ free(bc1, M_DEVBUF, sizeof(*bc1));
}
- free(bv1, M_DEVBUF, 0);
+ free(bv1, M_DEVBUF, sizeof(*bv1));
}
/* Free keydisks chunks. */
for (bc1 = SLIST_FIRST(); bc1 != NULL; bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
- free(bc1->sbc_metadata, M_DEVBUF, 0);
- free(bc1, M_DEVBUF, 0);
+ free(bc1->sbc_metadata, M_DEVBUF, sizeof(*bc1->sbc_metadata));
+ free(bc1, M_DEVBUF, sizeof(*bc1));
}
/* Free unallocated chunks. */
for (bc1 = SLIST_FIRST(); bc1 != NULL; bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
- free(bc1->sbc_metadata, M_DEVBUF, 0);
- free(bc1, M_DEVBUF, 0);
+ free(bc1->sbc_metadata, M_DEVBUF, sizeof(*bc1->sbc_metadata));
+ free(bc1, M_DEVBUF, sizeof(*bc1));
}
while (!SLIST_EMPTY()) {
sdk = SLIST_FIRST();
SLIST_REMOVE_HEAD(, sdk_link);
- free(sdk, M_DEVBUF, 0);
+ free(sdk, M_DEVBUF, sizeof(*sdk));
}
free(devs, M_DEVBUF, BIOC_CRMAXLEN * sizeof(dev_t));
@@ -1751,7 +1752,7 @@ sr_hotplug_unregister(struct sr_discipli
if (mhe != NULL) {
SLIST_REMOVE(_hotplug_callbacks, mhe,
sr_hotplug_list, shl_link);
- free(mhe, M_DEVBUF, 0);
+ free(mhe, M_DEVBUF, sizeof(*mhe));
}
}
@@ -1953,7 +1954,7 @@ sr_ccb_free(struct sr_discipline *sd)
while ((ccb = TAILQ_FIRST(>sd_ccb_freeq)) != NULL)
TAILQ_REMOVE(>sd_ccb_freeq, ccb, ccb_link);
- free(sd->sd_ccb, M_DEVBUF, 0);
+ free(sd->sd_ccb, M_DEVBUF, sizeof(*sd->sd_ccb));
}
struct sr_ccb *
@@ -2132,7 +2133,7 @@ sr_wu_free(struct sr_discipline *sd)
while ((wu = TAILQ_FIRST(>sd_wu)) != NULL) {
TAILQ_REMOVE(>sd_wu, wu, swu_next);
- free(wu, M_DEVBUF, 0);
+ free(wu, M_DEVBUF, sizeof(*wu));
}
}
@@ -2966,13 +2967,14 @@ sr_hotspare(struct sr_softc *sc, dev_t d
goto done;
fail:
- free(hotspare, M_DEVBUF, 0);
+ free(hotspare, M_DEVBUF, sizeof(*hotspare));
done:
if (sd)
- free(sd->sd_vol.sv_chunks, M_DEVBUF, 0);
- free(sd, M_DEVBUF, 0);
- free(sm, M_DEVBUF, 0);
+ free(sd->sd_vol.sv_chunks, M_DEVBUF,
+ sizeof(sd->sd_vol.sv_chunks));
+ free(sd, M_DEVBUF, sizeof(*sd));
+ free(sm, M_DEVBUF, sizeof(*sm));
if (open) {
VOP_CLOSE(vn, FREAD | FWRITE, NOCRED, curproc);
vput(vn);
@@ -3079,7 +3081,7 @@ sr_hotspare_rebuild(struct sr_discipline
/* Remove hotspare from available list. */
sc->sc_hotspare_no--;
SLIST_REMOVE(cl, hotspare, sr_chunk, src_link);
- free(hotspare, M_DEVBUF, 0);
+ free(hotspare, M_DEVBUF, sizeof(*hotspare));
}
rw_exit_write(>sc_lock);
@@ -3375,7 +3377,7 @@ sr_ioctl_createraid(struct sr_softc *sc,
>sd_meta->ssdi.ssd_uuid);
sr_error(sc, "disk %s is currently in use; "
"cannot force create", uuid);
- free(uuid, M_DEVBUF, 0);
+
Don't use '.Sx' to refer to external sections
It was mentioned previously that the use of .Sx to refer to a section in
a different manual page is incorrect. I grepped through the src tree to
see if there were any cases of this and I found a couple.
diff --git a/share/man/man4/inet6.4 b/share/man/man4/inet6.4
index f64eedbfb..ddeb27136 100644
--- a/share/man/man4/inet6.4
+++ b/share/man/man4/inet6.4
@@ -161,11 +161,7 @@ For setups which tunnel IPv6 over IPv4,
see
.Xr gif 4 .
.Pp
-The
-.Sx INET6
-and
-.Sx TUNNEL
-sections of
+The INET6 and TUNNEL sections of
.Xr ifconfig 8
contain information relevant to IPv6 setups;
settings can be made permanent using
diff --git a/share/man/man4/ip6.4 b/share/man/man4/ip6.4
index 8acb7a762..a40b78f3a 100644
--- a/share/man/man4/ip6.4
+++ b/share/man/man4/ip6.4
@@ -94,7 +94,8 @@ struct ip6_hdr {
All fields are in network-byte order.
Any options specified (see
.Sx Options
-below) must also be specified in network-byte order.
+below)
+must also be specified in network-byte order.
.Pp
.Va ip6_flow
specifies the flow ID.
diff --git a/share/man/man9/syscall.9 b/share/man/man9/syscall.9
index 6a20b052e..1eb78609f 100644
--- a/share/man/man9/syscall.9
+++ b/share/man/man9/syscall.9
@@ -175,9 +175,9 @@ else
.Pp
The
.Dq SYSCALL_DEBUG
-parts of the code are explained in the section
+parts of the code are explained in the
.Sx Debugging
-later in the document.
+section below.
For the
.Dq KTRACE
portions of the code refer to the
diff --git a/usr.bin/ssh/ssh_config.5 b/usr.bin/ssh/ssh_config.5
index b8ba4022a..cb9018580 100644
--- a/usr.bin/ssh/ssh_config.5
+++ b/usr.bin/ssh/ssh_config.5
@@ -1327,9 +1327,7 @@ and
.Sq 4G ,
depending on the cipher.
The optional second value is specified in seconds and may use any of the
-units documented in the
-.Sx TIME FORMATS
-section of
+units documented in the TIME FORMATS section of
.Xr sshd_config 5 .
The default value for
.Cm RekeyLimit
diff --git a/usr.bin/ssh/sshd_config.5 b/usr.bin/ssh/sshd_config.5
index 9e97701ed..d018fd5a2 100644
--- a/usr.bin/ssh/sshd_config.5
+++ b/usr.bin/ssh/sshd_config.5
@@ -278,9 +278,7 @@ is not, then
will refuse to start.
.It Cm AuthorizedKeysFile
Specifies the file that contains the public keys used for user authentication.
-The format is described in the
-.Sx AUTHORIZED_KEYS FILE FORMAT
-section of
+The format is described in the AUTHORIZED_KEYS FILE FORMAT section of
.Xr sshd 8 .
Arguments to
.Cm AuthorizedKeysFile
diff --git a/usr.sbin/vmctl/vmctl.8 b/usr.sbin/vmctl/vmctl.8
index 144d774c8..0a7195a3c 100644
--- a/usr.sbin/vmctl/vmctl.8
+++ b/usr.sbin/vmctl/vmctl.8
@@ -208,8 +208,8 @@ configure a gateway address on the VM host side,
and run a simple DHCP/BOOTP server for the VM.
See
.Sx LOCAL INTERFACES
-below for more information on how addresses are calculated and assigned when
-using the
+below for more information on how addresses are calculated and assigned
+when using the
.Fl L
option.
.It Fl m Ar size
@@ -220,9 +220,7 @@ The default is 512M.
.It Fl n Ar switch
Add a network interface that is attached to the specified virtual
.Ar switch .
-See
-.Sx SWITCH CONFIGURATION
-in
+See the SWITCH CONFIGURATION section in
.Xr vm.conf 5
for more information.
.It Fl r Ar path
diff --git a/usr.sbin/vmd/vm.conf.5 b/usr.sbin/vmd/vm.conf.5
index 54eb9ed5e..fcb43d57a 100644
--- a/usr.sbin/vmd/vm.conf.5
+++ b/usr.sbin/vmd/vm.conf.5
@@ -331,11 +331,7 @@ is pre-configured using
.Xr hostname.if 5
or
.Xr ifconfig 8
-(see the
-.Sx BRIDGE
-and
-.Sx SWITCH
-sections in
+(see the BRIDGE and SWITCH sections in
.Xr ifconfig 8
accordingly).
When a VM is started, virtual network interfaces which are assigned to a
--
Stephen Gregoratto
PGP: 3FC6 3D0E 2801 C348 1C44 2D34 A80C 0F8E 8BAB EC8B
Re: softraid(4): fix wrong malloc size and zero sized free calls
Jan Klemkow wrote: > Hi, > > The diff mainly add sizes to free(9) calls. But, while here fix a > malloc(9) call with the wrong size in sr_ioctl_installboot(). > omi->omi_som is allocated with size of struct sr_meta_crypto, but used > as struct sr_meta_boot later. > > One free(9) with size zero left over in sr_discipline_free(). As, the > allocated size of sd->sd_vol.sv_chunks is not ascertainable here without > larger changes. > > Build and run the kernel for testing. The change in installboot for the size is suspicious. I would leave that out. Especially if you haven't tested installboot to a crypto softraid. :)
softraid(4): fix wrong malloc size and zero sized free calls
Hi,
The diff mainly add sizes to free(9) calls. But, while here fix a
malloc(9) call with the wrong size in sr_ioctl_installboot().
omi->omi_som is allocated with size of struct sr_meta_crypto, but used
as struct sr_meta_boot later.
One free(9) with size zero left over in sr_discipline_free(). As, the
allocated size of sd->sd_vol.sv_chunks is not ascertainable here without
larger changes.
Build and run the kernel for testing.
OK?
Bye,
Jan
Index: dev/softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.392
diff -u -p -r1.392 softraid.c
--- dev/softraid.c 2 May 2018 02:24:55 - 1.392
+++ dev/softraid.c 13 May 2019 22:40:04 -
@@ -1470,28 +1470,29 @@ unwind:
for (bc1 = SLIST_FIRST(>sbv_chunks); bc1 != NULL;
bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
- free(bc1->sbc_metadata, M_DEVBUF, 0);
- free(bc1, M_DEVBUF, 0);
+ free(bc1->sbc_metadata, M_DEVBUF,
+ sizeof(*bc1->sbc_metadata));
+ free(bc1, M_DEVBUF, sizeof(*bc1));
}
- free(bv1, M_DEVBUF, 0);
+ free(bv1, M_DEVBUF, sizeof(*bv1));
}
/* Free keydisks chunks. */
for (bc1 = SLIST_FIRST(); bc1 != NULL; bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
- free(bc1->sbc_metadata, M_DEVBUF, 0);
- free(bc1, M_DEVBUF, 0);
+ free(bc1->sbc_metadata, M_DEVBUF, sizeof(*bc1->sbc_metadata));
+ free(bc1, M_DEVBUF, sizeof(*bc1));
}
/* Free unallocated chunks. */
for (bc1 = SLIST_FIRST(); bc1 != NULL; bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
- free(bc1->sbc_metadata, M_DEVBUF, 0);
- free(bc1, M_DEVBUF, 0);
+ free(bc1->sbc_metadata, M_DEVBUF, sizeof(*bc1->sbc_metadata));
+ free(bc1, M_DEVBUF, sizeof(*bc1));
}
while (!SLIST_EMPTY()) {
sdk = SLIST_FIRST();
SLIST_REMOVE_HEAD(, sdk_link);
- free(sdk, M_DEVBUF, 0);
+ free(sdk, M_DEVBUF, sizeof(*sdk));
}
free(devs, M_DEVBUF, BIOC_CRMAXLEN * sizeof(dev_t));
@@ -1751,7 +1752,7 @@ sr_hotplug_unregister(struct sr_discipli
if (mhe != NULL) {
SLIST_REMOVE(_hotplug_callbacks, mhe,
sr_hotplug_list, shl_link);
- free(mhe, M_DEVBUF, 0);
+ free(mhe, M_DEVBUF, sizeof(*mhe));
}
}
@@ -1953,7 +1954,7 @@ sr_ccb_free(struct sr_discipline *sd)
while ((ccb = TAILQ_FIRST(>sd_ccb_freeq)) != NULL)
TAILQ_REMOVE(>sd_ccb_freeq, ccb, ccb_link);
- free(sd->sd_ccb, M_DEVBUF, 0);
+ free(sd->sd_ccb, M_DEVBUF, sizeof(*sd->sd_ccb));
}
struct sr_ccb *
@@ -2132,7 +2133,7 @@ sr_wu_free(struct sr_discipline *sd)
while ((wu = TAILQ_FIRST(>sd_wu)) != NULL) {
TAILQ_REMOVE(>sd_wu, wu, swu_next);
- free(wu, M_DEVBUF, 0);
+ free(wu, M_DEVBUF, sizeof(*wu));
}
}
@@ -2966,13 +2967,14 @@ sr_hotspare(struct sr_softc *sc, dev_t d
goto done;
fail:
- free(hotspare, M_DEVBUF, 0);
+ free(hotspare, M_DEVBUF, sizeof(*hotspare));
done:
if (sd)
- free(sd->sd_vol.sv_chunks, M_DEVBUF, 0);
- free(sd, M_DEVBUF, 0);
- free(sm, M_DEVBUF, 0);
+ free(sd->sd_vol.sv_chunks, M_DEVBUF,
+ sizeof(sd->sd_vol.sv_chunks));
+ free(sd, M_DEVBUF, sizeof(*sd));
+ free(sm, M_DEVBUF, sizeof(*sm));
if (open) {
VOP_CLOSE(vn, FREAD | FWRITE, NOCRED, curproc);
vput(vn);
@@ -3079,7 +3081,7 @@ sr_hotspare_rebuild(struct sr_discipline
/* Remove hotspare from available list. */
sc->sc_hotspare_no--;
SLIST_REMOVE(cl, hotspare, sr_chunk, src_link);
- free(hotspare, M_DEVBUF, 0);
+ free(hotspare, M_DEVBUF, sizeof(*hotspare));
}
rw_exit_write(>sc_lock);
@@ -3375,7 +3377,7 @@ sr_ioctl_createraid(struct sr_softc *sc,
>sd_meta->ssdi.ssd_uuid);
sr_error(sc, "disk %s is currently in use; "
"cannot force create", uuid);
- free(uuid, M_DEVBUF, 0);
+ free(uuid, M_DEVBUF, 37);
goto unwind;
}
@@ -3439,7 +3441,7 @@ sr_ioctl_createraid(struct sr_softc *sc,
if (sr_already_assembled(sd)) {
uuid = sr_uuid_format(>sd_meta->ssdi.ssd_uuid);
sr_error(sc, "disk %s already
Re: add newline for tpm0: dmesg line
f. holop wrote: > dmesg: > > ... > acpibtn2 at acpi0: PWRB > tpm0 at acpi0: TPM_ addr 0xfed4/0x5000acpivideo0 at acpi0: GFX0 > acpivout0 at acpivideo0: DD1F > ... thanks
Re: [PATCH] portgen(1) man page: Add py type
On Mon, May 13, 2019 at 02:51:54PM -0700, Andrew Hewus Fresh wrote:
> On Mon, May 13, 2019 at 10:05:16AM -0700, Andrew Hewus Fresh wrote:
> > On Mon, May 13, 2019 at 07:37:36AM +0100, Stuart Henderson wrote:
> > > As far as plists go, unless the port only supports py2 or only supports
> > > py3,
> > > it ought to generate the plist with FLAVOR=python3 and then prefix any
> > > lines
> > > ending in ${MODPY_PYCACHE}/ with ${MODPY_COMMENT}.
> >
> > I think kmos@ explained this to me correctly, but if someone wants to
> > write down the why this needs to happen again I'll happily add it as a
> > comment to this magic.
>
> So this pointed out an issue to me due to this patch. As I understood
> it, I could attach "${MODPY_FLAVOR}" indiscriminately to all the
> depends, but this error tells me that's probably not true. Do I need to
> only add the flavor if the dependent has a python3 flavor?
>
> ===> Updating plist for py3-pytest-4.5.0
> Fatal: Unknown flavor(s) python3 (in devel/py-funcsigs)
>(No flavors for this port). (in devel/py-funcsigs)
> *** Error 1 in /usr/ports/devel/py-funcsigs
> (/usr/ports/infrastructure/mk/bsd.port.mk:3564 '.BEGIN': @exit 1)
> Problem with dependency STEM->=1.0:devel/py-funcsigs,python3
This was a bit annoying, but kmos@ explained that he really meant that
we need to tack on the MODPY_FLAVOR only if the dependency *has* a
python3 flavor. This sounds a bit error-prone if a port suddenly
sprouts a python3 flavor, but that's unrelated to portgen.
Anyway, this patch checks the flavors of the dependency before adding
MODPY_FLAVOR, which is how I understood what kurt said.
Comments, OK?
Index: infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm
===
RCS file: /cvs/ports/infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm,v
retrieving revision 1.12
diff -u -p -r1.12 PyPI.pm
--- infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm 12 May 2019 20:23:33
- 1.12
+++ infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm 13 May 2019 22:48:50
-
@@ -21,8 +21,10 @@ use warnings;
use parent 'OpenBSD::PortGen::Port';
+use Cwd;
+
use OpenBSD::PortGen::Dependency;
-use OpenBSD::PortGen::Utils qw( module_in_ports );
+use OpenBSD::PortGen::Utils qw( base_dir ports_dir module_in_ports );
sub ecosystem_prefix
{
@@ -155,11 +157,30 @@ sub get_deps
next if @plat and join( " ", @plat ) !~ /OpenBSD/i;
- my $port = module_in_ports( $name, 'py-' )
- || $self->name_new_port($name);
+ my $port = module_in_ports( $name, 'py-' );
+ my $dep_dir = ports_dir() . '/' . $port;
+
+ # don't have it in tree, port it
+ unless ( $port ) {
+ $port = $self->name_new_port($name);
+ $dep_dir = base_dir() . '/' . $port;
+
+ my $o = OpenBSD::PortGen::Port::PyPI->new();
+ $o->port($name);
+ $self->add_notice( $o->notices );
+ }
my $base_port = $port;
- $port .= '${MODPY_FLAVOR}';
+
+ {
+ my $old_cwd = getcwd();
+ chdir $dep_dir || die "Unable to chdir $dep_dir: $!";
+ my $flavors = $self->make_show('FLAVORS');
+ chdir $old_cwd || die "Unable to chdir $old_cwd: $!";
+
+ # Attach the flavor if the dependency has one
+ $port .= '${MODPY_FLAVOR}' if $flavors =~ /\bpython3\b/;
+ }
if ( $phase eq 'build' ) {
$deps->add_build( $port, $req );
@@ -175,13 +196,6 @@ sub get_deps
"Added $base_port as 'run' dep, wanted
'$phase'")
unless $phase eq 'run';
$deps->add_run( $port, $req );
- }
-
- # don't have it in tree, port it
- if ( $port =~ m{^pypi/} ) {
- my $o = OpenBSD::PortGen::Port::PyPI->new();
- $o->port($name);
- $self->add_notice( $o->notices );
}
}
bgpd communities rewrite
This diff changes the way communites are stored and modified in bgpd.
The current implementation was showing that community_*_delete() consumed
a lot of CPU time because of the way rde_attr was used.
Communities are extensivly used by filters (e.g. arouteserver) and
therefor they are stored in an own special datastructure that allows fast
changes especially during filtering. The communities are now a special
part of the filterstate and because of this set and delete of a community
is much simpler.
This seems to make my test setup a fair bit snappier and quicker at
processing UPDATEs.
--
:wq Claudio
Index: usr.sbin/bgpctl/bgpctl.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.236
diff -u -p -r1.236 bgpctl.c
--- usr.sbin/bgpctl/bgpctl.c3 May 2019 01:48:42 - 1.236
+++ usr.sbin/bgpctl/bgpctl.c12 May 2019 15:25:13 -
@@ -81,6 +81,7 @@ intshow_rib_detail_msg(struct imsg *,
voidshow_rib_brief(struct ctl_show_rib *, u_char *);
voidshow_rib_detail(struct ctl_show_rib *, u_char *, int, int);
voidshow_attr(void *, u_int16_t, int);
+voidshow_communities(u_char *, size_t, int);
voidshow_community(u_char *, u_int16_t);
voidshow_large_community(u_char *, u_int16_t);
voidshow_ext_community(u_char *, u_int16_t);
@@ -1248,6 +1249,12 @@ show_rib_detail_msg(struct imsg *imsg, i
asdata += sizeof(struct ctl_show_rib);
show_rib_detail(, asdata, nodescr, flag0);
break;
+ case IMSG_CTL_SHOW_RIB_COMMUNITIES:
+ ilen = imsg->hdr.len - IMSG_HEADER_SIZE;
+ if (ilen % sizeof(struct community))
+ errx(1, "bad IMSG_CTL_SHOW_RIB_COMMUNITIES received");
+ show_communities(imsg->data, ilen, flag0);
+ break;
case IMSG_CTL_SHOW_RIB_ATTR:
ilen = imsg->hdr.len - IMSG_HEADER_SIZE;
if (ilen < 3)
@@ -1628,6 +1635,138 @@ show_attr(void *b, u_int16_t len, int fl
printf("%c", EOL0(flag0));
}
+static void
+print_community(u_int16_t a, u_int16_t v)
+{
+ if (a == COMMUNITY_WELLKNOWN)
+ switch (v) {
+ case COMMUNITY_GRACEFUL_SHUTDOWN:
+ printf("GRACEFUL_SHUTDOWN");
+ break;
+ case COMMUNITY_NO_EXPORT:
+ printf("NO_EXPORT");
+ break;
+ case COMMUNITY_NO_ADVERTISE:
+ printf("NO_ADVERTISE");
+ break;
+ case COMMUNITY_NO_EXPSUBCONFED:
+ printf("NO_EXPORT_SUBCONFED");
+ break;
+ case COMMUNITY_NO_PEER:
+ printf("NO_PEER");
+ break;
+ case COMMUNITY_BLACKHOLE:
+ printf("BLACKHOLE");
+ break;
+ default:
+ printf("%hu:%hu", a, v);
+ break;
+ }
+ else
+ printf("%hu:%hu", a, v);
+}
+
+static void
+print_ext_community(u_int8_t *data)
+{
+ u_int64_t ext;
+ struct in_addr ip;
+ u_int32_t as4, u32;
+ u_int16_t as2, u16;
+ u_int8_ttype, subtype;
+
+ type = data[0];
+ subtype = data[1];
+
+ printf("%s ", log_ext_subtype(type, subtype));
+
+ switch (type) {
+ case EXT_COMMUNITY_TRANS_TWO_AS:
+ memcpy(, data + 2, sizeof(as2));
+ memcpy(, data + 4, sizeof(u32));
+ printf("%s:%u", log_as(ntohs(as2)), ntohl(u32));
+ break;
+ case EXT_COMMUNITY_TRANS_IPV4:
+ memcpy(, data + 2, sizeof(ip));
+ memcpy(, data + 6, sizeof(u16));
+ printf("%s:%hu", inet_ntoa(ip), ntohs(u16));
+ break;
+ case EXT_COMMUNITY_TRANS_FOUR_AS:
+ memcpy(, data + 2, sizeof(as4));
+ memcpy(, data + 6, sizeof(u16));
+ printf("%s:%hu", log_as(ntohl(as4)), ntohs(u16));
+ break;
+ case EXT_COMMUNITY_TRANS_OPAQUE:
+ case EXT_COMMUNITY_TRANS_EVPN:
+ memcpy(, data, sizeof(ext));
+ ext = be64toh(ext) & 0xLL;
+ printf("0x%llx", (unsigned long long)ext);
+ break;
+ case EXT_COMMUNITY_NON_TRANS_OPAQUE:
+ memcpy(, data, sizeof(ext));
+ ext = be64toh(ext) & 0xLL;
+ switch (ext) {
+ case EXT_COMMUNITY_OVS_VALID:
+ printf("valid ");
+ break;
+ case EXT_COMMUNITY_OVS_NOTFOUND:
+ printf("not-found ");
+ break;
+ case EXT_COMMUNITY_OVS_INVALID:
+
Unlock uvm a tiny bit more
This changes uvm_unmap_detach() to get rid of the "easy" entries first
before grabbing the kernel lock. Probably doesn't help much with the
lock contention, but it avoids a locking problem that happens with
pools that use kernel_map() to allocate the kva for their pages.
ok?
Index: uvm/uvm_map.c
===
RCS file: /cvs/src/sys/uvm/uvm_map.c,v
retrieving revision 1.243
diff -u -p -r1.243 uvm_map.c
--- uvm/uvm_map.c 23 Apr 2019 13:35:12 - 1.243
+++ uvm/uvm_map.c 13 May 2019 22:09:26 -
@@ -1538,8 +1538,18 @@ uvm_mapent_tryjoin(struct vm_map *map, s
void
uvm_unmap_detach(struct uvm_map_deadq *deadq, int flags)
{
- struct vm_map_entry *entry;
+ struct vm_map_entry *entry, *tmp;
int waitok = flags & UVM_PLA_WAITOK;
+
+ TAILQ_FOREACH_SAFE(entry, deadq, dfree.deadq, tmp) {
+ /* Skip entries for which we have to grab the kernel lock. */
+ if (entry->aref.ar_amap || UVM_ET_ISSUBMAP(entry) ||
+ UVM_ET_ISOBJ(entry))
+ continue;
+
+ TAILQ_REMOVE(deadq, entry, dfree.deadq);
+ uvm_mapent_free(entry);
+ }
if (TAILQ_EMPTY(deadq))
return;
add newline for tpm0: dmesg line
dmesg:
...
acpibtn2 at acpi0: PWRB
tpm0 at acpi0: TPM_ addr 0xfed4/0x5000acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
...
--- dev/acpi/tpm.c.orig Mon May 13 23:54:55 2019
+++ dev/acpi/tpm.c Mon May 13 23:55:03 2019
@@ -268,6 +268,7 @@
return;
}
+ printf("\n");
sc->sc_enabled = 1;
}
-f
--
Re: [PATCH] portgen(1) man page: Add py type
On Mon, May 13, 2019 at 10:05:16AM -0700, Andrew Hewus Fresh wrote:
> On Mon, May 13, 2019 at 07:37:36AM +0100, Stuart Henderson wrote:
> > As far as plists go, unless the port only supports py2 or only supports py3,
> > it ought to generate the plist with FLAVOR=python3 and then prefix any lines
> > ending in ${MODPY_PYCACHE}/ with ${MODPY_COMMENT}.
>
> I think kmos@ explained this to me correctly, but if someone wants to
> write down the why this needs to happen again I'll happily add it as a
> comment to this magic.
So this pointed out an issue to me due to this patch. As I understood
it, I could attach "${MODPY_FLAVOR}" indiscriminately to all the
depends, but this error tells me that's probably not true. Do I need to
only add the flavor if the dependent has a python3 flavor?
===> Updating plist for py3-pytest-4.5.0
Fatal: Unknown flavor(s) python3 (in devel/py-funcsigs)
(No flavors for this port). (in devel/py-funcsigs)
*** Error 1 in /usr/ports/devel/py-funcsigs
(/usr/ports/infrastructure/mk/bsd.port.mk:3564 '.BEGIN': @exit 1)
Problem with dependency STEM->=1.0:devel/py-funcsigs,python3
Re: bgpd refactor UPDATE attribute writer
ok with whitespace fixes below
Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.05.10 15:34:22 +0200:
> This change is from a much larger patch I'm working on. This cleans up
> up_generate_attr() from a hardcoded implementation to a loop-switch
> construct. This way attributes are always dumped in ascending order as
> suggested by the RFC and adding special attributes is simpler than in the
> current way. There is an exception whit the MP attributes because those
> are added at a later point.
>
> Works for me(tm)
> --
> :wq Claudio
>
> Index: rde_update.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde_update.c,v
> retrieving revision 1.108
> diff -u -p -r1.108 rde_update.c
> --- rde_update.c 21 Jan 2019 02:07:56 - 1.108
> +++ rde_update.c 10 May 2019 11:51:28 -
> @@ -295,96 +295,155 @@ up_generate_attr(u_char *buf, int len, s
> struct filterstate *state, u_int8_t aid)
> {
> struct rde_aspath *asp = >aspath;
> - struct attr *oa, *newaggr = NULL;
> + struct attr *oa = NULL, *newaggr = NULL;
> u_char *pdata;
> u_int32_ttmp32;
> in_addr_tnexthop;
> int flags, r, neednewpath = 0;
> u_int16_twlen = 0, plen;
> - u_int8_t l;
> - u_int16_tnlen = 0;
> - u_char *ndata;
> -
> - /* origin */
> - if ((r = attr_write(buf + wlen, len, ATTR_WELL_KNOWN,
> - ATTR_ORIGIN, >origin, 1)) == -1)
> - return (-1);
> - wlen += r; len -= r;
> -
> - /* aspath */
> - if (!peer->conf.ebgp ||
> - peer->conf.flags & PEERFLAG_TRANS_AS)
> - pdata = aspath_prepend(asp->aspath, peer->conf.local_as, 0,
> - );
> - else
> - pdata = aspath_prepend(asp->aspath, peer->conf.local_as, 1,
> - );
> -
> - if (!rde_as4byte(peer))
> - pdata = aspath_deflate(pdata, , );
> -
> - if ((r = attr_write(buf + wlen, len, ATTR_WELL_KNOWN,
> - ATTR_ASPATH, pdata, plen)) == -1)
> - return (-1);
> - wlen += r; len -= r;
> - free(pdata);
> -
> - switch (aid) {
> - case AID_INET:
> - nexthop = up_get_nexthop(peer, state);
> - if ((r = attr_write(buf + wlen, len, ATTR_WELL_KNOWN,
> - ATTR_NEXTHOP, , 4)) == -1)
> - return (-1);
> - wlen += r; len -= r;
> - break;
> - default:
> - break;
> - }
> -
> - /*
> - * The old MED from other peers MUST not be announced to others
> - * unless the MED is originating from us or the peer is an IBGP one.
> - * Only exception are routers with "transparent-as yes" set.
> - */
> - if (asp->flags & F_ATTR_MED && (!peer->conf.ebgp ||
> - asp->flags & F_ATTR_MED_ANNOUNCE ||
> - peer->conf.flags & PEERFLAG_TRANS_AS)) {
> - tmp32 = htonl(asp->med);
> - if ((r = attr_write(buf + wlen, len, ATTR_OPTIONAL,
> - ATTR_MED, , 4)) == -1)
> - return (-1);
> - wlen += r; len -= r;
> - }
> -
> - if (!peer->conf.ebgp) {
> - /* local preference, only valid for ibgp */
> - tmp32 = htonl(asp->lpref);
> - if ((r = attr_write(buf + wlen, len, ATTR_WELL_KNOWN,
> - ATTR_LOCALPREF, , 4)) == -1)
> - return (-1);
> - wlen += r; len -= r;
> - }
> -
> - /*
> - * dump all other path attributes. Following rules apply:
> - * 1. well-known attrs: ATTR_ATOMIC_AGGREGATE and ATTR_AGGREGATOR
> - * pass unmodified (enforce flags to correct values)
> - * Actually ATTR_AGGREGATOR may be deflated for OLD 2-byte peers.
> - * 2. non-transitive attrs: don't re-announce to ebgp peers
> - * 3. transitive known attrs: announce unmodified
> - * 4. transitive unknown attrs: set partial bit and re-announce
> - */
> - for (l = 0; l < asp->others_len; l++) {
> - if ((oa = asp->others[l]) == NULL)
> + u_int8_t oalen = 0, type;
> +
> + if (asp->others_len > 0)
> + oa = asp->others[oalen++];
> +
> + /* dump attributes in ascending order */
> + for (type = ATTR_ORIGIN; type < 255; type++) {
> + r = 0;
> +
> + while (oa && oa->type < type) {
> + if (oalen < asp->others_len)
> + oa = asp->others[oalen++];
trailing tab
> + else
> + oa = NULL;
> + }
> +
> + switch (type) {
> + /*
> + * Attributes stored in rde_aspath
> + */
> + case ATTR_ORIGIN:
> + if ((r = attr_write(buf + wlen, len, ATTR_WELL_KNOWN,
> + ATTR_ORIGIN, >origin, 1)) == -1)
> +
bgpd set nexthop 198.51.100.42 clarifications
When using a rule forcing the nexthop to a specific address bgpd currently does not mark that nexthop as no-modify. In other words the default rules for nexthop propagation applies. This means that for ebgp it only sends out the set nexthop when this nexthop is connected and on the same network as the peer. So while the Adj-RIB-Out shows the right nexthop it is actually not on the wire. This diff changes set nexthop 198.51.100.42 to also imply set nexthop no-modify. This way the set nexthop is always on the wire. The problem with that is that it will hand you a nice footgun ready to blow of your big toe (but in the end the current behaviour is doing the same just with a different angle of attack) . The set nexthop section in bgpd.conf.5 needs to be adjusted once a decision is made on how to handle this. -- :wq Claudio Index: rde_rib.c === RCS file: /cvs/src/usr.sbin/bgpd/rde_rib.c,v retrieving revision 1.190 diff -u -p -r1.190 rde_rib.c --- rde_rib.c 7 Mar 2019 07:42:36 - 1.190 +++ rde_rib.c 13 May 2019 17:32:14 - @@ -1491,7 +1491,7 @@ nexthop_modify(struct nexthop *setnh, en break; nexthop_put(*nexthop); *nexthop = nexthop_ref(setnh); - *flags = 0; + *flags = NEXTHOP_NOMODIFY; break; default: break;
Re: sv(4): fix free with zero size
Jan Klemkow wrote: > Hi, > > The following diff fixes "free with zero size" in sv(4). Builds and > stats the kernel with sv at pci and audio at sv enabled. ok
Re: [PATCH] portgen(1) man page: Add py type
On Mon, May 13, 2019 at 07:37:36AM +0100, Stuart Henderson wrote:
> As far as plists go, unless the port only supports py2 or only supports py3,
> it ought to generate the plist with FLAVOR=python3 and then prefix any lines
> ending in ${MODPY_PYCACHE}/ with ${MODPY_COMMENT}.
I think kmos@ explained this to me correctly, but if someone wants to
write down the why this needs to happen again I'll happily add it as a
comment to this magic.
Comments, OK?
Index: infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm
===
RCS file: /cvs/ports/infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm,v
retrieving revision 1.12
diff -u -p -r1.12 PyPI.pm
--- infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm 12 May 2019 20:23:33
- 1.12
+++ infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm 13 May 2019 17:03:48
-
@@ -48,6 +48,38 @@ sub get_ver_info
return 1;
}
+sub make_plist
+{
+ my ($self, @args) = @_;
+
+ my $flavored3 = $self->{FLAVORS} && $self->{FLAVORS} =~ /\bpython3\b/;
+ local $ENV{FLAVOR} = 'python3' if $flavored3;
+
+ my $ret = $self->SUPER::make_plist(@args);
+
+ if ( $flavored3 && -e 'pkg/PLIST' ) {
+ open my $ifh, '<', 'pkg/PLIST'
+ or die "Unable to open PLIST: $!";
+ open my $ofh, '>', 'pkg/PLIST.new'
+ or die "Unable to open PLIST.new: $!";
+
+ while ( my $line = readline $ifh ) {
+ $line = '${MODPY_COMMENT}' . $line
+ if $line =~ m<\$\{MODPY_PYCACHE\}/?$>
+ and $line !~ m<^\$\{MODPY_COMMENT\}>;
+ print $ofh $line;
+ }
+
+ close $ifh;
+ close $ofh;
+
+ rename 'pkg/PLIST.new', 'pkg/PLIST'
+ or die "Unable to rename new PLIST: $!";
+ }
+
+ return $ret;
+}
+
sub name_new_port
{
my ( $self, $di ) = @_;
Re: Perl update to 5.28.2
On Mon, May 13, 2019 at 09:04:41AM -0700, Andrew Hewus Fresh wrote: > I was reminded by bluhm@ that I had patches to update perl to the minor > 5.28.2 release ready shortly before the hackathon. I haven't had time > to do much testing of it, and unsurprisingly it seems to be mostly full > of `s/5.28.1/5.28.2/`, but there are a few bugfixes included, none of > which seem like candidates for -stable. > > I'd love to hear how your testing goes. I had to remove .../perl/obj/* manually to make Perl compile. I have installed it on my laptop, works fine. Only one static function has been added to libperl.so.19.0. 0025b570 t S_argvout_final So I think it is correct to keep the library version. No bump required. OK bluhm@
free() sizes in sys/arch/alpha
Index: dev/sgmap_common.c
===
RCS file: /OpenBSD/src/sys/arch/alpha/dev/sgmap_common.c,v
retrieving revision 1.14
diff -u -p -r1.14 sgmap_common.c
--- dev/sgmap_common.c 9 Dec 2014 06:58:28 - 1.14
+++ dev/sgmap_common.c 13 May 2019 16:39:50 -
@@ -150,6 +150,8 @@ alpha_sgmap_dmamap_setup(map, nsegments,
{
map->_dm_cookie = mallocarray(nsegments, sizeof(struct extent_region),
M_DEVBUF, (flags & BUS_DMA_NOWAIT) ? M_NOWAIT : M_WAITOK);
+ if (map->_dm_cookie != NULL)
+ map->_dm_cookiesize = nsegments * sizeof(struct extent_region);
return (map->_dm_cookie == NULL);
}
@@ -187,7 +189,7 @@ void
alpha_sgmap_dmamap_teardown(map)
bus_dmamap_t map;
{
- free(map->_dm_cookie, M_DEVBUF, 0);
+ free(map->_dm_cookie, M_DEVBUF, map->_dm_cookiesize);
}
void
Index: include/bus.h
===
RCS file: /OpenBSD/src/sys/arch/alpha/include/bus.h,v
retrieving revision 1.31
diff -u -p -r1.31 bus.h
--- include/bus.h 8 May 2017 00:27:45 - 1.31
+++ include/bus.h 13 May 2019 16:39:50 -
@@ -648,6 +648,7 @@ struct alpha_bus_dmamap {
* Private cookie to be used by the DMA back-end.
*/
void*_dm_cookie;
+ size_t _dm_cookiesize; /* size allocated for _dm_cookie */
/*
* The DMA window that we ended up being mapped in.
Index: isa/isadma_bounce.c
===
RCS file: /OpenBSD/src/sys/arch/alpha/isa/isadma_bounce.c,v
retrieving revision 1.12
diff -u -p -r1.12 isadma_bounce.c
--- isa/isadma_bounce.c 27 Sep 2015 10:12:09 - 1.12
+++ isa/isadma_bounce.c 13 May 2019 16:39:50 -
@@ -115,6 +115,7 @@ isadma_bounce_dmamap_create(bus_dma_tag_
map = *dmamp;
map->_dm_cookie = NULL;
+ map->_dm_cookiesize = 0;
cookiesize = sizeof(*cookie);
@@ -156,6 +157,7 @@ isadma_bounce_dmamap_create(bus_dma_tag_
cookie = (struct isadma_bounce_cookie *)cookiestore;
cookie->id_flags = cookieflags;
map->_dm_cookie = cookie;
+ map->_dm_cookiesize = cookiesize;
if (cookieflags & ID_MIGHT_NEED_BOUNCE) {
/*
@@ -190,7 +192,7 @@ isadma_bounce_dmamap_destroy(bus_dma_tag
if (cookie->id_flags & ID_HAS_BOUNCE)
isadma_bounce_free_bouncebuf(t, map);
- free(cookie, M_DEVBUF, 0);
+ free(cookie, M_DEVBUF, map->_dm_cookiesize);
_bus_dmamap_destroy(t, map);
}
Re: [patch] ftp: tiny typo in comment
On Mon, May 13, 2019 at 05:53:37PM +0200, Hiltjo Posthuma wrote: > Tiny typo in a fancy word :) Fixed, thanks
[patch] ftp: tiny typo in comment
Tiny typo in a fancy word :)
Patch below:
diff --git usr.bin/ftp/ftp.c usr.bin/ftp/ftp.c
index afb6514efd7..5690f4dbfb9 100644
--- usr.bin/ftp/ftp.c
+++ usr.bin/ftp/ftp.c
@@ -343,7 +343,7 @@ ftp_eprt(FILE *fp)
return -1;
}
- /* Find out the ephermal port chosen */
+ /* Find out the ephemeral port chosen */
len = sizeof(ss);
memset(, 0, len);
if (getsockname(sock, (struct sockaddr *), ) == -1) {
--
Kind regards,
Hiltjo
Re: chroot vs su vs doas
Martijn van Duren wrote: > >> Would > >> doas -c /rootdir somecmd > >> be of any use ? > > > > Not particularly opposed, but the extend of this option should be > > examined. E.g. do we want to extend it to the config to be something > > similar to -u and limit it's use for certain commands? > > > Working this out I'm not particularly a fan of the extra code this would > take, but the diff below seems to do the trick. This seems like feature creep. We already have a command to chroot and switch user.
Re: chroot vs su vs doas
Martijn van Duren wrote:
> > But what would it hurt to allow root usage ?
> > Specifically,
> >
> > doas -u ${BUILDUSER} some unquoted command
> >
> > as run by root. This would not open any security hole, would it ?
>
> I don't see any and I've been bitten by having a rootshell open and
> typing doas out of habit.
The reason there's no builtin config is to prevent confusion, even if it
sometimes causes mild annoyance. When there are invisible rules, it becomes
harder to know which rule is actually being taken.
For example, your rule below doesn't include keepenv. So next week we're going
to get bug reports that things work when run as a user, but not as root. And
for exactly the same reason, people only half set things up. The fact that the
default appears to work sometimes makes things even more annoying. And I
don't think the default should just be changed to include keepenv, because
maybe that's not what people want and then we'd need to explain how to undo
that.
> + static struct rule allowroot = {
> + .action = PERMIT,
> + .options = NOPASS,
> + .ident = NULL,
> + .target = NULL,
> + .cmd = NULL,
> + .cmdargs = NULL,
> + .envlist = NULL
> + };
Re: [PATCH] portgen(1) man page: Add py type
On 2019/05/13 09:18, Kurt Mosiejczuk wrote:
> On Mon, May 13, 2019 at 07:37:36AM +0100, Stuart Henderson wrote:
>
> > As far as plists go, unless the port only supports py2 or only
> > supports py3, it ought to generate the plist with FLAVOR=python3
> > and then prefix any lines ending in ${MODPY_PYCACHE}/ with
> > ${MODPY_COMMENT}.
>
> Yes. I was describing that to afresh1 at one point. Someone else brought
> up setting REVISION while doing so. I had seen that danj's aliases for
> regenerating the plist set REVISION to 999, although I had a problem
> related to have done that at one point. Is setting the REVISION while
> doing so still necessary? If it is, what does it do? (It'd probably be
> nice to know the reasoning before making a tool incorporate it :) ).
>
> --Kurt
portgen should not set this.
Python ports usually include an egg-info file which includes the module
name + version, normally written as name-${MODPY_EGG_VERSION}. But in the
case where this is equal to FULLPKGNAME update-plist prefers that longer
match. This is most common in tools that happen to be written in python
(no py- prefix in the package name) - things like ansible, beets,
radiotray etc.
It initially looks like things work ok with FULLPKGNAME there, but then
later somebody makes a change and bumps REVISION, and packaging gets
broken.
The trick of forcing a bogus REVISION prevents the string in the egg-info
filename from matching FULLPKGNAME.
The proper way to fix that problem is remove FULLPKGNAME from the
default SUBST_VARS. This used to be needed for the filenames for
pkg-readmes, but these have been changed to use PKGSTEM instead of
FULLPKGNAME, so pkg-readmes isn't a problem for doing this any more.
However since then, lua ports (ports/*/lua* and ports/devel/lpeg)
started using FULLPKGNAME as a de-conflict mechanism for examples and
docs directories, so they would need changing.
Re: [PATCH] portgen(1) man page: Add py type
On Mon, May 13, 2019 at 07:37:36AM +0100, Stuart Henderson wrote:
> As far as plists go, unless the port only supports py2 or only
> supports py3, it ought to generate the plist with FLAVOR=python3
> and then prefix any lines ending in ${MODPY_PYCACHE}/ with
> ${MODPY_COMMENT}.
Yes. I was describing that to afresh1 at one point. Someone else brought
up setting REVISION while doing so. I had seen that danj's aliases for
regenerating the plist set REVISION to 999, although I had a problem
related to have done that at one point. Is setting the REVISION while
doing so still necessary? If it is, what does it do? (It'd probably be
nice to know the reasoning before making a tool incorporate it :) ).
--Kurt
Re: [patch] cwm: filter duplicate hostnames in ssh menu
inform...@gmx.net (Bruno Flueckiger), 2019.05.12 (Sun) 14:39 (CEST):
> On 01.05., Marcus MERIGHI wrote:
> > Hello,
> >
> > o...@demirmen.com (Okan Demirmen), 2019.04.29 (Mon) 16:19 (CEST):
> > > On Fri 2019.04.26 at 07:15 +0200, Bruno Fl?ckiger wrote:
> > > > Hi,
> > > >
> > > > The ssh menu of cwm(1) doesn't filter duplicated hostnames when reading
> > > > them from ~/.ssh/known_hosts. This patch makes sure each hostname is
> > > > only displayed once to the menu.
> > >
> > > Sure, maybe; but why again do we even have this inside a window manager?
> > > Really, the known_hosts parsing is incomplete at best; either the entire
> > > parsing code needs to be lifted from ssh or this (mis)feature should be
> > > removed from cwm. I prefer the latter.
> >
> > FWIW, i use "M-period" a lot... are there easy alternatives?
> >
> I use dmenu[1] from suckless.org as a replacement. The following script
> reads the host names from ~/.ssh/known_hosts, feeds them to dmenu and
> executes ssh to the host I choose in an xterm:
Matthias, Landry, Thuban, Bruno - Thanks for your hints!
I settled for the script below. Thanks for the blueprint, Bruno!
Marcus
#!/bin/sh -eu
_h=$(while read _l; do print ${_l%%[ ,]*}; done < ~/.ssh/known_hosts | \
sort -u | dmenu)
exec xterm -T "[ssh] $_h" -e "ssh $_h || read _a?'enter to continue'"
Re: relayd: fix filter rules with forward to statement
Reyk Floeter writes:
> Hi,
>
> the attached diff fixes filter rules with "forward to" statement in
> persistent (keep-alive) connections. See the XXX comment below.
>
> ```relayd.conf
> log connection
> table {
> 127.0.0.1
> }
> table {
> 127.0.0.1
> }
> table {
> 127.0.0.1
> }
> http protocol pathfwd {
> return error
>
> # XXX The following workaround is not needed anymore:
> #match header set "Connection" value "close"
>
> pass path "/a/*" forward to
> pass path "/b/*" forward to
> #match request path log "*"
> }
> relay pathfwd {
> listen on 0.0.0.0 port 80
> protocol pathfwd
> forward to port 8082
> forward to port 8080
> forward to port 8081
> }
> ```
>
> OK?
>
Works great for us. FWIW, OK mikeb
> reyk
>
> Index: usr.sbin/relayd/relay.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
> retrieving revision 1.242
> diff -u -p -u -p -r1.242 relay.c
> --- usr.sbin/relayd/relay.c 4 Mar 2019 21:25:03 - 1.242
> +++ usr.sbin/relayd/relay.c 8 May 2019 14:26:40 -
> @@ -76,11 +76,14 @@ intrelay_tls_ctx_create(struct relay
> void relay_tls_transaction(struct rsession *,
> struct ctl_relay_event *);
> void relay_tls_handshake(int, short, void *);
> -void relay_connect_retry(int, short, void *);
> void relay_tls_connected(struct ctl_relay_event *);
> void relay_tls_readcb(int, short, void *);
> void relay_tls_writecb(int, short, void *);
>
> +void relay_connect_retry(int, short, void *);
> +void relay_connect_state(struct rsession *,
> + struct ctl_relay_event *, enum relay_state);
> +
> extern void bufferevent_read_pressure_cb(struct evbuffer *, size_t,
> size_t, void *);
>
> @@ -654,6 +657,7 @@ relay_socket_listen(struct sockaddr_stor
> void
> relay_connected(int fd, short sig, void *arg)
> {
> + char obuf[128];
> struct rsession *con = arg;
> struct relay*rlay = con->se_relay;
> struct protocol *proto = rlay->rl_proto;
> @@ -696,6 +700,22 @@ relay_connected(int fd, short sig, void
>
> DPRINTF("%s: session %d: successful", __func__, con->se_id);
>
> + /* Log destination if it was changed in a keep-alive connection */
> + if ((con->se_table != con->se_table0) &&
> + (env->sc_conf.opts & (RELAYD_OPT_LOGCON|RELAYD_OPT_LOGCONERR))) {
> + con->se_table0 = con->se_table;
> + memset(, 0, sizeof(obuf));
> + (void)print_host(>se_out.ss, obuf, sizeof(obuf));
> + if (asprintf(, " -> %s:%d",
> + obuf, ntohs(con->se_out.port)) == -1) {
> + relay_abort_http(con, 500,
> + "connection changed and asprintf failed", 0);
> + return;
> + }
> + relay_log(con, msg);
> + free(msg);
> + }
> +
> switch (rlay->rl_proto->type) {
> case RELAY_PROTO_HTTP:
> if (relay_httpdesc_init(out) == -1) {
> @@ -1465,6 +1485,17 @@ relay_bindany(int fd, short event, void
> }
>
> void
> +relay_connect_state(struct rsession *con, struct ctl_relay_event *cre,
> +enum relay_state new)
> +{
> + DPRINTF("%s: session %d: %s state %s -> %s",
> + __func__, con->se_id,
> + cre->dir == RELAY_DIR_REQUEST ? "accept" : "connect",
> + relay_state(cre->state), relay_state(new));
> + cre->state = new;
> +}
> +
> +void
> relay_connect_retry(int fd, short sig, void *arg)
> {
> struct timeval evtpause = { 1, 0 };
> @@ -1533,9 +1564,9 @@ relay_connect_retry(int fd, short sig, v
> }
>
> if (rlay->rl_conf.flags & F_TLSINSPECT)
> - con->se_out.state = STATE_PRECONNECT;
> + relay_connect_state(con, >se_out, STATE_PRECONNECT);
> else
> - con->se_out.state = STATE_CONNECTED;
> + relay_connect_state(con, >se_out, STATE_CONNECTED);
> relay_inflight--;
> DPRINTF("%s: inflight decremented, now %d",__func__, relay_inflight);
>
> @@ -1560,7 +1591,7 @@ relay_preconnect(struct rsession *con)
> con->se_id, privsep_process);
> rv = relay_connect(con);
> if (con->se_out.state == STATE_CONNECTED)
> - con->se_out.state = STATE_PRECONNECT;
> + relay_connect_state(con, >se_out, STATE_PRECONNECT);
> return (rv);
> }
>
> @@ -1585,7 +1616,7 @@ relay_connect(struct rsession *con)
> return (-1);
> }
> relay_connected(con->se_out.s, EV_WRITE, con);
> - con->se_out.state = STATE_CONNECTED;
> + relay_connect_state(con, >se_out, STATE_CONNECTED);
> return (0);
> }
>
> @@ -1642,7
Re: chroot vs su vs doas
On 5/13/19 10:00 AM, Martijn van Duren wrote:
> On 5/13/19 9:13 AM, Marc Espie wrote:
>> So, in dpb, I've been forking a lot of 'chroot -u user /build'
>> to build various things, and it works just great.
>>
>> I was wondering about the benefits of
>> su ${BUILDUSER} -c 'some quoted command'
>> vs
>> chroot -u ${BUILDUSER} / some unquoted command
>>
>> Superficially, it looks mostly similar.
>>
>> The very nice thing about chroot (IMO) being that you can pass the
>> command verbatim without having to re-quote anything. The other
>> difference being that chroot doesn't fork an extra shell, which
>> might make things more transparent wrt running commands.
>>
>> I'm also wondering about doas.
>> By default, it's not configured at all.
>>
>> But what would it hurt to allow root usage ?
>> Specifically,
>>
>> doas -u ${BUILDUSER} some unquoted command
>>
>> as run by root. This would not open any security hole, would it ?
>
> I don't see any and I've been bitten by having a rootshell open and
> typing doas out of habit.
>
> lightly tested diff below.
>>
>> Finally, I'm wondering if people would have any use for a chroot'd
>> option in doas, and whether it's a security issue (again).
>>
>> Like, people have some hardened doas.conf which only allows running
>> some commands as root.
>>
>> Some of these commands are basically game over, as they allow anything
>> to be run, actually. Specifically, /usr/bin/env, or chroot...
>>
>> Would
>> doas -c /rootdir somecmd
>> be of any use ?
>
> Not particularly opposed, but the extend of this option should be
> examined. E.g. do we want to extend it to the config to be something
> similar to -u and limit it's use for certain commands?
>
Working this out I'm not particularly a fan of the extra code this would
take, but the diff below seems to do the trick.
martijn@
Index: doas.c
===
RCS file: /cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.74
diff -u -p -r1.74 doas.c
--- doas.c 17 Jan 2019 05:35:35 - 1.74
+++ doas.c 13 May 2019 09:23:41 -
@@ -89,8 +89,9 @@ parsegid(const char *s, gid_t *gid)
}
static int
-match(uid_t uid, gid_t *groups, int ngroups, uid_t target, const char *cmd,
-const char **cmdargs, struct rule *r)
+match(uid_t uid, gid_t *groups, int ngroups, uid_t target,
+const char *chrootpath, const char *cmd, const char **cmdargs,
+struct rule *r)
{
int i;
@@ -110,6 +111,12 @@ match(uid_t uid, gid_t *groups, int ngro
}
if (r->target && uidcheck(r->target, target) != 0)
return 0;
+ if (r->chroot != NULL) {
+ if (chrootpath == NULL)
+ return 0;
+ if (strcmp(r->chroot, chrootpath) != 0)
+ return 0;
+ }
if (r->cmd) {
if (strcmp(r->cmd, cmd))
return 0;
@@ -130,13 +137,13 @@ match(uid_t uid, gid_t *groups, int ngro
static int
permit(uid_t uid, gid_t *groups, int ngroups, const struct rule **lastr,
-uid_t target, const char *cmd, const char **cmdargs)
+uid_t target, const char *chrootpath, const char *cmd, const char
**cmdargs)
{
int i;
*lastr = NULL;
for (i = 0; i < nrules; i++) {
- if (match(uid, groups, ngroups, target, cmd,
+ if (match(uid, groups, ngroups, target, chrootpath, cmd,
cmdargs, rules[i]))
*lastr = rules[i];
}
@@ -173,7 +180,7 @@ parseconfig(const char *filename, int ch
}
static void __dead
-checkconfig(const char *confpath, int argc, char **argv,
+checkconfig(const char *confpath, int argc, char **argv, const char
*chrootpath,
uid_t uid, gid_t *groups, int ngroups, uid_t target)
{
const struct rule *rule;
@@ -183,7 +190,7 @@ checkconfig(const char *confpath, int ar
if (!argc)
exit(0);
- if (permit(uid, groups, ngroups, , target, argv[0],
+ if (permit(uid, groups, ngroups, , target, chrootpath, argv[0],
(const char **)argv + 1)) {
printf("permit%s\n", (rule->options & NOPASS) ? " nopass" : "");
exit(0);
@@ -286,6 +293,7 @@ main(int argc, char **argv)
const char *confpath = NULL;
char *shargv[] = { NULL, NULL };
char *sh;
+ const char *chrootpath = NULL;
const char *cmd;
char cmdline[LINE_MAX];
char myname[_PW_NAME_LEN + 1];
@@ -309,11 +317,14 @@ main(int argc, char **argv)
uid = getuid();
- while ((ch = getopt(argc, argv, "a:C:Lnsu:")) != -1) {
+ while ((ch = getopt(argc, argv, "a:c:C:Lnsu:")) != -1) {
switch (ch) {
case 'a':
login_style = optarg;
break;
+ case 'c':
+ chrootpath = optarg;
+ break;
case 'C':
Re: relayd: SNI
On Thu, May 09, 2019 at 02:51:23PM +0200, Reyk Floeter wrote:
> Hi,
>
> this diff adds SNI support to relayd.
>
Below is the same diff again -current minus one debug line.
jsing@ has noted that calling tls_config_set_keypair_ocsp_mem() with
NULL ocsp options could be replaced with tls_config_set_keypair_mem(),
but I'd like to keep it for now because I have an OCSP diff on top of
it that I'll send once SNI is in.
OK?
Reyk
Index: usr.sbin/relayd/ca.c
===
RCS file: /cvs/src/usr.sbin/relayd/ca.c,v
retrieving revision 1.34
diff -u -p -u -p -r1.34 ca.c
--- usr.sbin/relayd/ca.c19 Sep 2018 11:28:02 - 1.34
+++ usr.sbin/relayd/ca.c13 May 2019 08:53:17 -
@@ -108,56 +108,60 @@ hash_x509(X509 *cert, char *hash, size_t
void
ca_launch(void)
{
- char hash[TLS_CERT_HASH_SIZE];
- char*buf;
- BIO *in = NULL;
- EVP_PKEY*pkey = NULL;
- struct relay*rlay;
- X509*cert = NULL;
- off_tlen;
+ char hash[TLS_CERT_HASH_SIZE];
+ char*buf;
+ BIO *in = NULL;
+ EVP_PKEY*pkey = NULL;
+ struct relay*rlay;
+ struct relay_cert *cert;
+ X509*x509 = NULL;
+ off_tlen;
- TAILQ_FOREACH(rlay, env->sc_relays, rl_entry) {
- if ((rlay->rl_conf.flags & (F_TLS|F_TLSCLIENT)) == 0)
+ TAILQ_FOREACH(cert, env->sc_certs, cert_entry) {
+ if (cert->cert_fd == -1 || cert->cert_key_fd == -1)
continue;
- if (rlay->rl_tls_cert_fd != -1) {
- if ((buf = relay_load_fd(rlay->rl_tls_cert_fd,
- )) == NULL)
- fatal("ca_launch: cert relay_load_fd");
+ if ((buf = relay_load_fd(cert->cert_fd, )) == NULL)
+ fatal("ca_launch: cert relay_load_fd");
- if ((in = BIO_new_mem_buf(buf, len)) == NULL)
- fatalx("ca_launch: cert BIO_new_mem_buf");
+ if ((in = BIO_new_mem_buf(buf, len)) == NULL)
+ fatalx("ca_launch: cert BIO_new_mem_buf");
- if ((cert = PEM_read_bio_X509(in, NULL,
- NULL, NULL)) == NULL)
- fatalx("ca_launch: cert PEM_read_bio_X509");
+ if ((x509 = PEM_read_bio_X509(in, NULL,
+ NULL, NULL)) == NULL)
+ fatalx("ca_launch: cert PEM_read_bio_X509");
- hash_x509(cert, hash, sizeof(hash));
+ hash_x509(x509, hash, sizeof(hash));
- BIO_free(in);
- X509_free(cert);
- purge_key(, len);
- }
- if (rlay->rl_conf.tls_key_len) {
- if ((in = BIO_new_mem_buf(rlay->rl_tls_key,
- rlay->rl_conf.tls_key_len)) == NULL)
- fatalx("%s: key", __func__);
-
- if ((pkey = PEM_read_bio_PrivateKey(in,
- NULL, NULL, NULL)) == NULL)
- fatalx("%s: PEM", __func__);
- BIO_free(in);
+ BIO_free(in);
+ X509_free(x509);
+ purge_key(, len);
- rlay->rl_tls_pkey = pkey;
+ if ((buf = relay_load_fd(cert->cert_key_fd, )) == NULL)
+ fatal("ca_launch: key relay_load_fd");
- if (pkey_add(env, pkey, hash) == NULL)
- fatalx("tls pkey");
+ if ((in = BIO_new_mem_buf(buf, len)) == NULL)
+ fatalx("%s: key", __func__);
- purge_key(>rl_tls_key,
- rlay->rl_conf.tls_key_len);
- }
+ if ((pkey = PEM_read_bio_PrivateKey(in,
+ NULL, NULL, NULL)) == NULL)
+ fatalx("%s: PEM", __func__);
- if (rlay->rl_tls_cacert_fd != -1) {
+ cert->cert_pkey = pkey;
+
+ if (pkey_add(env, pkey, hash) == NULL)
+ fatalx("tls pkey");
+
+ BIO_free(in);
+ purge_key(, len);
+ }
+
+ TAILQ_FOREACH(rlay, env->sc_relays, rl_entry) {
+ if ((rlay->rl_conf.flags & (F_TLS|F_TLSCLIENT)) == 0)
+ continue;
+
+ if (rlay->rl_tls_cacert_fd != -1 &&
+ rlay->rl_conf.tls_cakey_len) {
if ((buf = relay_load_fd(rlay->rl_tls_cacert_fd,
)) == NULL)
fatal("ca_launch: cacert relay_load_fd");
@@ -165,17 +169,16 @@
Re: chroot vs su vs doas
On 5/13/19 9:13 AM, Marc Espie wrote:
> So, in dpb, I've been forking a lot of 'chroot -u user /build'
> to build various things, and it works just great.
>
> I was wondering about the benefits of
> su ${BUILDUSER} -c 'some quoted command'
> vs
> chroot -u ${BUILDUSER} / some unquoted command
>
> Superficially, it looks mostly similar.
>
> The very nice thing about chroot (IMO) being that you can pass the
> command verbatim without having to re-quote anything. The other
> difference being that chroot doesn't fork an extra shell, which
> might make things more transparent wrt running commands.
>
> I'm also wondering about doas.
> By default, it's not configured at all.
>
> But what would it hurt to allow root usage ?
> Specifically,
>
> doas -u ${BUILDUSER} some unquoted command
>
> as run by root. This would not open any security hole, would it ?
I don't see any and I've been bitten by having a rootshell open and
typing doas out of habit.
lightly tested diff below.
>
> Finally, I'm wondering if people would have any use for a chroot'd
> option in doas, and whether it's a security issue (again).
>
> Like, people have some hardened doas.conf which only allows running
> some commands as root.
>
> Some of these commands are basically game over, as they allow anything
> to be run, actually. Specifically, /usr/bin/env, or chroot...
>
> Would
> doas -c /rootdir somecmd
> be of any use ?
Not particularly opposed, but the extend of this option should be
examined. E.g. do we want to extend it to the config to be something
similar to -u and limit it's use for certain commands?
>
Index: doas.c
===
RCS file: /cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.74
diff -u -p -r1.74 doas.c
--- doas.c 17 Jan 2019 05:35:35 - 1.74
+++ doas.c 13 May 2019 07:57:29 -
@@ -132,6 +132,15 @@ static int
permit(uid_t uid, gid_t *groups, int ngroups, const struct rule **lastr,
uid_t target, const char *cmd, const char **cmdargs)
{
+ static struct rule allowroot = {
+ .action = PERMIT,
+ .options = NOPASS,
+ .ident = NULL,
+ .target = NULL,
+ .cmd = NULL,
+ .cmdargs = NULL,
+ .envlist = NULL
+ };
int i;
*lastr = NULL;
@@ -140,8 +149,13 @@ permit(uid_t uid, gid_t *groups, int ngr
cmdargs, rules[i]))
*lastr = rules[i];
}
- if (!*lastr)
+ if (!*lastr) {
+ if (uid == 0) {
+ *lastr =
+ return PERMIT;
+ }
return 0;
+ }
return (*lastr)->action == PERMIT;
}
chroot vs su vs doas
So, in dpb, I've been forking a lot of 'chroot -u user /build'
to build various things, and it works just great.
I was wondering about the benefits of
su ${BUILDUSER} -c 'some quoted command'
vs
chroot -u ${BUILDUSER} / some unquoted command
Superficially, it looks mostly similar.
The very nice thing about chroot (IMO) being that you can pass the
command verbatim without having to re-quote anything. The other
difference being that chroot doesn't fork an extra shell, which
might make things more transparent wrt running commands.
I'm also wondering about doas.
By default, it's not configured at all.
But what would it hurt to allow root usage ?
Specifically,
doas -u ${BUILDUSER} some unquoted command
as run by root. This would not open any security hole, would it ?
Finally, I'm wondering if people would have any use for a chroot'd
option in doas, and whether it's a security issue (again).
Like, people have some hardened doas.conf which only allows running
some commands as root.
Some of these commands are basically game over, as they allow anything
to be run, actually. Specifically, /usr/bin/env, or chroot...
Would
doas -c /rootdir somecmd
be of any use ?
Re: [PATCH] portgen(1) man page: Add py type
As far as plists go, unless the port only supports py2 or only supports
py3, it ought to generate the plist with FLAVOR=python3 and then prefix any
lines ending in ${MODPY_PYCACHE}/ with ${MODPY_COMMENT}.
--
Sent from a phone, apologies for poor formatting.
On 12 May 2019 21:30:34 Andrew Hewus Fresh wrote:
Kurt, you're welcome to commit this whenever you think it's good enough.
I say, with the improvements this week, OK afresh1@
I'm not quite sure what "plist smarts" it needs, but let me know if
there is something I'm missing.
On Sun, Feb 03, 2019 at 11:44:41PM +, Stuart Henderson wrote:
I asked tsg about this before, IIRC it was intentionally omitted as it
wasn't considered finished. (For starters it could do with some plist
smarts).
On Sun, Feb 03, 2019 at 09:22:31PM +, Linda Lapinlampi wrote:
/usr/ports/infrastructure/bin/portgen supports "py" type, as seen in the
source code:
if ( $type eq 'p5' ) {
$o = OpenBSD::PortGen::Port::CPAN->new();
} elsif ( $type eq 'py' ) {
$o = OpenBSD::PortGen::Port::PyPI->new();
} elsif ( $type eq 'ruby' ) {
$o = OpenBSD::PortGen::Port::Ruby->new();
} else {
die "unknown module type\n";
}
This "py" type also works to generate ports from PyPI sources, mostly.
It's not documented in the man page though.
Attached diff adds a mention of the type to portgen(1) man page.
Index: portgen.1
===
RCS file: /cvs/src/share/man/man1/portgen.1,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 portgen.1
--- portgen.1 26 Jun 2018 05:38:49 - 1.1
+++ portgen.1 3 Feb 2019 21:15:33 -
@@ -50,6 +50,8 @@ values:
.Bl -inset -offset indent -compact
.It Cm p5
for Perl modules on CPAN.
+.It Cm py
+for Python modules on PyPI.
.It Cm ruby
for Ruby gems.
.El
ftp.usa.openbsd.org mirror unavailable Monday afternoon through Wednesday morning
RIT is doing two overnight power outages again starting 5pm (EDT) Monday May 13th. Accordingly, ftp5.usa.openbsd.org (which is also ftp3.usa.openbsd.org and ftp.usa.openbsd.org) will be down from Monday Afternoon until the power comes back on Wednesday morning on May 15th. --Kurt Mosiejczuk
Re: enable cy(4) by default on amd64
Does this driver correctly support cua(4) device nodes? If it doesn't, then my position would be "no, that is a minimum required featureset". And 'd' dialout support isn't the same, it must be cua. (Quirky different behaviours between tty devices are super annoying and end up as complaints on the mailing list, so a tty driver MUST support cua(4) correctly). A quick review of the driver indicates: No cua support. Frankly, it's the kind of driver that needs the work, or a visit to the Attic... Want to try fixing it? It is not trivial.. >I use tree cy(4) cards on amd64 for several releases. Its totally >stable and works fine beside known bugs already mentioned in the >manpage. Thus, I would prefer to enabled it by default in amd64 as it >is in i386. > >Bye, >Jan > >Index: arch/amd64/conf/GENERIC >=== >RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v >retrieving revision 1.471 >diff -u -p -r1.471 GENERIC >--- arch/amd64/conf/GENERIC8 May 2019 23:54:39 - 1.471 >+++ arch/amd64/conf/GENERIC13 May 2019 05:13:47 - >@@ -382,7 +382,7 @@ com* at pcmcia? # PCMCIA >modems/serial > com* at puc? > > # options CY_HW_RTS >-#cy* at pci? # PCI cyclom serial card >+cy* at pci? # PCI cyclom serial card > #cz* at pci? # Cyclades-Z multi-port serial boards > > lpt0 at isa? port 0x378 irq 7# standard PC parallel ports > >
