Re: Possible typo in pf NAT FAQ

[Ashlen]

On Sun, 18 Jun 2023 20:35 +0200, Stephan Neuhaus wrote:
> Hi list
> 
> I think I have found a typo in the pf NAT FAQ here:
> https://www.openbsd.org/faq/pf/nat.html. In the
> "Configuring NAT" section it says:
> 
>   The general format in pf.conf looks something like this:
> 
>   match out on interface [af] \
>  from src_addr to dst_addr \
>  nat-to ext_addr [pool_type] [static-port]
>   [...]
>   pass out [log] on interface [af] [proto protocol] \
>  from ext_addr [port src_port] \
>  to dst_addr [port dst_port]
> 
> As you can see, the pass rule says "from ext_addr".
> But beneath the description of the various options, it
> says:
> 
>   This would lead to a most basic form of these lines similar to this:
> 
>   match out on tl0 from 192.168.1.0/24 to any nat-to 198.51.100.1
>   pass on tl0 from 192.168.1.0/24 to any
> 
> Here you can see that the "from" part is what the
> above description calls the src_addr, not the
> ext_addr, as it claims. This makes much more sense and
> is consistent with all the other documentation that
> I've seen.
> 
> So could it be a typo in the docs? Or have I missed some things?
> 
> Thanks in advance
> 
> Stephan
> 

That looks like a typo to me. Changing CC to include tech@ and drop
misc@ (I've been told it's bad form to send patches on misc@).
Index: nat.html
===
RCS file: /cvs/www/faq/pf/nat.html,v
retrieving revision 1.79
diff -u -p -r1.79 nat.html
--- nat.html12 May 2021 15:13:25 -  1.79
+++ nat.html19 Jun 2023 00:18:15 -
@@ -166,7 +166,7 @@ match out on interface [af] \
nat-to ext_addr [pool_type] [static-port]
 [...]
 pass out [log] on interface [af] [proto protocol] \
-   from ext_addr [port src_port] \
+   from src_addr [port src_port] \
to dst_addr [port dst_port]
 
 

moncontrol(3), gprof(1): write, read gmon profiling data via utrace(2)

[Scott Cheloha]

This patch changes libc's _mcleanup() function so it serializes gmon
profiling data with utrace(2).  gprof(1) is also modified: it can now
deserialize that profiling data from a ktrace(2) file.

Only apply this patch if you are testing the profclock() patch.

Index: lib/libc/gmon/gmon.c
===
RCS file: /cvs/src/lib/libc/gmon/gmon.c,v
retrieving revision 1.33
diff -u -p -r1.33 gmon.c
--- lib/libc/gmon/gmon.c26 Jul 2022 04:07:13 -  1.33
+++ lib/libc/gmon/gmon.c19 Jun 2023 03:15:14 -
@@ -28,16 +28,22 @@
  * SUCH DAMAGE.
  */
 
-#include 
+#include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct gmonparam _gmonparam = { GMON_PROF_OFF };
@@ -47,6 +53,7 @@ static ints_scale;
 #defineSCALE_1_TO_10x1L
 
 #define ERR(s) write(STDERR_FILENO, s, sizeof(s))
+#define GMON_LABEL "_openbsd_libc_gmon"
 
 PROTO_NORMAL(moncontrol);
 PROTO_DEPRECATED(monstartup);
