Re: [RFC] acpi: add acpitimer_delay(), acpihpet_delay()
On 09/07, Scott Cheloha wrote: > Just to make sure that my changes to acpihpet(4) actually caused > the problem, I have a few more questions: > > 1. When did you change the OS type? 03 August, after that, there was a local snpashot built from sources fetched on 17 Aug 2022 22:12:57 +0300 which wasn't affected. > 2. What was the compilation date of the kernel where you first saw the >problem? Locally built snapshot from sources fetched on Wed, 31 Aug 2022 02:05:34 +0300. > 3. If you boot an unpatched kernel does the problem manifest in >exactly the same way? As I said, I mistakenly changed the OS type not to "FreeBSD Pre-11 versions (32-bit)", but to "FreeBSD 11 (32-bit)". The problem affects only VMs which have Guest OS Version set to "FreeBSD Pre-11 versions (32-bit)" on snapshots built after 31 Aug 2022. Sample outputs from the machine running older snapshot which is not affected: $ sysctl kern.version | head -n1 kern.version=OpenBSD 7.2-beta (GENERIC.MP) #1: Thu Aug 18 15:15:13 MSK 2022 $ sysctl | grep tsc kern.timecounter.hardware=tsc kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) acpitimer0(1000) machdep.tscfreq=1500017850 machdep.invarianttsc=1 -- With best regards, Pavel Korovin
Re: [RFC] acpi: add acpitimer_delay(), acpihpet_delay()
Oh no, sorry, that was too early. Double-checked once again, no, this problem still exists if Guest OS Version is set to "FreeBSD Pre-11 versions (32-bit)". If I set Guest OS Version to "FreeBSD 11 (32-bit)", the problem disappears. On 09/08, Pavel Korovin wrote: > Hi Scott, > > Thank you for the fix! > > I found what triggered this behaviour: it was the change in Guest OS > Version in VM Options. > > I deploy VMs with sysutils/packer, some time ago I noticed that VM type in > my templates is specified as freebsd11_64Guest, which isn't consistent with > vmt(4), as it presents itself as "FreeBSD Pre-11 versions (32-bit)". > > After changing OS type to "FreeBSD Pre-11 versions (32-bit)", I've got this > problem with tsc. > > The provided diff fixes it: > > $ sysctl -a | grep tsc > kern.timecounter.hardware=tsc > kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) > acpitimer0(1000) > machdep.tscfreq=158129 > machdep.invarianttsc=1 -- With best regards, Pavel Korovin
Re: [RFC] acpi: add acpitimer_delay(), acpihpet_delay()
Hi Scott,
Thank you for the fix!
I found what triggered this behaviour: it was the change in Guest OS
Version in VM Options.
I deploy VMs with sysutils/packer, some time ago I noticed that VM type in
my templates is specified as freebsd11_64Guest, which isn't consistent with
vmt(4), as it presents itself as "FreeBSD Pre-11 versions (32-bit)".
After changing OS type to "FreeBSD Pre-11 versions (32-bit)", I've got this
problem with tsc.
The provided diff fixes it:
$ sysctl -a | grep tsc
kern.timecounter.hardware=tsc
kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000)
acpitimer0(1000)
machdep.tscfreq=158129
machdep.invarianttsc=1
On 09/06, Scott Cheloha wrote:
> On Sat, Sep 03, 2022 at 01:50:28PM +0300, Pavel Korovin wrote:
> > After these changes, OpenBSD VMware guest's clock is galloping into the
> > future like this:
> > Aug 31 02:42:18 build ntpd[55904]: adjusting local clock by -27.085360s
> > Aug 31 02:44:26 build ntpd[55904]: adjusting local clock by -116.270573s
> > Aug 31 02:47:40 build ntpd[55904]: adjusting local clock by -281.085430s
> > Aug 31 02:52:01 build ntpd[55904]: adjusting local clock by -320.064639s
> > Aug 31 02:53:09 build ntpd[55904]: adjusting local clock by -385.095886s
> > Aug 31 02:54:47 build ntpd[55904]: adjusting local clock by -532.542486s
> > Aug 31 02:58:33 build ntpd[55904]: adjusting local clock by -572.363323s
> > Aug 31 02:59:38 build ntpd[55904]: adjusting local clock by -655.253598s
> > Aug 31 03:01:54 build ntpd[55904]: adjusting local clock by -823.653978s
> > Aug 31 03:06:14 build ntpd[55904]: adjusting local clock by -926.705093s
> > Aug 31 03:09:00 build ntpd[55904]: adjusting local clock by -1071.837887s
> >
> > VM time right after boot:
> > rdate -pn $ntp; date
> > Sat Sep 3 13:39:43 MSK 2022
> > Sat Sep 3 13:43:24 MSK 2022
> >
> > $ sysctl -a | grep tsc
> > kern.timecounter.hardware=tsc
> > kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000)
> > acpitimer0(1000)
> > machdep.tscfreq=580245275
>
> This frequency looks wrong.
>
> My first guess is that you are hitting a split-read problem in
> acpihpet_delay() when recalibrating the TSC.
>
> Does this patch fix it?
>
> If you can't build a kernel for testing I can just commit this and you
> can try the snapshot in a day or two.
>
> Index: acpihpet.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpihpet.c,v
> retrieving revision 1.28
> diff -u -p -r1.28 acpihpet.c
> --- acpihpet.c25 Aug 2022 18:01:54 - 1.28
> +++ acpihpet.c6 Sep 2022 16:12:23 -
> @@ -281,13 +281,19 @@ acpihpet_attach(struct device *parent, s
> void
> acpihpet_delay(int usecs)
> {
> - uint64_t c, s;
> + uint64_t count = 0, cycles;
> struct acpihpet_softc *sc = hpet_timecounter.tc_priv;
> + uint32_t val1, val2;
>
> - s = acpihpet_r(sc->sc_iot, sc->sc_ioh, HPET_MAIN_COUNTER);
> - c = usecs * hpet_timecounter.tc_frequency / 100;
> - while (acpihpet_r(sc->sc_iot, sc->sc_ioh, HPET_MAIN_COUNTER) - s < c)
> + val2 = bus_space_read_4(sc->sc_iot, sc->sc_ioh, HPET_MAIN_COUNTER);
> + cycles = usecs * hpet_timecounter.tc_frequency / 100;
> + while (count < cycles) {
> CPU_BUSY_CYCLE();
> + val1 = val2;
> + val2 = bus_space_read_4(sc->sc_iot, sc->sc_ioh,
> + HPET_MAIN_COUNTER);
> + count += val2 - val1;
> + }
> }
>
> u_int
--
With best regards,
Pavel Korovin
Re: [RFC] acpi: add acpitimer_delay(), acpihpet_delay()
After these changes, OpenBSD VMware guest's clock is galloping into the future like this: Aug 31 02:42:18 build ntpd[55904]: adjusting local clock by -27.085360s Aug 31 02:44:26 build ntpd[55904]: adjusting local clock by -116.270573s Aug 31 02:47:40 build ntpd[55904]: adjusting local clock by -281.085430s Aug 31 02:52:01 build ntpd[55904]: adjusting local clock by -320.064639s Aug 31 02:53:09 build ntpd[55904]: adjusting local clock by -385.095886s Aug 31 02:54:47 build ntpd[55904]: adjusting local clock by -532.542486s Aug 31 02:58:33 build ntpd[55904]: adjusting local clock by -572.363323s Aug 31 02:59:38 build ntpd[55904]: adjusting local clock by -655.253598s Aug 31 03:01:54 build ntpd[55904]: adjusting local clock by -823.653978s Aug 31 03:06:14 build ntpd[55904]: adjusting local clock by -926.705093s Aug 31 03:09:00 build ntpd[55904]: adjusting local clock by -1071.837887s VM time right after boot: rdate -pn $ntp; date Sat Sep 3 13:39:43 MSK 2022 Sat Sep 3 13:43:24 MSK 2022 $ sysctl -a | grep tsc kern.timecounter.hardware=tsc kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) acpitimer0(1000) machdep.tscfreq=580245275 machdep.invarianttsc=1 And in a couple of minutes after boot the timeskew getting like this: $ rdate -pn $ntp; date Sat Sep 3 13:41:49 MSK 2022 Sat Sep 3 13:48:46 MSK 2022 After several hours the VM lives in tomorrow. As a workaround, changing TSC source helps: # sysctl kern.timecounter.hardware=acpihpet0 -- With best regards, Pavel Korovin
relayd(8) TLSv1.3 diff
Dear all,
After compiling/upgrading to the latest source with TLSv1.3 server code enabled,
I've got Firefox SSL_ERROR_RX_MALFORMED_SERVER_HELLO when tried to access http
serviced by relayd.
Please find the diff for relayd(8) attached.
Qualys SSL report for the box:
https://www.ssllabs.com/ssltest/analyze.html?d=waste.tristero.se&s=2001%3a470%3a1f15%3a1492%3a0%3a0%3a0%3a2
--
With best regards,
Pavel Korovin
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/relayd/parse.y,v
retrieving revision 1.244
diff -u -p -r1.244 parse.y
--- parse.y 12 Feb 2020 21:15:44 - 1.244
+++ parse.y 12 May 2020 22:26:09 -
@@ -1355,6 +1355,8 @@ flag : STRING{
$$ = TLSFLAG_TLSV1_1;
else if (strcmp("tlsv1.2", $1) == 0)
$$ = TLSFLAG_TLSV1_2;
+ else if (strcmp("tlsv1.3", $1) == 0)
+ $$ = TLSFLAG_TLSV1_3;
else if (strcmp("cipher-server-preference", $1) == 0)
$$ = TLSFLAG_CIPHER_SERVER_PREF;
else if (strcmp("client-renegotiation", $1) == 0)
Index: relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.250
diff -u -p -r1.250 relay.c
--- relay.c 13 Jul 2019 06:53:00 - 1.250
+++ relay.c 12 May 2020 22:26:09 -
@@ -2066,6 +2066,8 @@ relay_tls_ctx_create_proto(struct protoc
protocols |= TLS_PROTOCOL_TLSv1_1;
if (proto->tlsflags & TLSFLAG_TLSV1_2)
protocols |= TLS_PROTOCOL_TLSv1_2;
+ if (proto->tlsflags & TLSFLAG_TLSV1_3)
+ protocols |= TLS_PROTOCOL_TLSv1_3;
if (tls_config_set_protocols(tls_cfg, protocols) == -1) {
log_warnx("could not set the TLS protocol: %s",
tls_config_error(tls_cfg));
Index: relayd.h
===
RCS file: /cvs/src/usr.sbin/relayd/relayd.h,v
retrieving revision 1.260
diff -u -p -r1.260 relayd.h
--- relayd.h15 Sep 2019 19:23:29 - 1.260
+++ relayd.h12 May 2020 22:26:09 -
@@ -695,15 +695,16 @@ TAILQ_HEAD(relay_rules, relay_rule);
#define TLSFLAG_TLSV1_00x02
#define TLSFLAG_TLSV1_10x04
#define TLSFLAG_TLSV1_20x08
-#define TLSFLAG_TLSV1 0x0e
+#define TLSFLAG_TLSV1_30x10
+#define TLSFLAG_TLSV1 0x1e
#define TLSFLAG_VERSION0x1f
#define TLSFLAG_CIPHER_SERVER_PREF 0x20
#define TLSFLAG_CLIENT_RENEG 0x40
#define TLSFLAG_DEFAULT\
- (TLSFLAG_TLSV1_2|TLSFLAG_CIPHER_SERVER_PREF)
+ (TLSFLAG_TLSV1_3|TLSFLAG_CIPHER_SERVER_PREF)
#define TLSFLAG_BITS \
- "\06\01sslv3\02tlsv1.0\03tlsv1.1\04tlsv1.2" \
+ "\06\01sslv3\02tlsv1.0\03tlsv1.1\04tlsv1.2\05tlsv1.3" \
"\06cipher-server-preference\07client-renegotiation"
#define TLSCIPHERS_DEFAULT "HIGH:!aNULL"
Re: syscall call-from verification
I missed the point, sorry. What I mean that without the patch, lang/go and go ports are fine on -current. On 11/30, Christian Weisgerber wrote: > Pavel Korovin: > > > In my partial dpb build, lang/go goes fine. > > My amd64 snapshot was custom-built from sources, dated 2019-11-30 ~02 a.m. > > ... and obviously without Theo's patch to sys/kern/exec_elf.c from > earlier in this thread. -- With best regards, Pavel Korovin
Re: syscall call-from verification
In my partial dpb build, lang/go goes fine. My amd64 snapshot was custom-built from sources, dated 2019-11-30 ~02 a.m. go ports (net/mattermos-server, sysutils/beats/filebeat, www/gitea) are functional. On 11/30, Christian Weisgerber wrote: > > I'm running an amd64 bulk build with this. > > The build failures were: > lang/fpc > lang/go > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > -- With best regards, Pavel Korovin
relayd(8) websockets proxy broken after adding websockets support
Dear all,
After websockets support was added in relayd(8),
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/relayd/relay_http.c.diff?r1=1.71&r2=1.72&f=h
the connections to services usging websockets are broken.
I checked what caused this breakage, and found that the check for the
"Connection" HTTP request header strictly checks for "Upgrade" value (line 402):
if (cre->dir == RELAY_DIR_REQUEST) {
if (strcasecmp("Connection", key) == 0 &&
strcasecmp("Upgrade", value) == 0)
priv->http_upgrade_req |=
HTTP_CONNECTION_UPGRADE;
while the browser can also send (and sends)
Connection: keep-alive, Upgrade
Websockets work fine if I add keep-alive to the list of values, but I'm sure
this must be fixed in some other way,
--- usr.sbin/relayd/relay_http.c.orig Wed Apr 3 17:41:00 2019
+++ usr.sbin/relayd/relay_http.cWed Apr 3 21:31:37 2019
@@ -400,7 +400,8 @@
if (cre->line != 1) {
if (cre->dir == RELAY_DIR_REQUEST) {
if (strcasecmp("Connection", key) == 0 &&
- strcasecmp("Upgrade", value) == 0)
+ (strcasecmp("Upgrade", value) == 0 ||
+ strcasecmp("keep-alive, Upgrade", value) ==
0))
priv->http_upgrade_req |=
HTTP_CONNECTION_UPGRADE;
if (strcasecmp("Upgrade", key) == 0 &&
--
With best regards,
Pavel Korovin
Re: smtpd: log ip/hostname for failed-command events
Dear all,
I have local patch which implements IP/hostname logging for all SMTP operations.
It simplifies log processing for me since I don't have to keep reference
between session ids and IPs/hostnames and check it every time I need to check
who's originating given SMTP transaction.
Does it make sense for anybody else?
--
With best regards,
Pavel Korovin
Index: usr.sbin/smtpd/mta.c
===
RCS file: /cvs/src/usr.sbin/smtpd/mta.c,v
retrieving revision 1.201
diff -u -p -r1.201 mta.c
--- usr.sbin/smtpd/mta.c22 May 2016 16:31:21 - 1.201
+++ usr.sbin/smtpd/mta.c22 Aug 2016 19:33:08 -
@@ -1610,8 +1610,8 @@ mta_log(const struct mta_envelope *evp,
const char *relay, const char *status)
{
log_info("%016"PRIx64" mta event=delivery evpid=%016"PRIx64" "
- "from=<%s> to=<%s> rcpt=<%s> source=%s "
- "relay=%s delay=%s result=%s stat=%s",
+ "from=<%s> to=<%s> rcpt=<%s> source=\"%s\" "
+ "relay=\"%s\" delay=%s result=\"%s\" stat=\"%s\"",
evp->session,
evp->id,
evp->task->sender,
Index: usr.sbin/smtpd/smtp_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
retrieving revision 1.285
diff -u -p -r1.285 smtp_session.c
--- usr.sbin/smtpd/smtp_session.c 29 Jul 2016 08:53:07 - 1.285
+++ usr.sbin/smtpd/smtp_session.c 22 Aug 2016 19:33:08 -
@@ -903,9 +903,10 @@ smtp_session_imsg(struct mproc *p, struc
s->tx->msgid);
TAILQ_FOREACH(rcpt, &s->tx->rcpts, entry) {
- log_info("%016"PRIx64" smtp event=message msgid=%08x "
- "from=<%s%s%s> to=<%s%s%s> size=%zu ndest=%zu
proto=%s",
+ log_info("%016"PRIx64" smtp event=message address=%s
host=%s "
+ "msgid=%08x from=<%s%s%s> to=<%s%s%s> size=%zu
ndest=%zu proto=%s",
s->id,
+ ss_to_text(&s->ss), s->hostname,
s->tx->msgid,
s->tx->evp.sender.user,
s->tx->evp.sender.user[0] == '\0' ? "" : "@",
@@ -969,8 +970,9 @@ smtp_session_imsg(struct mproc *p, struc
s = tree_xpop(&wait_ssl_init, resp_ca_cert->reqid);
if (resp_ca_cert->status == CA_FAIL) {
- log_info("%016"PRIx64" smtp event=closed
reason=ca-failure",
- s->id);
+ log_info("%016"PRIx64" smtp event=closed address=%s
host=%s "
+ "reason=ca-failure",
+ s->id, ss_to_text(&s->ss), s->hostname);
smtp_free(s, "CA failure");
return;
}
@@ -996,8 +998,8 @@ smtp_session_imsg(struct mproc *p, struc
s->flags |= SF_VERIFIED;
else if (s->listener->flags & F_TLS_VERIFY) {
log_info("%016"PRIx64" smtp "
- "event=closed reason=cert-check-failed",
- s->id);
+ "event=closed address=%s host=%s
reason=cert-check-failed",
+ s->id, ss_to_text(&s->ss), s->hostname);
smtp_free(s, "SSL certificate check failed");
return;
}
@@ -1034,8 +1036,8 @@ smtp_filter_response(uint64_t id, int qu
case QUERY_CONNECT:
if (status != FILTER_OK) {
log_info("%016"PRIx64" smtp "
- "event=closed reason=filter-reject",
- s->id);
+ "event=closed address=%s host=%s
reason=filter-reject",
+ s->id, ss_to_text(&s->ss), s->hostname);
smtp_free(s, "rejected by filter");
return;
}
@@ -1255,8 +1257,8 @@ smtp_io(struct io *io, int evt)
switch (evt) {
case IO_TLSREADY:
- log_info("%016"PRIx64" smtp event=starttls ciphers=\"%s\"",
- s->id, ssl_to_text(s->io.ssl));
+ log_info("%016"PRIx64" smtp event=starttls address=%s ho
[patch] adding quotes for space-containing values in smtpd(8) logs
Dear all,
Could you consider quoting the space-containing values in smtpd log
messages?
I like the latest smtpd log format improvements, but it's hard to parse
space-separated key-value pairs if they have space-containing values :)
Please see the patch attached.
--
With best regards,
Pavel Korovin
Index: smtp_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
retrieving revision 1.272
diff -u -p -r1.272 smtp_session.c
--- smtp_session.c 22 May 2016 16:31:21 - 1.272
+++ smtp_session.c 2 Jun 2016 12:55:51 -
@@ -1258,7 +1258,7 @@ smtp_io(struct io *io, int evt)
switch (evt) {
case IO_TLSREADY:
- log_info("%016"PRIx64" smtp event=starttls ciphers=%s",
+ log_info("%016"PRIx64" smtp event=starttls ciphers=\"%s\"",
s->id, ssl_to_text(s->io.ssl));
s->flags |= SF_SECURE;
@@ -1283,7 +1283,7 @@ smtp_io(struct io *io, int evt)
x = SSL_get_peer_certificate(s->io.ssl);
if (x) {
log_info("%016"PRIx64" smtp "
- "event=client-cert-check result=%s",
+ "event=client-cert-check result=\"%s\"",
s->id,
(s->flags & SF_VERIFIED) ? "success" : "failure");
X509_free(x);
@@ -1402,7 +1402,7 @@ smtp_io(struct io *io, int evt)
break;
case IO_ERROR:
- log_info("%016"PRIx64" smtp event=closed reason=io-error: %s",
+ log_info("%016"PRIx64" smtp event=closed reason=\"io-error:
%s\"",
s->id, io->error);
smtp_free(s, "IO error");
break;
@@ -2183,7 +2183,7 @@ smtp_reply(struct smtp_session *s, char
case '4':
if (s->flags & SF_BADINPUT) {
log_info("%016"PRIx64" smtp "
- "event=bad-input result=%.*s",
+ "event=bad-input result=\"%.*s\"",
s->id, n, buf);
}
else if (s->state == STATE_AUTH_INIT) {
@@ -2201,7 +2201,7 @@ smtp_reply(struct smtp_session *s, char
else {
strnvis(tmp, s->cmd, sizeof tmp, VIS_SAFE | VIS_CSTYLE);
log_info("%016"PRIx64" smtp "
- "event=failed-command command=%s result=%.*s",
+ "event=failed-command command=\"%s\"
result=\"%.*s\"",
s->id, tmp, n, buf);
}
break;
