unwind(8): recommend supersede in dhclient.conf
We didn't get around to run unwind per default and integrate it tighter with dhclient this release cycle. But there is also no need anymore to recomend prepend in dhclient.conf, unwind(8) is no longer closing it's service port when it's running so it should always be available. (I checked the installer there supersede does not have any effect, probably because the small dhclient doesn't parse /etc/dhclient.conf.) Comments, OK? diff --git unwind.8 unwind.8 index fe08a9b4c4c..7014db070f9 100644 --- unwind.8 +++ unwind.8 @@ -52,7 +52,7 @@ in .Pp Adding .Pp -.Dl prepend domain-name-servers 127.0.0.1; +.Dl supersede domain-name-servers 127.0.0.1; .Pp to .Pa /etc/dhclient.conf -- I'm not entirely sure you are real.
Re: smtpd: trailing CR
On Mon, 20 Apr 2020 15:01:31 +0200, Eric Faurot wrote: > There has been a discussion a while ago about the issue of trailing CR > in smtp lines (https://marc.info/?l=openbsd-tech=156890805128121=2). > > It is agreed that stripping an optional CR at io level is a problem > because the information is lost and there is no way to take a specific > action at the protocol level if needed. > > So this diffs moves the CR stripping from io level to protocol level for > SMTP dialogs. Other uses of io_getline() are internal and expect simple LF > line ending. The current behavior should not change. This looks OK to me but I would feel better if we had successful reports from other people too. - todd
Re: Support additional SD/MMC controller on Raspberry Pi 4
On 2020/04/20 23:43, Mark Kettenis wrote: > > bwfm(4) is working for me, but when in device tree mode (wherever the > > uSD is routed) bse(4) is flaky - ethernet link doesn't come up at boot, > > if I leave it for a little while with a ping running to the bse from > > another machine I get the occasional packet through but that's all. > > Do you see that too? > > I don't see that, but I suspect this is because the device tree has > phy-mode set to "rgmii" instead of "rgmii-rxid". > > A workaround is to take the bcm2711-rpi-4-b.dtb, fixup4.dat and > start4.elf files from > > https://github.com/raspberrypi/firmware/tree/next/boot > > and put them on the MS-DOS partition of your uSD card. Thanks, confirmed it's working for me with the newer files.
Re: Support additional SD/MMC controller on Raspberry Pi 4
> Date: Mon, 20 Apr 2020 22:18:06 +0100 > From: Stuart Henderson > > On 2020/04/19 21:44, Mark Kettenis wrote: > > The Raspberry Pi 4 has an additional SD/MMC controller. This > > controller is almost completely standard and just needs one tiny > > quirk. So the diff is really simple. > > > > By default, if you use the EDK2-base UEFI firmware this controller > > isn't actually connected to anything. So you'll see > > > > sdmmc0: can't enable card > > > > in your dmesg. If you change the "Raspberry Pi Configuration" -> > > "SD/MMC Configuration" -> "uSD routing" setting in the "Device > > Manager" firmware configuration screen to "eMMC2 SDHCI". The uSD card > > will show up behind this controller and WiFi will show up on the other > > controller. Note that after you've made that configuration change and > > reset the machine, any further change you make won't stick. You can > > fix this by replacing the RPI_EFI.fd file on the MS-DOS partition of > > your uSD card. > > > > For now the SDHC controllers are only supported in device tree mode > > which can be enabled using the "Raspberry Pi Configuration" -> > > "Advanced Configuration" -> "Device Tree" option in the "Device > > Manager". > > bwfm(4) is working for me, but when in device tree mode (wherever the > uSD is routed) bse(4) is flaky - ethernet link doesn't come up at boot, > if I leave it for a little while with a ping running to the bse from > another machine I get the occasional packet through but that's all. > Do you see that too? I don't see that, but I suspect this is because the device tree has phy-mode set to "rgmii" instead of "rgmii-rxid". A workaround is to take the bcm2711-rpi-4-b.dtb, fixup4.dat and start4.elf files from https://github.com/raspberrypi/firmware/tree/next/boot and put them on the MS-DOS partition of your uSD card.
Re: distrib/notes/arm64/prep update
On 2020/04/20 22:23, Olivier wrote: > Hi stuart, > > Thanks. > > I let you handle it. I would like just share and maybe help. > > My point; is possible that i am doing someting bad ^^, is that on rockpro64, > when you perform the install : > > _ emmc with u-boot > _ pen with miniroot67.fs > > If i did not install the dtb on the pen... i can not write on the emmc, even > if i can boot the pen from the emmc. > > As i said, i let you manage ^^ I think i should open a specific thread on > that matter in @arm mailing list :) > > Thank you all, for your job ^^ The file I sent the diff for is src/distrib/notes/arm64. It already has a section, "Install on systems without a supported miniroot:" telling you to install the dtb and showing how. The only 64-bit ARM hardware I have is raspberry pi and OD1000 so if that is not enough then you or somebody else who has a system that needs this will need to figure out what is missing and propose a diff. > 0liv. > > On Mon, 20 Apr 2020 13:42:37 +0100 > Stuart Henderson wrote: > > > On 2020/04/20 11:06, Olivier wrote: > > > Hi Mark, > > > > > > as often i forgot those steps, may i suggest to include the followings > > > below ? > > > > > > without it, seems (for me) impossible to write to the installed emmc from > > > the installer. > > > > I don't have one of those systems, but I believe this is already coverex > > by the "Install on systems without a supported miniroot" section. > > > -- > burelli.fr >
Re: Support additional SD/MMC controller on Raspberry Pi 4
On 2020/04/19 21:44, Mark Kettenis wrote: > The Raspberry Pi 4 has an additional SD/MMC controller. This > controller is almost completely standard and just needs one tiny > quirk. So the diff is really simple. > > By default, if you use the EDK2-base UEFI firmware this controller > isn't actually connected to anything. So you'll see > > sdmmc0: can't enable card > > in your dmesg. If you change the "Raspberry Pi Configuration" -> > "SD/MMC Configuration" -> "uSD routing" setting in the "Device > Manager" firmware configuration screen to "eMMC2 SDHCI". The uSD card > will show up behind this controller and WiFi will show up on the other > controller. Note that after you've made that configuration change and > reset the machine, any further change you make won't stick. You can > fix this by replacing the RPI_EFI.fd file on the MS-DOS partition of > your uSD card. > > For now the SDHC controllers are only supported in device tree mode > which can be enabled using the "Raspberry Pi Configuration" -> > "Advanced Configuration" -> "Device Tree" option in the "Device > Manager". bwfm(4) is working for me, but when in device tree mode (wherever the uSD is routed) bse(4) is flaky - ethernet link doesn't come up at boot, if I leave it for a little while with a ping running to the bse from another machine I get the occasional packet through but that's all. Do you see that too? 64 bytes from 10.15.5.53: icmp_seq=1977 ttl=255 time=0.590 ms 64 bytes from 10.15.5.53: icmp_seq=1987 ttl=255 time=0.531 ms 64 bytes from 10.15.5.53: icmp_seq=1992 ttl=255 time=0.537 ms 64 bytes from 10.15.5.53: icmp_seq=2024 ttl=255 time=0.543 ms 64 bytes from 10.15.5.53: icmp_seq=2027 ttl=255 time=0.406 ms Watching interrupt rates whilst flood pinging it, none of them move. $ vmstat -i interrupt total rate irq1023/spur 470 irq0/ipinop214576 197 irq153/pluart0 43887 40 irq158/sdhc033516 30 irq175/xhci0 305805 281 irq189/bse0 74136 irq27/tick 867628 797 Total 1472872 1353 ESC (setup), F1 (shell), ENTER (boot).disks: sd0* >> OpenBSD/arm64 BOOTAA64 0.22 boot> booting sd0a:/bsd: 7737056+1498096+541152+848472 [509436+109+962448+543543]=0xd3 f930 type 0x0 pa 0x0 va 0x0 pages 0x1d0 attr 0xe type 0x6 pa 0x1d va 0x97a96c000 pages 0x20 attr 0x800e type 0x0 pa 0x1f va 0x0 pages 0x10 attr 0xe type 0x2 pa 0x20 va 0x0 pages 0x4000 attr 0xe type 0x7 pa 0x420 va 0x0 pages 0x2e8fb attr 0xe type 0x2 pa 0x32afb000 va 0x0 pages 0xc82 attr 0xe type 0x1 pa 0x3377d000 va 0x0 pages 0x2a attr 0xe type 0x0 pa 0x337a7000 va 0x0 pages 0xf9 attr 0xe type 0x6 pa 0x338a va 0x9ae03c000 pages 0xa0 attr 0x800e type 0x5 pa 0x3394 va 0x9ae0dc000 pages 0x50 attr 0x800e type 0x9 pa 0x3399 va 0x0 pages 0x80 attr 0xe type 0x5 pa 0x33a1 va 0x9ae1ac000 pages 0x80 attr 0x800e type 0x9 pa 0x33a9 va 0x0 pages 0x20 attr 0xe type 0x5 pa 0x33ab va 0x9ae24c000 pages 0x80 attr 0x800e type 0x7 pa 0x33b3 va 0x0 pages 0x19e7 attr 0xe type 0x4 pa 0x35517000 va 0x0 pages 0x481 attr 0xe type 0x7 pa 0x35998000 va 0x0 pages 0x5f attr 0xe type 0x4 pa 0x359f7000 va 0x0 pages 0x1 attr 0xe type 0x7 pa 0x359f8000 va 0x0 pages 0xd7 attr 0xe type 0x4 pa 0x35acf000 va 0x0 pages 0xf55 attr 0xe type 0x7 pa 0x36a24000 va 0x0 pages 0x19e attr 0xe type 0x3 pa 0x36bc2000 va 0x0 pages 0x43e attr 0xe type 0x5 pa 0x3700 va 0x9b179c000 pages 0x190 attr 0x800e type 0x6 pa 0x3719 va 0x9b192c000 pages 0x250 attr 0x800e type 0x7 pa 0x373e va 0x0 pages 0x1f attr 0xe type 0x4 pa 0x373ff000 va 0x0 pages 0x1 attr 0xe type 0x7 pa 0x3740 va 0x0 pages 0x302b attr 0xe type 0x3 pa 0x3a42b000 va 0x0 pages 0x36 attr 0xe type 0x4 pa 0x3a461000 va 0x0 pages 0xf9f attr 0xe type 0x7 pa 0x4000 va 0x0 pages 0x8 attr 0xe [ using 2016504 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2020 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.7-beta (GENERIC.MP) #2: Mon Apr 20 21:13:03 BST 2020 st...@moo.spacehopper.org:/sys/arch/arm64/compile/GENERIC.MP real mem = 3076521984 (2934MB) avail mem = 2951929856 (2815MB) mainbus0 at root: Raspberry Pi 4 Model B Rev 1.2 cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3 cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu0: 1024KB 64b/line 16-way L2 cache efi0 at mainbus0: UEFI 2.7 efi0: https://github.com/pftf/RPi4 rev 0x1 smbios0 at efi0: SMBIOS 3.3.0 smbios0: vendor https://github.com/pftf/RPi4 version "UEFI Firmware v1.8" date Apr 14 2020 21:24:48 smbios0: Sony UK Raspberry Pi 4 Model B apm0 at mainbus0 psci0 at mainbus0: PSCI 1.1,
Re: distrib/notes/arm64/prep update
Hi stuart, Thanks. I let you handle it. I would like just share and maybe help. My point; is possible that i am doing someting bad ^^, is that on rockpro64, when you perform the install : _ emmc with u-boot _ pen with miniroot67.fs If i did not install the dtb on the pen... i can not write on the emmc, even if i can boot the pen from the emmc. As i said, i let you manage ^^ I think i should open a specific thread on that matter in @arm mailing list :) Thank you all, for your job ^^ 0liv. On Mon, 20 Apr 2020 13:42:37 +0100 Stuart Henderson wrote: > On 2020/04/20 11:06, Olivier wrote: > > Hi Mark, > > > > as often i forgot those steps, may i suggest to include the followings > > below ? > > > > without it, seems (for me) impossible to write to the installed emmc from > > the installer. > > I don't have one of those systems, but I believe this is already coverex > by the "Install on systems without a supported miniroot" section. -- burelli.fr
smtpd: fix smtpctl discover
Hi again,
We had a report of a crash when running "smtpctl discover" on an
envelope that has a invalid dispatcher (action name changed in the
config).
The issue is that the dispatcher is not checked after the envelope is
loaded as a result of the discover command. But adding the check
afterwards is not enough, because the envelope is already in the
envelope cache, so this makes the whole live update/discover process
actually useless (we would have to invalidate the cache).
So the right fix, which also simplifies the code (always a good sign),
is to make that check along with the other envelope validation checks
that happen at envelope load time.
Eric.
Index: queue.c
===
RCS file: /cvs/src/usr.sbin/smtpd/queue.c,v
retrieving revision 1.189
diff -u -p -r1.189 queue.c
--- queue.c 30 Dec 2018 23:09:58 - 1.189
+++ queue.c 20 Apr 2020 18:43:17 -
@@ -686,7 +686,6 @@ static void
queue_timeout(int fd, short event, void *p)
{
static uint32_t msgid = 0;
- struct dispatcher *dsp;
struct envelope evp;
struct event*ev = p;
struct timeval tv;
@@ -705,13 +704,6 @@ queue_timeout(int fd, short event, void
}
if (r) {
- dsp = dict_get(env->sc_dispatchers, evp.dispatcher);
- if (dsp == NULL) {
- log_warnx("warn: queue: missing dispatcher \"%s\""
- " for envelope %016"PRIx64", ignoring",
- evp.dispatcher, evp.id);
- goto reset;
- }
if (msgid && evpid_to_msgid(evp.id) != msgid) {
m_create(p_scheduler, IMSG_QUEUE_MESSAGE_COMMIT,
0, 0, -1);
@@ -724,7 +716,6 @@ queue_timeout(int fd, short event, void
m_close(p_scheduler);
}
-reset:
tv.tv_sec = 0;
tv.tv_usec = 10;
evtimer_add(ev, );
Index: queue_backend.c
===
RCS file: /cvs/src/usr.sbin/smtpd/queue_backend.c,v
retrieving revision 1.65
diff -u -p -r1.65 queue_backend.c
--- queue_backend.c 30 Dec 2018 23:09:58 - 1.65
+++ queue_backend.c 20 Apr 2020 18:42:38 -
@@ -730,6 +730,9 @@ envelope_validate(struct envelope *ep)
if (memchr(ep->errorline, '\0', sizeof(ep->errorline)) == NULL)
return "invalid error line";
+ if (dict_get(env->sc_dispatchers, ep->dispatcher) == NULL)
+ return "unknown dispatcher";
+
return NULL;
}
acme-client(1) and Buypass Go SSL
Hello,
I've tried to get a certificate from Buypass Go SSL provider using
acme-client(1) but it ends with the following error:
acme-client: https://api.buypass.com/acme-v02/new-acct: bad HTTP: 400
acme-client: transfer buffer:
[{"type":"urn:ietf:params:acme:error:malformed","d
etail":"Email is a required
contact","code":400,"message":"MALFORMED_BAD_REQUEST
","details":"HTTP 400 Bad Request"}] (164 bytes)
Buypass Go SSL requires that optional field contact in Account Objects
will contain email address.
I've added new option "contact" to acme-client.conf to fullfil this
requirement. It is also required to change MARKER in certproc.c to fix
line endings handling in pem files.
--
Kind regards, Bartosz Kuzma.
Index: usr.sbin/acme-client/acme-client.conf.5
===
RCS file: /cvs/src/usr.sbin/acme-client/acme-client.conf.5,v
retrieving revision 1.22
diff -u -p -r1.22 acme-client.conf.5
--- usr.sbin/acme-client/acme-client.conf.5 10 Feb 2020 13:18:21 -
1.22
+++ usr.sbin/acme-client/acme-client.conf.5 20 Apr 2020 16:24:46 -
@@ -98,6 +98,10 @@ It defaults to
Specify the
.Ar url
under which the ACME API is reachable.
+.It Ic contact Ar contact
+Optional
+.Ar contact
+URLs that the authority can use to contact the client for issues related to
this account.
.El
.Sh DOMAINS
The certificates to be obtained through ACME.
Index: usr.sbin/acme-client/certproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/certproc.c,v
retrieving revision 1.12
diff -u -p -r1.12 certproc.c
--- usr.sbin/acme-client/certproc.c 7 Jun 2019 08:07:52 - 1.12
+++ usr.sbin/acme-client/certproc.c 20 Apr 2020 16:24:46 -
@@ -28,7 +28,7 @@
#include "extern.h"
-#define MARKER "-END CERTIFICATE-\n"
+#define MARKER "-END CERTIFICATE-"
int
certproc(int netsock, int filesock)
@@ -94,6 +94,12 @@ certproc(int netsock, int filesock)
}
chaincp += strlen(MARKER);
+
+ if ((chaincp = strchr(chaincp, '-')) == NULL) {
+ warn("strchr");
+ goto out;
+ }
+
if ((chain = strdup(chaincp)) == NULL) {
warn("strdup");
goto out;
Index: usr.sbin/acme-client/extern.h
===
RCS file: /cvs/src/usr.sbin/acme-client/extern.h,v
retrieving revision 1.17
diff -u -p -r1.17 extern.h
--- usr.sbin/acme-client/extern.h 7 Feb 2020 14:34:15 - 1.17
+++ usr.sbin/acme-client/extern.h 20 Apr 2020 16:24:46 -
@@ -261,13 +261,13 @@ intjson_parse_capaths(struct jsmnn *,
char *json_fmt_newcert(const char *);
char *json_fmt_chkacc(void);
-char *json_fmt_newacc(void);
+char *json_fmt_newacc(const char *);
char *json_fmt_neworder(const char *const *, size_t);
char *json_fmt_protected_rsa(const char *,
const char *, const char *, const char *);
char *json_fmt_protected_ec(const char *, const char *, const char *,
const char *);
-char *json_fmt_protected_kid(const char*, const char *, const char *,
+char *json_fmt_protected_kid(const char *, const char *, const char
*,
const char *);
char *json_fmt_revokecert(const char *);
char *json_fmt_thumb_rsa(const char *, const char *);
Index: usr.sbin/acme-client/json.c
===
RCS file: /cvs/src/usr.sbin/acme-client/json.c,v
retrieving revision 1.16
diff -u -p -r1.16 json.c
--- usr.sbin/acme-client/json.c 22 Jan 2020 22:25:22 - 1.16
+++ usr.sbin/acme-client/json.c 20 Apr 2020 16:24:46 -
@@ -616,19 +616,30 @@ json_fmt_chkacc(void)
* Format the "newAccount" resource request.
*/
char *
-json_fmt_newacc(void)
+json_fmt_newacc(const char *contact)
{
int c;
- char*p;
+ char*p, *cnt;
+
+ c = asprintf(, "\"contact\": [ \"%s\" ], ", contact);
+ if (c == -1) {
+ warn("asprintf");
+ goto err;
+ }
c = asprintf(, "{"
+ "%s"
"\"termsOfServiceAgreed\": true"
- "}");
+ "}", contact == NULL ? "" : cnt);
+ free(cnt);
if (c == -1) {
warn("asprintf");
p = NULL;
}
return p;
+
+err:
+ return NULL;
}
/*
Index: usr.sbin/acme-client/netproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/netproc.c,v
retrieving revision 1.25
diff -u -p -r1.25 netproc.c
--- usr.sbin/acme-client/netproc.c 11 Aug 2019 19:44:25 - 1.25
+++ usr.sbin/acme-client/netproc.c 20 Apr 2020 16:24:46 -
@@ -368,13 +368,13 @@ sreq(struct conn *c, const char *addr, i
*
Struct for kqueue scan state
This diff introduces a struct for kqueue scan state. It eases making
scans piecewise by keeping track of the scan's end point. The end point
prevents the scan from recollecting events that are already being
reported to the userspace.
Below is an overview of the goal. It is achieved by combining this diff
with mpi@'s kqueue_scan() refactoring.
kqueue_scan_setup(, kq);
while (room for events) {
...
ready = kqueue_scan(, ...);
if (ready == 0)
break;
...
}
kqueue_scan_finish();
The diff takes a conservative approach with the scan start marker and
reinserts it for each round in kqueue_scan().
As the diff does not provide any immediate improvement, it will wait
after release.
OK?
Index: kern/kern_event.c
===
RCS file: src/sys/kern/kern_event.c,v
retrieving revision 1.131
diff -u -p -r1.131 kern_event.c
--- kern/kern_event.c 7 Apr 2020 13:27:51 - 1.131
+++ kern/kern_event.c 20 Apr 2020 14:17:59 -
@@ -62,7 +62,7 @@ void KQREF(struct kqueue *);
void KQRELE(struct kqueue *);
intkqueue_sleep(struct kqueue *, struct timespec *);
-intkqueue_scan(struct kqueue *kq, int maxevents,
+intkqueue_scan(struct kqueue_scan_state *scan, int maxevents,
struct kevent *ulistp, struct timespec *timeout,
struct proc *p, int *retval);
@@ -529,6 +529,7 @@ out:
int
sys_kevent(struct proc *p, void *v, register_t *retval)
{
+ struct kqueue_scan_state scan;
struct filedesc* fdp = p->p_fd;
struct sys_kevent_args /* {
syscallarg(int) fd;
@@ -612,8 +613,10 @@ sys_kevent(struct proc *p, void *v, regi
KQREF(kq);
FRELE(fp, p);
- error = kqueue_scan(kq, SCARG(uap, nevents), SCARG(uap, eventlist),
+ kqueue_scan_setup(, kq);
+ error = kqueue_scan(, SCARG(uap, nevents), SCARG(uap, eventlist),
tsp, p, );
+ kqueue_scan_finish();
KQRELE(kq);
*retval = n;
return (error);
@@ -870,11 +873,12 @@ kqueue_sleep(struct kqueue *kq, struct t
}
int
-kqueue_scan(struct kqueue *kq, int maxevents, struct kevent *ulistp,
-struct timespec *tsp, struct proc *p, int *retval)
+kqueue_scan(struct kqueue_scan_state *scan, int maxevents,
+struct kevent *ulistp, struct timespec *tsp, struct proc *p, int *retval)
{
struct kevent *kevp;
- struct knote mend, mstart, *kn;
+ struct knote *kn;
+ struct kqueue *kq = scan->kqs_kq;
int s, count, nkev = 0, error = 0;
struct kevent kev[KQ_NEVENTS];
@@ -882,9 +886,6 @@ kqueue_scan(struct kqueue *kq, int maxev
if (count == 0)
goto done;
- memset(, 0, sizeof(mstart));
- memset(, 0, sizeof(mend));
-
retry:
if (kq->kq_state & KQ_DYING) {
error = EBADF;
@@ -894,7 +895,8 @@ retry:
kevp = [0];
s = splhigh();
if (kq->kq_count == 0) {
- if (tsp != NULL && !timespecisset(tsp)) {
+ if ((tsp != NULL && !timespecisset(tsp)) ||
+ scan->kqs_nevent != 0) {
splx(s);
error = 0;
goto done;
@@ -910,27 +912,40 @@ retry:
goto done;
}
- mstart.kn_filter = EVFILT_MARKER;
- mstart.kn_status = KN_PROCESSING;
- TAILQ_INSERT_HEAD(>kq_head, , kn_tqe);
- mend.kn_filter = EVFILT_MARKER;
- mend.kn_status = KN_PROCESSING;
- TAILQ_INSERT_TAIL(>kq_head, , kn_tqe);
+ /*
+* Put the end marker in the queue to limit the scan to the events
+* that are currently active. This prevents events from being
+* recollected if they reactivate during scan.
+*
+* If a partial scan has been performed already but no events have
+* been collected, reposition the end marker to make any new events
+* reachable.
+*/
+ if (!scan->kqs_queued) {
+ TAILQ_INSERT_TAIL(>kq_head, >kqs_end, kn_tqe);
+ scan->kqs_queued = 1;
+ } else if (scan->kqs_nevent == 0) {
+ TAILQ_REMOVE(>kq_head, >kqs_end, kn_tqe);
+ TAILQ_INSERT_TAIL(>kq_head, >kqs_end, kn_tqe);
+ }
+
+ TAILQ_INSERT_HEAD(>kq_head, >kqs_start, kn_tqe);
while (count) {
- kn = TAILQ_NEXT(, kn_tqe);
+ kn = TAILQ_NEXT(>kqs_start, kn_tqe);
if (kn->kn_filter == EVFILT_MARKER) {
- if (kn == ) {
- TAILQ_REMOVE(>kq_head, , kn_tqe);
- TAILQ_REMOVE(>kq_head, , kn_tqe);
+ if (kn == >kqs_end) {
+ TAILQ_REMOVE(>kq_head, >kqs_start,
+ kn_tqe);
splx(s);
-
Re: AEAD Suites in IKEX (iked) and Phase 1 (isakmpd)
Hi Tobias, *, thanks for the heads up. I'd see a security benefit by using those chiphers. (-> compared with CBC Ciphers) Thanks for your time. g, Stephan On Mon, Apr 20, 2020 at 01:36:47PM +0200, Tobias Heider wrote: > Date: Mon, 20 Apr 2020 13:36:47 +0200 > From: Tobias Heider > Subject: Re: AEAD Suites in IKEX (iked) and Phase 1 (isakmpd) > To: Stephan Mending > Cc: tech@openbsd.org > > On Mon, Apr 20, 2020 at 12:52:24PM +0200, Stephan Mending wrote: > > Hi, > > I was wondering if there was a reason why there are no AEAD Suites > > implemented for initial IKEX in iked or phase 1 in isamkmpd ? Even though > > iked's childSAs > > support it and Phase 2 in isakmpd does as well ? Is it just lack of time ? > > Because for example strongswan does exactly support that. Using GCM Suites > > and/or > > Chacha20Poly1305. > > > > Thanks for your time. > > > > Best regards, > > Stephan > > > > The quick answer would be: "No one bothered to implement it." > > It is on my list of planned features for iked, but honestly having > AEADs in the IKE SA is not really a priority. > > The main reason to prefer AEADs is their better performance. > The amount of data exchanged in phase 1 (or the IKE SA) is negligible > because it is only used for encrypting the key exchange messages. > The Child SAs (which are used for ESP) are where performance and > throughput actually matter. > > - Tobias >
smtpd: trailing CR
Hi,
There has been a discussion a while ago about the issue of trailing CR
in smtp lines (https://marc.info/?l=openbsd-tech=156890805128121=2).
It is agreed that stripping an optional CR at io level is a problem
because the information is lost and there is no way to take a specific
action at the protocol level if needed.
So this diffs moves the CR stripping from io level to protocol level for
SMTP dialogs. Other uses of io_getline() are internal and expect simple LF
line ending. The current behavior should not change.
Comments?
Eric.
Index: bounce.c
===
RCS file: /cvs/src/usr.sbin/smtpd/bounce.c,v
retrieving revision 1.81
diff -u -p -r1.81 bounce.c
--- bounce.c25 Nov 2019 12:11:26 - 1.81
+++ bounce.c20 Apr 2020 08:06:43 -
@@ -728,6 +728,10 @@ bounce_io(struct io *io, int evt, void *
if (line == NULL)
break;
+ /* Strip trailing '\r' */
+ if (len && line[len - 1] == '\r')
+ line[--len] = '\0';
+
log_trace(TRACE_BOUNCE, "bounce: %p: <<< %s", s, line);
if ((error = parse_smtp_response(line, len, , ))) {
Index: iobuf.c
===
RCS file: /cvs/src/usr.sbin/smtpd/iobuf.c,v
retrieving revision 1.12
diff -u -p -r1.12 iobuf.c
--- iobuf.c 3 Oct 2019 07:03:23 - 1.12
+++ iobuf.c 18 Mar 2020 20:25:41 -
@@ -174,10 +174,9 @@ iobuf_getline(struct iobuf *iobuf, size_
* the next call to iobuf_normalize() or iobuf_extend().
*/
iobuf_drop(iobuf, i + 1);
- len = (i && buf[i - 1] == '\r') ? i - 1 : i;
- buf[len] = '\0';
+ buf[i] = '\0';
if (rlen)
- *rlen = len;
+ *rlen = i;
return (buf);
}
Index: lka_filter.c
===
RCS file: /cvs/src/usr.sbin/smtpd/lka_filter.c,v
retrieving revision 1.61
diff -u -p -r1.61 lka_filter.c
--- lka_filter.c17 Apr 2020 14:20:13 - 1.61
+++ lka_filter.c19 Apr 2020 18:56:57 -
@@ -851,7 +851,7 @@ filter_data_internal(struct filter_sessi
/* no filter_entry, we either had none or reached end of chain */
if (filter_entry == NULL) {
- io_printf(fs->io, "%s\r\n", line);
+ io_printf(fs->io, "%s\n", line);
return;
}
Index: mta_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/mta_session.c,v
retrieving revision 1.134
diff -u -p -r1.134 mta_session.c
--- mta_session.c 10 Apr 2020 19:28:57 - 1.134
+++ mta_session.c 19 Apr 2020 10:25:55 -
@@ -1257,6 +1257,10 @@ mta_io(struct io *io, int evt, void *arg
return;
}
+ /* Strip trailing '\r' */
+ if (len && line[len - 1] == '\r')
+ line[--len] = '\0';
+
log_trace(TRACE_MTA, "mta: %p: <<< %s", s, line);
mta_report_protocol_server(s, line);
Index: smtp_client.c
===
RCS file: /cvs/src/usr.sbin/smtpd/smtp_client.c,v
retrieving revision 1.13
diff -u -p -r1.13 smtp_client.c
--- smtp_client.c 24 Feb 2020 23:54:27 - 1.13
+++ smtp_client.c 19 Apr 2020 10:26:25 -
@@ -680,6 +680,10 @@ smtp_client_readline(struct smtp_client
return 0;
}
+ /* Strip trailing '\r' */
+ if (len && line[len - 1] == '\r')
+ line[--len] = '\0';
+
log_trace(TRACE_SMTPCLT, "%p: <<< %s", proto, line);
/* Validate SMTP */
Index: smtp_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
retrieving revision 1.425
diff -u -p -r1.425 smtp_session.c
--- smtp_session.c 15 Mar 2020 16:34:57 - 1.425
+++ smtp_session.c 20 Apr 2020 08:06:35 -
@@ -1132,6 +1132,10 @@ smtp_io(struct io *io, int evt, void *ar
if (line == NULL)
return;
+ /* Strip trailing '\r' */
+ if (len && line[len - 1] == '\r')
+ line[--len] = '\0';
+
/* Message body */
eom = 0;
if (s->state == STATE_BODY) {
Re: distrib/notes/arm64/prep update
On 2020/04/20 11:06, Olivier wrote: > Hi Mark, > > as often i forgot those steps, may i suggest to include the followings below ? > > without it, seems (for me) impossible to write to the installed emmc from the > installer. I don't have one of those systems, but I believe this is already coverex by the "Install on systems without a supported miniroot" section.
Re: AEAD Suites in IKEX (iked) and Phase 1 (isakmpd)
On Mon, Apr 20, 2020 at 12:52:24PM +0200, Stephan Mending wrote: > Hi, > I was wondering if there was a reason why there are no AEAD Suites > implemented for initial IKEX in iked or phase 1 in isamkmpd ? Even though > iked's childSAs > support it and Phase 2 in isakmpd does as well ? Is it just lack of time ? > Because for example strongswan does exactly support that. Using GCM Suites > and/or > Chacha20Poly1305. > > Thanks for your time. > > Best regards, > Stephan > The quick answer would be: "No one bothered to implement it." It is on my list of planned features for iked, but honestly having AEADs in the IKE SA is not really a priority. The main reason to prefer AEADs is their better performance. The amount of data exchanged in phase 1 (or the IKE SA) is negligible because it is only used for encrypting the key exchange messages. The Child SAs (which are used for ESP) are where performance and throughput actually matter. - Tobias
AEAD Suites in IKEX (iked) and Phase 1 (isakmpd)
Hi, I was wondering if there was a reason why there are no AEAD Suites implemented for initial IKEX in iked or phase 1 in isamkmpd ? Even though iked's childSAs support it and Phase 2 in isakmpd does as well ? Is it just lack of time ? Because for example strongswan does exactly support that. Using GCM Suites and/or Chacha20Poly1305. Thanks for your time. Best regards, Stephan
Re: distrib/notes/arm64/prep update
Hi Mark,
as often i forgot those steps, may i suggest to include the followings below ?
without it, seems (for me) impossible to write to the installed emmc from the
installer.
Thank you.
On Mon, 20 Apr 2020 01:33:05 +0200 (CEST)
Mark Kettenis wrote:
> > Date: Thu, 16 Apr 2020 21:31:51 +0100
> > From: Stuart Henderson
> >
> > any comments? ok?
>
> ok kettenis@
>
> > Index: prep
> > ===
> > RCS file: /cvs/src/distrib/notes/arm64/prep,v
> > retrieving revision 1.9
> > diff -u -p -r1.9 prep
> > --- prep15 Apr 2020 11:41:08 - 1.9
> > +++ prep16 Apr 2020 20:29:56 -
> > @@ -24,11 +24,11 @@ Booting from an SD card:
> >storage devices. Under OpenBSD, it will appear as a ``sd'' device, for
> >example sd1.
> >
> >
> > - Use the dd(1) utility to copy the miniroot to the hard drive.
> > + Use the dd(1) utility to copy the miniroot to the SD card.
> >The command would likely be, under OpenBSD:
> > dd if=miniroot{:--:}OSrev.fs of=/dev/rsd1c bs=1m
+ (maybe only for minirootfs & rockchip installation)
+ If not installed :
+ # pkg_add u-boot-aarch64
+ # pkg_add dtb
+ To install dtb to usb stick
+ # mount /dev/sd1i /mnt
+ # mkdir /mnt/vendor
+ # cp /usr/local/share/dtb/arm64/rockchip/$(vendor).dtb /mnt/vendor/
+ # umount /mnt
> >
> > - When you have connected the serial to you computer, a command such
> > + When you have connected the serial to your computer, a command such
> >as "cu -l cuaU0 -s 115200" (assuming cuaU0 is your serial port device)
> >should connect you to the board's console.
> >
> > @@ -48,6 +48,35 @@ script.
> > => bootefi ${kernel_addr_r} ${fdt_addr_r}
> > The bootloader will then run and try to load sd0a:/bsd off an FFS
> > filesystem after a timeout.
> > +
> > +Install on Raspberry Pi 4:
> > +
> > + You will need a microSD card (only a small one is needed), a USB
> > + storage device, a TTL serial interface adapter (e.g. CP2102 USB-UART
> > + converter), and a cable to attach this to the TXD/RXD/GND pins on the
> > + https://pinout.xyz/ header on the board.
> > +
> > + Follow the installation instructions at https://github.com/pftf/RPi4
> > + to install UEFI firmware to a FAT-formatted microSD card.
> > +
> > + Use the dd(1) utility to copy the miniroot to the USB storage device.
> > + The command would likely be, under OpenBSD:
> > + dd if=miniroot{:--:}OSrev.fs of=/dev/rsd1c bs=1m
> > +
> > + When you have connected the serial to your computer, a command such
> > + as "cu -l cuaU0 -s 115200" (assuming cuaU0 is your serial port device)
> > + should connect you to the board's console.
> > +
> > + Shortly after powering the board, you should see messages on the serial
> > + console starting with "Initialising SDRAM" followed by messages from the
> > + UEFI firmware. If you have a monitor connected to the HDMI port, you
> > + should see a multi-coloured screen followed by UEFI firmware output.
> > + If you do not see this, re-check your UEFI firmware installation.
> > +
> > + OpenBSD should boot automatically soon after loading the UEFI firmware.
> > + If a monitor is connected you will see messages from the boot loader,
> > + but after the kernel has started running you will only see output on
> > + the serial console.
> >
> > Install on systems without a supported miniroot:
> >
> >
> >
--
burelli.fr
Re: patch: Unable to use USB scanner more than once: XHCI problem
On 19/04/20(Sun) 09:53, Natasha Kerensikova wrote:
> on Thursday 13 February 2020 at 14:44, Natasha Kerensikova wrote:
> > More detials below, but TL;DR: the problem only happens on XHCI USB,
> > everything is fine with the same code going through EHCI; and the
> > problem is the loss of a short bulk xfer from the device, but it never
> > happens on the first handle opened for the device file, only on
> > subsequent uses of the same device.
> [...]
> patrick@ suggested to change ugen(4) to reset the PID state recorded by
> the OS, using usbd_clear_endpoint_stall(), so that both OpenBSD and the
> device continue on DATA0.
> [...]
> I moved to right before closing the device, which is the non-commented
> line in the patch below, and it fixes the scanner for me, without
> breaking my other ugen(4) device (a digital camera used with gphoto2
> port). To be honest I don't really understand why one works and not the
> other.
That's progress, thanks!
That could imply some magic is missing from xhci_pipe_close() and/or
usbd_close_pipe() isn't adapted to xHCI.
> --- a/sys/dev/usb/ugen.c
> +++ b/sys/dev/usb/ugen.c
> @@ -441,6 +445,7 @@ ugen_do_close(struct ugen_softc *sc, int endpt, int flag)
> DPRINTFN(5, ("ugenclose: endpt=%d dir=%d sce=%p\n",
> endpt, dir, sce));
>
> + usbd_clear_endpoint_stall(sce->pipeh);
> usbd_close_pipe(sce->pipeh);
> sce->pipeh = NULL;
>