@@ -136,24 +143,17 @@ __strong_alias(_monstartup,monstartup);
 void
 _mcleanup(void)
 {
-   int fd;
-   int fromindex;
+   char ubuf[KTR_USER_MAXLEN + 1]; /* +1 for NUL, for snprintf(3) */
+   int error, fromindex, len;
int endfrom;
-   u_long frompc;
+   u_long frompc, i, j, limit;
int toindex;
struct rawarc rawarc;
struct gmonparam *p = &_gmonparam;
struct gmonhdr gmonhdr, *hdr;
struct clockinfo clockinfo;
const int mib[2] = { CTL_KERN, KERN_CLOCKRATE };
-   size_t size;
-   char *profdir;
-   char *proffile;
-   char  buf[PATH_MAX];
-#ifdef DEBUG
-   int log, len;
-   char dbuf[200];
-#endif
+   size_t off, sample_limit, sample_total, size;
 
if (p->state == GMON_PROF_ERROR)
ERR("_mcleanup: tos overflow\n");
@@ -171,66 +171,7 @@ _mcleanup(void)
 
moncontrol(0);
 
-   if (issetugid() == 0 && (profdir = getenv("PROFDIR")) != NULL) {
-   char *s, *t, *limit;
-   pid_t pid;
-   long divisor;
-
-   /* If PROFDIR contains a null value, no profiling
-  output is produced */
-   if (*profdir == '\0') {
-   return;
-   }
-
-   limit = buf + sizeof buf - 1 - 10 - 1 -
-   strlen(__progname) - 1;
-   t = buf;
-   s = profdir;
-   while((*t = *s) != '\0' && t < limit) {
-   t++;
-   s++;
-   }
-   *t++ = '/';
-
-   /*
-* Copy and convert pid from a pid_t to a string.  For
-* best performance, divisor should be initialized to
-* the largest power of 10 less than PID_MAX.
-*/
-   pid = getpid();
-   divisor=1;
-   while (divisor > pid) divisor /= 10;/* skip leading zeros */
-   do {
-   *t++ = (pid/divisor) + '0';
-   pid %= divisor;
-   } while (divisor /= 10);
-   *t++ = '.';
-
-   s = __progname;
-   while ((*t++ = *s++) != '\0')
-   ;
-
-   proffile = buf;
-   } else {
-   proffile = "gmon.out";
-   }
-
-   fd = open(proffile , O_CREAT|O_TRUNC|O_WRONLY, 0664);
-   if (fd == -1) {
-   perror( proffile );
-   return;
-   }
-#ifdef DEBUG
-   log = open("gmon.log", O_CREAT|O_TRUNC|O_WRONLY, 0664);
-   if (log == -1) {
-   perror("mcount: gmon.log");
-   close(fd);
-   return;
-   }
-   snprintf(dbuf, sizeof dbuf, "[mcleanup1] kcount 0x%x ssiz %d\n",
-   p->kcount, p->kcountsize);
-   write(log, dbuf, strlen(dbuf));
-#endif
+   /* First, serialize the gmon header. */
hdr = (struct gmonhdr *)
bzero(hdr, sizeof(*hdr));
hdr->lpc = p->lowpc;
@@ -238,8 +179,48 @@ _mcleanup(void)
hdr->ncnt = p->kcountsize + sizeof(gmonhdr);
hdr->version = GMONVERSION;
hdr->profrate = clockinfo.profhz;
-   write(fd, (char *)hdr, sizeof *hdr);
-   write(fd, p->kcount, p->kcountsize);
+   len = snprintf(ubuf, sizeof ubuf, "gmonhdr %lx %lx %x %x %x",
+   hdr->lpc, hdr->hpc, hdr->ncnt, hdr->version, hdr->profrate);
+   if (len == -1 || len >= sizeof ubuf)
+   goto out;
+   if (utrace(GMON_LABEL, ubuf, len) == -1)
+   goto out;
+
+   /*
+* Next, serialize the kcount sample array.  Each trace is prefixed
+* with the string "kcount" (6).  Each sample is prefixed with a
+* delimiting space (1) and serialized as a 4-digit hexadecimal
+* value (4).  The buffer, ubuf, is KTR_USER_MAXLEN + 1 

Re: uvm_meter: improve periodic execution logic for uvm_loadav()

[Scott Cheloha]

On Sun, Jun 18, 2023 at 12:36:07PM -0500, Scott Cheloha wrote:
> On Sun, Jun 18, 2023 at 07:32:56PM +0200, Mark Kettenis wrote:
> > > Date: Sun, 18 Jun 2023 12:27:17 -0500
> > > From: Scott Cheloha 
> > > 
> > > The intent here is to update the load averages every five seconds.
> > > However:
> > > 
> > > 1. Measuring elapsed time with the UTC clock is unreliable because of
> > >settimeofday(2).
> > > 
> > > 2. "Call uvm_loadav() no more than once every five seconds", is not
> > > equivalent to "call uvm_loadav() if the current second is equal
> > > to zero, modulo five".
> > > 
> > >Not hard to imagine edge cases where timeouts are delayed and
> > >the load averages are not updated.
> > > 
> > > So, (1) use the monotonic clock, and (2) keep the next uvm_loadav()
> > > call time in a static value.
> > > 
> > > ok?
> > 
> > I really don't see why the calculatin of something vague like the load
> > average warrants complicating the code like this.
> 
> Aren't load averages used to make decisions about thread placement in
> the scheduler?
> 
> Regardless, the code is still wrong.  At minimum you should use
> getuptime(9).

Maybe I misunderstood.  Are you suggesting this?


now = getuptime();
if (now >= next_uvm_loadav) {
next_uvm_loadav = now + 5;
uvm_loadav(...);
}

The patch I posted preserves the current behavior.  It is equivalent
to:

while (next_uvm_loadav <= now)
next_uvm_loadav += 5;

Changing it to (now + 5) changes the behavior.

Index: uvm_meter.c
===
RCS file: /cvs/src/sys/uvm/uvm_meter.c,v
retrieving revision 1.42
diff -u -p -r1.42 uvm_meter.c
--- uvm_meter.c 28 Dec 2020 14:01:23 -  1.42
+++ uvm_meter.c 18 Jun 2023 17:11:09 -
@@ -87,8 +87,16 @@ void uvmexp_read(struct uvmexp *);
 void
 uvm_meter(void)
 {
-   if ((gettime() % 5) == 0)
+   static time_t next_uvm_loadav;
+   time_t intvl_count, now;
+
+   now = getuptime();
+   if (now >= next_uvm_loadav) {
+   intvl_count = (now - next_uvm_loadav) / 5 + 1;
+   next_uvm_loadav += 5 * intvl_count;
uvm_loadav();
+   }
+
if (proc0.p_slptime > (maxslp / 2))
wakeup();
 }

Re: uvm_meter: improve periodic execution logic for uvm_loadav()

[Scott Cheloha]

On Sun, Jun 18, 2023 at 07:32:56PM +0200, Mark Kettenis wrote:
> > Date: Sun, 18 Jun 2023 12:27:17 -0500
> > From: Scott Cheloha 
> > 
> > The intent here is to update the load averages every five seconds.
> > However:
> > 
> > 1. Measuring elapsed time with the UTC clock is unreliable because of
> >settimeofday(2).
> > 
> > 2. "Call uvm_loadav() no more than once every five seconds", is not
> > equivalent to "call uvm_loadav() if the current second is equal
> > to zero, modulo five".
> > 
> >Not hard to imagine edge cases where timeouts are delayed and
> >the load averages are not updated.
> > 
> > So, (1) use the monotonic clock, and (2) keep the next uvm_loadav()
> > call time in a static value.
> > 
> > ok?
> 
> I really don't see why the calculatin of something vague like the load
> average warrants complicating the code like this.

Aren't load averages used to make decisions about thread placement in
the scheduler?

Regardless, the code is still wrong.  At minimum you should use
getuptime(9).

Re: uvm_meter: improve periodic execution logic for uvm_loadav()

[Mark Kettenis]

> Date: Sun, 18 Jun 2023 12:27:17 -0500
> From: Scott Cheloha 
> 
> The intent here is to update the load averages every five seconds.
> However:
> 
> 1. Measuring elapsed time with the UTC clock is unreliable because of
>settimeofday(2).
> 
> 2. "Call uvm_loadav() no more than once every five seconds", is not
> equivalent to "call uvm_loadav() if the current second is equal
> to zero, modulo five".
> 
>Not hard to imagine edge cases where timeouts are delayed and
>the load averages are not updated.
> 
> So, (1) use the monotonic clock, and (2) keep the next uvm_loadav()
> call time in a static value.
> 
> ok?

I really don't see why the calculatin of something vague like the load
average warrants complicating the code like this.

> Index: uvm_meter.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_meter.c,v
> retrieving revision 1.42
> diff -u -p -r1.42 uvm_meter.c
> --- uvm_meter.c   28 Dec 2020 14:01:23 -  1.42
> +++ uvm_meter.c   18 Jun 2023 17:11:09 -
> @@ -87,8 +87,16 @@ void uvmexp_read(struct uvmexp *);
>  void
>  uvm_meter(void)
>  {
> - if ((gettime() % 5) == 0)
> + static time_t next_uvm_loadav;
> + time_t intvl_count, now;
> +
> + now = getuptime();
> + if (now >= next_uvm_loadav) {
> + intvl_count = (now - next_uvm_loadav) / 5 + 1;
> + next_uvm_loadav += 5 * intvl_count;
>   uvm_loadav();
> + }
> +
>   if (proc0.p_slptime > (maxslp / 2))
>   wakeup();
>  }
> 
> 

uvm_meter: improve periodic execution logic for uvm_loadav()

[Scott Cheloha]

The intent here is to update the load averages every five seconds.
However:

1. Measuring elapsed time with the UTC clock is unreliable because of
   settimeofday(2).

2. "Call uvm_loadav() no more than once every five seconds", is not
equivalent to "call uvm_loadav() if the current second is equal
to zero, modulo five".

   Not hard to imagine edge cases where timeouts are delayed and
   the load averages are not updated.

So, (1) use the monotonic clock, and (2) keep the next uvm_loadav()
call time in a static value.

ok?

Index: uvm_meter.c
===
RCS file: /cvs/src/sys/uvm/uvm_meter.c,v
retrieving revision 1.42
diff -u -p -r1.42 uvm_meter.c
--- uvm_meter.c 28 Dec 2020 14:01:23 -  1.42
+++ uvm_meter.c 18 Jun 2023 17:11:09 -
@@ -87,8 +87,16 @@ void uvmexp_read(struct uvmexp *);
 void
 uvm_meter(void)
 {
-   if ((gettime() % 5) == 0)
+   static time_t next_uvm_loadav;
+   time_t intvl_count, now;
+
+   now = getuptime();
+   if (now >= next_uvm_loadav) {
+   intvl_count = (now - next_uvm_loadav) / 5 + 1;
+   next_uvm_loadav += 5 * intvl_count;
uvm_loadav();
+   }
+
if (proc0.p_slptime > (maxslp / 2))
wakeup();
 }

Re: recent malloc changes

[Why 42? The lists account.]

On Sun, Jun 18, 2023 at 04:46:46PM +0200, Why 42? The lists account. wrote:
> Jun 18 16:18:23 mjoelnir mdnsd: startup
> Jun 18 16:18:23 mjoelnir mdnsd: fatal: bind: Address already in use
> Jun 18 16:23:02 mjoelnir mdnsd: startup
> Jun 18 16:23:02 mjoelnir mdnsd: fatal: bind: Address already in use

So, this issue "Address in use" was because mdnsd and avahi-daemon were
fighting over the same port, likely 5353. My fault.

Once I stop the avahi daemon, I can start mdnsd OK (and vice versa).

Still seems that mdnsd exits with 0 when it fails to start e.g. when
given a nonexistant interface:

mjoelnir:robb 18.06 17:41:08 # mdnsd le0
mjoelnir:robb 18.06 17:41:12 # echo $?
0

mjoelnir:robb 18.06 17:41:18 # pgrep -l mdnsd
mjoelnir:robb 18.06 17:41:24 [$?==1]#

mjoelnir:robb 18.06 17:41:24 [$?==1]# grep mdnsd /var/log/daemon | tail -3
Jun 18 17:41:12 mjoelnir mdnsd: startup
Jun 18 17:41:12 mjoelnir mdnsd: Unknown interface le0
Jun 18 17:41:12 mjoelnir mdnsd: fatal: Couldn't find any interface

This then confuses the rcctl script.

So IMHO that would also be a potential improvement.

Cheers,
Robb.

Fwd: [openbsd/src] https://redmine.pfsense.org/issues/14444 (PR #39)

[Jonathan Lee]

Hello I was directed to email this mailing list.

Docker container OS fingerprints are missing from p0f database.

Please see following Redmine that helps showcase this. The closed pull
request also lists location in database file for os fingerprints.

Jonathan Lee
Adult Student

-- Forwarded message -
From: Stuart Henderson 
Date: Sun, Jun 18, 2023, 6:53 AM
Subject: Re: [openbsd/src] https://redmine.pfsense.org/issues/1 (PR #39)
To: openbsd/src 
Cc: Jonathan David Lee , Author <
aut...@noreply.github.com>


Closed #39 .

—
Reply to this email directly, view it on GitHub
, or unsubscribe

.
You are receiving this because you authored the thread.Message ID:

Re: smtpd: sync imsg_to_str()

[Todd C . Miller]

On Sun, 18 Jun 2023 16:49:30 +0200, Omar Polo wrote:

> some imsg types are missing from the big switch in imsg_to_str(),
> noticed after a report in m...@opensmtpd.org.  Tracing shows:
>
> : imsg: lka <- dispatcher: IMSG_??? (139) (len=42)
>
> (imsg #139 should be IMSG_REPORT_SMTP_FILTER_RESPONSE if I'm counting
> right.)
>
> Instead of checking one by one (they're a lot!) I just copied over the
> list from smtpd.h and ran an emacs macro.  Some entries changed place,
> but since the list is long I figured this was the best way to keep
> everything in sync.

Using the same order as smtpd.h makes sense.  OK millert@

 - todd

smtpd: sync imsg_to_str()

[Omar Polo]

some imsg types are missing from the big switch in imsg_to_str(),
noticed after a report in m...@opensmtpd.org.  Tracing shows:

: imsg: lka <- dispatcher: IMSG_??? (139) (len=42)

(imsg #139 should be IMSG_REPORT_SMTP_FILTER_RESPONSE if I'm counting
right.)

Instead of checking one by one (they're a lot!) I just copied over the
list from smtpd.h and ran an emacs macro.  Some entries changed place,
but since the list is long I figured this was the best way to keep
everything in sync.

ok?

diff /usr/src
commit - af580bd60cce9d8599fddb1cffa69d16b70ae3a7
path + /usr/src
blob - 0bd24de8a65d0655a9866c5d3e66ad82a152959a
file + usr.sbin/smtpd/smtpd.c
--- usr.sbin/smtpd/smtpd.c
+++ usr.sbin/smtpd/smtpd.c
@@ -2081,19 +2081,22 @@ imsg_to_str(int type)
 
CASE(IMSG_REPORT_SMTP_LINK_CONNECT);
CASE(IMSG_REPORT_SMTP_LINK_DISCONNECT);
-   CASE(IMSG_REPORT_SMTP_LINK_TLS);
CASE(IMSG_REPORT_SMTP_LINK_GREETING);
CASE(IMSG_REPORT_SMTP_LINK_IDENTIFY);
+   CASE(IMSG_REPORT_SMTP_LINK_TLS);
CASE(IMSG_REPORT_SMTP_LINK_AUTH);
-
CASE(IMSG_REPORT_SMTP_TX_RESET);
CASE(IMSG_REPORT_SMTP_TX_BEGIN);
+   CASE(IMSG_REPORT_SMTP_TX_MAIL);
+   CASE(IMSG_REPORT_SMTP_TX_RCPT);
CASE(IMSG_REPORT_SMTP_TX_ENVELOPE);
+   CASE(IMSG_REPORT_SMTP_TX_DATA);
CASE(IMSG_REPORT_SMTP_TX_COMMIT);
CASE(IMSG_REPORT_SMTP_TX_ROLLBACK);
-
CASE(IMSG_REPORT_SMTP_PROTOCOL_CLIENT);
CASE(IMSG_REPORT_SMTP_PROTOCOL_SERVER);
+   CASE(IMSG_REPORT_SMTP_FILTER_RESPONSE);
+   CASE(IMSG_REPORT_SMTP_TIMEOUT);
 
CASE(IMSG_FILTER_SMTP_BEGIN);
CASE(IMSG_FILTER_SMTP_END);
@@ -2104,6 +2107,7 @@ imsg_to_str(int type)
CASE(IMSG_CA_RSA_PRIVENC);
CASE(IMSG_CA_RSA_PRIVDEC);
CASE(IMSG_CA_ECDSA_SIGN);
+
default:
(void)snprintf(buf, sizeof(buf), "IMSG_??? (%d)", type);
 

Re: recent malloc changes

[Why 42? The lists account.]

On Sun, Jun 18, 2023 at 03:34:27PM +0200, Otto Moerbeek wrote:
> So what's in your malloc options?

Er, nothing:
mjoelnir:robb 18.06 15:57:29 [$?==1]# echo $MALLOC_OPTIONS

mjoelnir:robb 18.06 15:57:40 # echo $MALLOC_OPTIONS | cat -vet
$

mjoelnir:robb 18.06 15:59:25 [$?==1]# unset MALLOC_OPTIONS

mjoelnir:robb 18.06 15:59:30 # mdnsd -d
malloc() warning: unknown char in MALLOC_OPTIONS
malloc() warning: unknown char in MALLOC_OPTIONS


But I think that I now see how I managed to trigger this ...

I commented out the "mdnsd_flags" entry in /etc/rc.conf.local while
trying to debug the "simple-scan" application.

(simple-scan starts but doesn't do anything and I noticed that I had
previously (2021) left myself a hint in that file: "Reverted to avahid
since scanner not detected with mdnsd")

I would have probably done better to have changed that line to say "=NO"
instead.

Still doesn't start though ... Now I see this log message:
mjoelnir:robb 18.06 16:23:21 # grep mdnsd /var/log/daemon
...
Jun 18 16:18:23 mjoelnir mdnsd: startup
Jun 18 16:18:23 mjoelnir mdnsd: fatal: bind: Address already in use
Jun 18 16:23:02 mjoelnir mdnsd: startup
Jun 18 16:23:02 mjoelnir mdnsd: fatal: bind: Address already in use

Interesting that the startup script returns OK:
mjoelnir:robb 18.06 16:32:43 [$?==1]# rcctl start mdnsd
mdnsd(ok)

Log file:
Jun 18 16:32:45 mjoelnir mdnsd: startup
Jun 18 16:32:45 mjoelnir mdnsd: fatal: bind: Address already in use

mjoelnir:robb 18.06 16:34:21 # pgrep -l dns
mjoelnir:robb 18.06 16:34:26 [$?==1]#

Maybe the daemon isn't returning a bad exit status?

I tried "ktrace -di mdnsd" but couldn't spot any obvious error. It would
be nice if the error message included the bind address, i mean the port
number.

I'll try a reboot ...

Cheers,
Robb.

Re: recent malloc changes

[Otto Moerbeek]

On Sun, Jun 18, 2023 at 03:51:20PM +0200, Theo Buehler wrote:

> > So what's in your malloc options?
> 
> mdnsd -d must have thrown this warning for nearly 7 years. With d, it sets
> 'malloc_options = "AFGJPX";'. You removed A and P end of october 2016.

Sigh should be "S". 

I take care to make sure that S always has the meaning: all flags that
enable extra strict checking or otherwise enhance securiy but cannot
be enabled always for performance reasons. 

All other flag are subject to change.

-Otto

Re: Pull Request: Addition of String Data Type in /sys/sys/types.h

[Scott Cheloha]

> On Jun 18, 2023, at 02:19, Abderrahmane Ghellab 
>  wrote:
> 
> [...]
> 
> In my pull request , I made a
> simple modification to the file by adding a new line to introduce a string
> data type. Below, you can find the diff highlighting the changes made:
> 
> ```diff
> 4848   #endif
> 4949
> 5050   #if __BSD_VISIBLE
>51 + typedef char * string; /*String Data Type: Better than writing
> char* every time*/
> 5152typedef unsigned char u_char;
> 5253typedef unsigned short u_short;
> 5354typedef unsigned int u_int;
> ```
> 
> The addition of the `string` data type aims to enhance code readability and
> reduce verbosity. Instead of explicitly writing `char*` every time a string
> is declared, developers can now utilize the `string` type for convenience
> and brevity.
> 
> I believe that this modification can contribute positively to the OpenBSD
> codebase, simplifying code maintenance and making it more intuitive for
> developers. It aligns with the philosophy of OpenBSD to provide a secure,
> simple, and clean operating system.

this is a very high-quality troll, nice

Re: recent malloc changes

[Theo Buehler]

> So what's in your malloc options?

mdnsd -d must have thrown this warning for nearly 7 years. With d, it sets
'malloc_options = "AFGJPX";'. You removed A and P end of october 2016.

Re: recent malloc changes

[Otto Moerbeek]

On Sun, Jun 18, 2023 at 03:24:17PM +0200, Why 42? The lists account. wrote:

> 
> On Sun, Jun 04, 2023 at 01:03:14PM +0200, Otto Moerbeek wrote:
> > Hello,
> > 
> > In the last few weeks a series of mallocs diff have been committed.
> > The last one today. That one allows malloc to detect more cases of
> > write-after-free. While that is a good thing, it might uncover latent
> > bugs in appliations. 
> > 
> > So if you are running current or snapshots, please keep an eye out for
> > issues reported by malloc. If we get too many reports of issues I
> > might change things so the extra write-after-free detetecion is ony
> > enabled when malloc option S is active.
> 
> Well, I don't know if this related, but I just noticed this:
> mjoelnir:robb 18.06 15:17:30 # rcctl check mdnsd
> mdnsd(failed)
> 
> mjoelnir:robb 18.06 15:17:32 [$?==1]# rcctl restart mdnsd
> mdnsd(ok)
> 
> mjoelnir:robb 18.06 15:17:37 # rcctl check mdnsd
> mdnsd(failed)
> 
> mjoelnir:robb 18.06 15:17:39 [$?==1]# pgrep -l mdnsd
> mjoelnir:robb 18.06 15:18:06 [$?==1]#
> 
> mjoelnir:robb 18.06 15:18:07 [$?==1]# mdnsd -h
> mdnsd: unknown option -- h
> usage: mdnsd [-dw] ifname [ifnames...]
> usage: mdnsd -v
> 
> mjoelnir:robb 18.06 15:18:22 [$?==1]# mdnsd -dv
> malloc() warning: unknown char in MALLOC_OPTIONS
> malloc() warning: unknown char in MALLOC_OPTIONS

So what's in your malloc options?

-Otto

> OpenMdns Daemon 0.7 (2017-03-10)
> Copyright (C) 2010-2014 Christiano F. Haesbaert
> mjoelnir:robb 18.06 15:18:30 #
> 
> mjoelnir:robb 18.06 15:18:33 # pgrep -l mdnsd
> mjoelnir:robb 18.06 15:18:36 [$?==1]# mdnsd -d
> malloc() warning: unknown char in MALLOC_OPTIONS
> malloc() warning: unknown char in MALLOC_OPTIONS
> usage: mdnsd [-dw] ifname [ifnames...]
> usage: mdnsd -v
> 
> This is with a 7.3 snapshot from about a week ago:
> mjoelnir:robb 18.06 15:22:22 # ls -ltr /bsd*
> -rwx--  1 root  wheel  25245701 Jun 11 13:42 /bsd.sp
> -rw---  1 root  wheel   4674809 Jun 11 13:42 /bsd.rd
> -rwx--  1 root  wheel  25364480 Jun 11 13:44 /bsd.booted
> -rwx--  1 root  wheel  25375272 Jun 11 13:56 /bsd
> 
> mjoelnir:robb 18.06 15:21:53 # uname -a
> OpenBSD mjoelnir.fritz.box 7.3 GENERIC.MP#1230 amd64
> 

Re: recent malloc changes

[Why 42? The lists account.]

On Sun, Jun 04, 2023 at 01:03:14PM +0200, Otto Moerbeek wrote:
> Hello,
> 
> In the last few weeks a series of mallocs diff have been committed.
> The last one today. That one allows malloc to detect more cases of
> write-after-free. While that is a good thing, it might uncover latent
> bugs in appliations. 
> 
> So if you are running current or snapshots, please keep an eye out for
> issues reported by malloc. If we get too many reports of issues I
> might change things so the extra write-after-free detetecion is ony
> enabled when malloc option S is active.

Well, I don't know if this related, but I just noticed this:
mjoelnir:robb 18.06 15:17:30 # rcctl check mdnsd
mdnsd(failed)

mjoelnir:robb 18.06 15:17:32 [$?==1]# rcctl restart mdnsd
mdnsd(ok)

mjoelnir:robb 18.06 15:17:37 # rcctl check mdnsd
mdnsd(failed)

mjoelnir:robb 18.06 15:17:39 [$?==1]# pgrep -l mdnsd
mjoelnir:robb 18.06 15:18:06 [$?==1]#

mjoelnir:robb 18.06 15:18:07 [$?==1]# mdnsd -h
mdnsd: unknown option -- h
usage: mdnsd [-dw] ifname [ifnames...]
usage: mdnsd -v

mjoelnir:robb 18.06 15:18:22 [$?==1]# mdnsd -dv
malloc() warning: unknown char in MALLOC_OPTIONS
malloc() warning: unknown char in MALLOC_OPTIONS
OpenMdns Daemon 0.7 (2017-03-10)
Copyright (C) 2010-2014 Christiano F. Haesbaert
mjoelnir:robb 18.06 15:18:30 #

mjoelnir:robb 18.06 15:18:33 # pgrep -l mdnsd
mjoelnir:robb 18.06 15:18:36 [$?==1]# mdnsd -d
malloc() warning: unknown char in MALLOC_OPTIONS
malloc() warning: unknown char in MALLOC_OPTIONS
usage: mdnsd [-dw] ifname [ifnames...]
usage: mdnsd -v

This is with a 7.3 snapshot from about a week ago:
mjoelnir:robb 18.06 15:22:22 # ls -ltr /bsd*
-rwx--  1 root  wheel  25245701 Jun 11 13:42 /bsd.sp
-rw---  1 root  wheel   4674809 Jun 11 13:42 /bsd.rd
-rwx--  1 root  wheel  25364480 Jun 11 13:44 /bsd.booted
-rwx--  1 root  wheel  25375272 Jun 11 13:56 /bsd

mjoelnir:robb 18.06 15:21:53 # uname -a
OpenBSD mjoelnir.fritz.box 7.3 GENERIC.MP#1230 amd64

Re: Pull Request: Addition of String Data Type in /sys/sys/types.h

[Ingo Schwarze]

Hi,

Abderrahmane Ghellab wrote on Sun, Jun 18, 2023 at 08:16:21AM +0100:

> I am writing to discuss a recent pull request I submitted

Never submit pull requests, for no reason whatsoever, full stop.
There is no excuse for doing that (except in a few related projects
like OpenSSH-portable).

> regarding the /sys/sys/types.h file.

As a general rule, don't add non-standard stuff to standard
headers:  is included by dozens of POSIX headers,
so you are inviting clashes and incompatibility issues in lots of
existing standard-compliant code.

Additions to standard headers require very robust justification.

> typedef char * string;
> /*String Data Type: Better than writing char* every time*/

This is completely ridiculous.  It is pure obfuscation.  Everybody
understands what char * means in C, nobody would know what a
user-defined data type "string" might be.  Besides, you are hiding
the fact that it is a pointer type.  In general, never typedef
"*" or "struct" away, it is valueable see them whenever the type
is used.  You are also making it harder for people to read the C
language standard and the POSIX standard because those will contonie
talking about char *, including in the official declarations of
function prototypes.  Arguing for brevity in something that is five
printable characters long and proposing a replacement that is also
five printable characters long is hilarious.  You are not even saving a
space character, "char *s" and "string s" are the exactly same length,
no matter whether you count whitespace or not.

There is no chance whatsoever of this, or anything similar, being
accepted.

Your main mistake is that you try to solve a problem where no
problem exists at all.

You severely harm clarity, readability, standards conformance,
and application code compatibility for no reason whatsoever.

> steps required from my end.

It you want to contribute, start by getting a better understanding
of the C programming language, of secure and standard compliant
programming practices, and of OpenBSD development goals and priorities.

Yours,
  Ingo

Diff for evaluation (WACOM tablet driver)

[Vladimir Meshcheriakov]

Good day,

I am currently trying to work on an implementation
of a driver for the WACOM tablet on openBSD
I am therefore submitting this diff so that it could potentially be evaluated.
Please if you have a moment, could you have a look at this diff?
I have tested it with my Wacom tablet
and it seems to work correctly,
the coding style is normally respected,
but I apologize in advance if my keen eyes have missed out something.

diff --git a/sys/dev/hid/hid.c b/sys/dev/hid/hid.c
index c758764f17a..20c0c501e91 100644
--- a/sys/dev/hid/hid.c
+++ b/sys/dev/hid/hid.c
@@ -657,3 +657,49 @@ hid_is_collection(const void *desc, int size, uint8_t id, 
int32_t usage)
hid_end_parse(hd);
return (0);
 }
+
+struct hid_data *
+hid_get_collection_data(const void *desc, int size, int32_t usage, uint32_t 
collection)
+{
+   struct hid_data *hd;
+   struct hid_item hi;
+
+   hd = hid_start_parse(desc, size, hid_all);
+
+   DPRINTF("%s: usage=0x%x\n", __func__, usage);
+   while (hid_get_item(hd, )) {
+   DPRINTF("%s: kind=%d id=%d usage=0x%x(0x%x)\n", __func__,
+   hi.kind, hi.report_ID, hi.usage, usage);
+   if (hi.kind == hid_collection &&
+   hi.collection == collection && hi.usage == usage){
+   DPRINTF("%s: found\n", __func__);
+   return hd;
+   }
+   }
+   DPRINTF("%s: not found\n", __func__);
+   hid_end_parse(hd);
+   return NULL;
+}
+
+int
+hid_get_id_of_collection(const void *desc, int size, int32_t usage, uint32_t 
collection)
+{
+   struct hid_data *hd;
+   struct hid_item hi;
+
+   hd = hid_start_parse(desc, size, hid_all);
+
+   DPRINTF("%s: id=%d usage=0x%x\n", __func__, id, usage);
+   while (hid_get_item(hd, )) {
+   DPRINTF("%s: kind=%d id=%d usage=0x%x(0x%x)\n", __func__,
+   hi.kind, hi.report_ID, hi.usage, usage);
+   if (hi.kind == hid_collection &&
+   hi.collection == collection && hi.usage == usage){
+   DPRINTF("%s: found\n", __func__);
+   return hi.report_ID;
+   }
+   }
+   DPRINTF("%s: not found\n", __func__);
+   hid_end_parse(hd);
+   return 0;
+}
diff --git a/sys/dev/hid/hid.h b/sys/dev/hid/hid.h
index 7400e920bc2..78bc4c403c5 100644
--- a/sys/dev/hid/hid.h
+++ b/sys/dev/hid/hid.h
@@ -93,6 +93,8 @@ int   hid_locate(const void *, int, int32_t, uint8_t, enum 
hid_kind,
 int32_thid_get_data(const uint8_t *buf, int, struct hid_location *);
 uint32_t hid_get_udata(const uint8_t *buf, int, struct hid_location *);
 inthid_is_collection(const void *, int, uint8_t, int32_t);
+struct hid_data *  hid_get_collection_data(const void *, int, int32_t, 
uint32_t);
+int hid_get_id_of_collection(const void *desc, int size, int32_t usage, 
uint32_t collection);
 
 #endif /* _KERNEL */
 
@@ -353,6 +355,7 @@ int hid_is_collection(const void *, int, uint8_t, int32_t);
 #define HUD_TOUCHSCREEN0x0004
 #define HUD_TOUCHPAD   0x0005
 #define HUD_CONFIG 0x000e
+#define HUD_STYLUS 0x0020
 #define HUD_FINGER 0x0022
 #define HUD_TIP_PRESSURE   0x0030
 #define HUD_BARREL_PRESSURE0x0031
@@ -387,6 +390,12 @@ inthid_is_collection(const void *, int, uint8_t, 
int32_t);
 #define HUD_CONTACT_MAX0x0055
 #define HUD_SCAN_TIME  0x0056
 #define HUD_BUTTON_TYPE0x0059
+#define HUD_SECONDARY_BARREL_SWITCH0x005A
+#define HUD_WACOM_X0x0130
+#define HUD_WACOM_Y0x0131
+#define HUD_WACOM_DISTANCE 0x0132
+#define HUD_WACOM_PAD_BUTTONS000x0910
+#define HUD_WACOM_BATTERY  0x1013
 
 /* Usages, LED */
 #define HUL_NUM_LOCK   0x0001
diff --git a/sys/dev/hid/hidms.c b/sys/dev/hid/hidms.c
index 622d5d9bc33..ec5c8d34d1b 100644
--- a/sys/dev/hid/hidms.c
+++ b/sys/dev/hid/hidms.c
@@ -37,6 +37,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -61,6 +62,219 @@ int hidmsdebug = 0;
 #define MOUSE_FLAGS_MASK   (HIO_CONST | HIO_RELATIVE)
 #define NOTMOUSE(f)(((f) & MOUSE_FLAGS_MASK) != HIO_RELATIVE)
 
+
+int
+stylus_hid_parse(struct hidms *ms, struct hid_data *d, uint32_t *flags) {
+   /* Define stylus reported usages: (maybe macros?) */
+   const uint32_t stylus_usage_tip
+   = HID_USAGE2(HUP_WACOM | HUP_DIGITIZERS, HUD_TIP_SWITCH);
+   const uint32_t stylus_usage_barrel
+   = HID_USAGE2(HUP_WACOM | HUP_DIGITIZERS, HUD_BARREL_SWITCH);
+   const uint32_t stylus_usage_sec_barrel = HID_USAGE2(
+   HUP_WACOM | HUP_DIGITIZERS, HUD_SECONDARY_BARREL_SWITCH);
+   const uint32_t stylus_usage_in_range
+   = HID_USAGE2(HUP_WACOM | HUP_DIGITIZERS, HUD_IN_RANGE);
+   const uint32_t stylus_usage_quality
+   =