Re: lladdr support for netstart/hostname.if

2022-11-24 Thread Theo de Raadt
Andrew spotted a potential issue with the short-circuit ordering, so
here is a newer diff.

Index: ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.385
diff -u -p -u -r1.385 ifconfig.8
--- ifconfig.8  26 Oct 2022 17:06:31 -  1.385
+++ ifconfig.8  24 Nov 2022 18:18:51 -
@@ -40,6 +40,7 @@
 .Sh SYNOPSIS
 .Nm ifconfig
 .Op Fl AaC
+.Op Fl M Ar lladdr
 .Op Ar interface
 .Op Ar address_family
 .Oo
@@ -88,6 +89,11 @@ This is the default, if no parameters ar
 Print the names of all network pseudo-devices that
 can be created dynamically at runtime using
 .Nm Cm create .
+.It Fl M Ar lladdr
+Scan the non-cloned interface list for the MAC address
+.Ar lladdr
+and print the name of that interface.
+If the MAC address is found on multiple interfaces, print nothing.
 .It Ar interface
 The
 .Ar interface
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.457
diff -u -p -u -r1.457 ifconfig.c
--- ifconfig.c  26 Oct 2022 17:06:31 -  1.457
+++ ifconfig.c  24 Nov 2022 19:19:55 -
@@ -368,6 +368,9 @@ voidwg_status(int);
 void   setignore(const char *, int);
 #endif
 
+struct if_clonereq *get_cloners(void);
+intfindmac(const char *);
+
 /*
  * Media stuff.  Whenever a media command is first performed, the
  * currently select media is grabbed for this interface.  If `media'
@@ -795,6 +798,11 @@ main(int argc, char *argv[])
Cflag = 1;
nomore = 1;
break;
+   case 'M':
+   if (argv[1] == NULL)
+   usage();
+   exit (findmac(argv[1]));
+   break;
default:
usage();
break;
@@ -1255,12 +1263,10 @@ clone_destroy(const char *addr, int para
err(1, "SIOCIFDESTROY");
 }
 
-void
-list_cloners(void)
+struct if_clonereq *
+get_cloners(void)
 {
-   struct if_clonereq ifcr;
-   char *cp, *buf;
-   int idx;
+   static struct if_clonereq ifcr;
 
memset(, 0, sizeof(ifcr));
 
@@ -1269,12 +1275,9 @@ list_cloners(void)
if (ioctl(sock, SIOCIFGCLONERS, ) == -1)
err(1, "SIOCIFGCLONERS for count");
 
-   buf = calloc(ifcr.ifcr_total, IFNAMSIZ);
-   if (buf == NULL)
+   if ((ifcr.ifcr_buffer = calloc(ifcr.ifcr_total, IFNAMSIZ)) == NULL)
err(1, "unable to allocate cloner name buffer");
-
ifcr.ifcr_count = ifcr.ifcr_total;
-   ifcr.ifcr_buffer = buf;
 
if (ioctl(sock, SIOCIFGCLONERS, ) == -1)
err(1, "SIOCIFGCLONERS for names");
@@ -1285,17 +1288,30 @@ list_cloners(void)
if (ifcr.ifcr_count > ifcr.ifcr_total)
ifcr.ifcr_count = ifcr.ifcr_total;
 
-   qsort(buf, ifcr.ifcr_count, IFNAMSIZ,
+   return 
+}
+
+void
+list_cloners(void)
+{
+   struct if_clonereq *ifcr;
+   char *cp, *buf;
+   int idx;
+
+   ifcr = get_cloners();
+   buf = ifcr->ifcr_buffer;
+
+   qsort(buf, ifcr->ifcr_count, IFNAMSIZ,
(int(*)(const void *, const void *))strcmp);
 
-   for (cp = buf, idx = 0; idx < ifcr.ifcr_count; idx++, cp += IFNAMSIZ) {
+   for (cp = buf, idx = 0; idx < ifcr->ifcr_count; idx++, cp += IFNAMSIZ) {
if (idx > 0)
putchar(' ');
printf("%s", cp);
}
 
putchar('\n');
-   free(buf);
+   free(ifcr->ifcr_buffer);
 }
 
 #define RIDADDR 0
@@ -6614,7 +6630,7 @@ __dead void
 usage(void)
 {
fprintf(stderr,
-   "usage: ifconfig [-AaC] [interface] [address_family] "
+   "usage: ifconfig [-AaC] [-M lladdr] [interface] [address_family] "
"[address [dest_address]]\n"
"\t\t[parameters]\n");
exit(1);
@@ -6782,3 +6798,55 @@ setignore(const char *id, int param)
/* just digest the command */
 }
 #endif
+
+int
+findmac(const char *mac)
+{
+   struct ifaddrs *ifap, *ifa;
+   const char *ifnam = NULL;
+   struct if_clonereq *ifcr;
+
+   ifcr = get_cloners();
+
+   if (getifaddrs() != 0)
+   err(1, "getifaddrs");
+
+   for (ifa = ifap; ifa; ifa = ifa->ifa_next) {
+   struct sockaddr_dl *sdl = (struct sockaddr_dl *)ifa->ifa_addr;
+
+   if (sdl != NULL && sdl->sdl_alen &&
+   (sdl->sdl_type == IFT_ETHER || sdl->sdl_type == IFT_CARP)) {
+   if (strcmp(ether_ntoa((struct ether_addr *)LLADDR(sdl)),
+   mac) == 0) {
+   int idx, skip = 0;
+   char *cp;
+   size_t len;
+
+   /* MACs 

Re: lladdr support for netstart/hostname.if

2022-11-24 Thread Theo de Raadt
Theo de Raadt  wrote:

> Vitaliy Makkoveev  wrote:
> 
> > > On 24 Nov 2022, at 19:20, Theo de Raadt  wrote:
> > > 
> > >> I like to exclude pseudo devices. The pseudo device list is immutable,
> > >> so we need to get only once during /etc/netstart.
> > > 
> > > Why do we need to excluse them?
> > > 
> > > The users will learn when to use this, and when not to.
> > > 
> > 
> > So, I can't use hostname.lladdr and usb ethernet cards with vlan?
> 
> Probably not.
> 
> Please answer this question:  Did you try the ifconfig change, and the
> script, in such a scenario?
> 
> Or are you just musing without trying it?

How about this.

vlan's and other potential interfaces with this problem have the IFXF_CLONED
flag set, and I don't see any IFXF_CLONED we would want a hostname.MAC file
to work against.  Unfortunately IFXF_CLONED is not visible in an ioctl.
But the IFXF_CLONED devices are in ifconfig -C output, so I have abstracted
that code into 'get the list' and 'print the list' functions, and reused
the 'get the list' function in findmac() so that I can exclude interfaces
with that root-name.

It is some ugly string mangling code, hope I got it right.  My coffee cup
is still pretty full...


Index: ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.385
diff -u -p -u -r1.385 ifconfig.8
--- ifconfig.8  26 Oct 2022 17:06:31 -  1.385
+++ ifconfig.8  22 Nov 2022 15:04:09 -
@@ -40,6 +40,7 @@
 .Sh SYNOPSIS
 .Nm ifconfig
 .Op Fl AaC
+.Op Fl M Ar lladdr
 .Op Ar interface
 .Op Ar address_family
 .Oo
@@ -88,6 +89,11 @@ This is the default, if no parameters ar
 Print the names of all network pseudo-devices that
 can be created dynamically at runtime using
 .Nm Cm create .
+.It Fl M Ar lladdr
+Scan the interface list for the MAC address
+.Ar lladdr
+and print the name of that interface.
+If the MAC address is found on multiple interfaces, print nothing.
 .It Ar interface
 The
 .Ar interface
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.457
diff -u -p -u -r1.457 ifconfig.c
--- ifconfig.c  26 Oct 2022 17:06:31 -  1.457
+++ ifconfig.c  24 Nov 2022 17:39:40 -
@@ -368,6 +368,9 @@ voidwg_status(int);
 void   setignore(const char *, int);
 #endif
 
+struct if_clonereq *get_cloners(void);
+intfindmac(const char *);
+
 /*
  * Media stuff.  Whenever a media command is first performed, the
  * currently select media is grabbed for this interface.  If `media'
@@ -795,6 +798,11 @@ main(int argc, char *argv[])
Cflag = 1;
nomore = 1;
break;
+   case 'M':
+   if (argv[1] == NULL)
+   usage();
+   exit (findmac(argv[1]));
+   break;
default:
usage();
break;
@@ -1255,12 +1263,10 @@ clone_destroy(const char *addr, int para
err(1, "SIOCIFDESTROY");
 }
 
-void
-list_cloners(void)
+struct if_clonereq *
+get_cloners(void)
 {
-   struct if_clonereq ifcr;
-   char *cp, *buf;
-   int idx;
+   static struct if_clonereq ifcr;
 
memset(, 0, sizeof(ifcr));
 
@@ -1269,12 +1275,9 @@ list_cloners(void)
if (ioctl(sock, SIOCIFGCLONERS, ) == -1)
err(1, "SIOCIFGCLONERS for count");
 
-   buf = calloc(ifcr.ifcr_total, IFNAMSIZ);
-   if (buf == NULL)
+   if ((ifcr.ifcr_buffer = calloc(ifcr.ifcr_total, IFNAMSIZ)) == NULL)
err(1, "unable to allocate cloner name buffer");
-
ifcr.ifcr_count = ifcr.ifcr_total;
-   ifcr.ifcr_buffer = buf;
 
if (ioctl(sock, SIOCIFGCLONERS, ) == -1)
err(1, "SIOCIFGCLONERS for names");
@@ -1285,17 +1288,30 @@ list_cloners(void)
if (ifcr.ifcr_count > ifcr.ifcr_total)
ifcr.ifcr_count = ifcr.ifcr_total;
 
-   qsort(buf, ifcr.ifcr_count, IFNAMSIZ,
+   return 
+}
+
+void
+list_cloners(void)
+{
+   struct if_clonereq *ifcr;
+   char *cp, *buf;
+   int idx;
+
+   ifcr = get_cloners();
+   buf = ifcr->ifcr_buffer;
+
+   qsort(buf, ifcr->ifcr_count, IFNAMSIZ,
(int(*)(const void *, const void *))strcmp);
 
-   for (cp = buf, idx = 0; idx < ifcr.ifcr_count; idx++, cp += IFNAMSIZ) {
+   for (cp = buf, idx = 0; idx < ifcr->ifcr_count; idx++, cp += IFNAMSIZ) {
if (idx > 0)
putchar(' ');
printf("%s", cp);
}
 
putchar('\n');

Re: lladdr support for netstart/hostname.if

2022-11-24 Thread Theo de Raadt
How about if ifconfig -M skips devices that are IFXF_CLONED?
That lookup might not be atomic (I don't think xflags is in the
ifaddrs list), but I don't think atomicity matters.


Then the hostname.MAC will always work on the underlying physical device.


Or is there another way to identify overlay devices?

Does this idea support the script well enough?






Re: lladdr support for netstart/hostname.if

2022-11-24 Thread Theo de Raadt
Vitaliy Makkoveev  wrote:

> > On 24 Nov 2022, at 19:20, Theo de Raadt  wrote:
> > 
> >> I like to exclude pseudo devices. The pseudo device list is immutable,
> >> so we need to get only once during /etc/netstart.
> > 
> > Why do we need to excluse them?
> > 
> > The users will learn when to use this, and when not to.
> > 
> 
> So, I can't use hostname.lladdr and usb ethernet cards with vlan?

Probably not.

Please answer this question:  Did you try the ifconfig change, and the
script, in such a scenario?

Or are you just musing without trying it?




Re: lladdr support for netstart/hostname.if

2022-11-24 Thread Theo de Raadt
> I like to exclude pseudo devices. The pseudo device list is immutable,
> so we need to get only once during /etc/netstart.

Why do we need to excluse them?

The users will learn when to use this, and when not to.



Re: lladdr support for netstart/hostname.if

2022-11-23 Thread Theo de Raadt
Theo de Raadt  wrote:

> > The other, that if both exist,
> > /etc/hostname.$if will override /etc/hostname.$lladdr.
> 
> We do need to decide which one is priority, and document that.
> 
> I am still unsure which is better.  (I've seen a lot of spurious comments
> from folk, so please think about realistic cases, and don't make stuff up..)

And by that I mean: Actually try andrews's diff.  It does it one way (.if
is more important).  Maybe it needs to be the other way.

By using that script, let's find an actual case where it matters and the
other way is better, and then we discuss that.  Maybe it doesn't matter
which way we do it, as long as we document it.



Re: lladdr support for netstart/hostname.if

2022-11-23 Thread Theo de Raadt
> The other, that if both exist,
> /etc/hostname.$if will override /etc/hostname.$lladdr.

We do need to decide which one is priority, and document that.

I am still unsure which is better.  (I've seen a lot of spurious comments
from folk, so please think about realistic cases, and don't make stuff up..)





Re: OpenSSH and -current out-of-tree patched for ~C?

2022-11-23 Thread Theo de Raadt
> I noticed that ~C stopped working in my -current, from last Saturday,
> holding the message "commandline disabled". The rest of the ~-escapes
> work tho, and ~C is no longer present in ~?. Went to check the code,
> currenlty sitting on Git commit e0b284df3ba7772329d85f200545e3bc5a84d54e
> only to find out that there are no instances of that message in it. A
> `make` later, the "classic" behaviour is restored.

There is a patch being tested, which will probably land soon because the
experiment in the community has gone very well.

It took almost 2 weeks for anyone in snapshots to notice, so this proves
how few people are using a set of features.  We have good reason to
collect facts from the community because there are often people who are
outraged, OUTRAGED, when a feature goes away or changes.

> 1. For how long this experiment is going to last? Is there a way to
>disable it? I tried with `permitlocalcommand=yes` with no success.

A new "enablecommandline" configuration option re-enables those particular
features, and the diff later on will show why we feel these features should
be optional.

That configuration option is also the snapshot diff, so you can use it
right away.

> 2. Can I see the patch? And more generally, is there a way to know of
>this experiments other than running into them?

Sometimes you can see the patch on a list.  This one isn't being handled
that way.  There is no firm rule.  We could do it a different way, by
always commiting them first.  And then if they break things backing them
out.  Annoying and painful churn. This is a simply different process of
getting diffs tested.




Re: netstart(8): remove sed

2022-11-23 Thread Theo de Raadt
Klemens Nanni  wrote:

> 449   mount -s /var >/dev/null 2>&1   # cannot be on NFS
> 450   mount -s /var/log >/dev/null 2>&1   # cannot be on NFS
> 451   mount -s /usr >/dev/null 2>&1   # if NFS, fstab must use IP 
> address
> 452   
> 453   start_daemon slaacd dhcpleased resolvd >/dev/null 2>&1
> 454   
> 455   echo 'starting network'
> 456   
> 457   # Set carp interlock by increasing the demotion counter.
> 458   # Prevents carp from preempting until the system is booted.
> 459   ifconfig -g carp carpdemote 128
> 460   
> 461   sh /etc/netstart
> ...
> 617   [[ -f /etc/rc.local ]] && sh /etc/rc.local
> 
> 
> It mounts /usr before running /etc/netstart.

yes that is a fairly recent change.


Shrug



Re: lladdr support for netstart/hostname.if

2022-11-22 Thread Theo de Raadt
Florian Obser  wrote:

> On 2022-11-22 18:06 +10, David Gwynne  wrote:
> >
> > There are a few things to keep in mind if we're going to use lladdrs like 
> > this.
> >
> > vlan interfaces start with their lladdr as 00:00:00:00:00:00 and then 
> > assume the lladdr of the parent interface when that is configured.
> >
> > Clonable devices (eg, egre, vport, aggr, etc) tend to generate random
> > lladdrs when they're created. If you want a consistent lladdr for
> > these you configure that in /etc/hostname.vportX or whatever you're
> > using.
> 
> ifconfig(8) already knows about these (see -C option). Which made me
> think, it might be easier to just ask ifconfig(8).
> 
> $ ifconfig -Q 00:80:41:7b:f3:c3
> vio0
> 
> Would that be helpful?

I'm unsure about the rest of your proposal, where MAC works in place if
the IF argument.  Let's say we do this in ifcconfig.  Do we do it in route?
Or ten other commands?  I think that is the wrong way to go.

But this first idea is valid. We've now seen 3 monster functions trying to
do this task of convering MAC to IF in shell.  Here's code to do it in
ifconfig.

I've done it as -M

It fails if the same MAC is on multiple interfaces.  Go back to using
hostname.if# files, you heathen.

Index: ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.385
diff -u -p -u -r1.385 ifconfig.8
--- ifconfig.8  26 Oct 2022 17:06:31 -  1.385
+++ ifconfig.8  22 Nov 2022 15:04:09 -
@@ -40,6 +40,7 @@
 .Sh SYNOPSIS
 .Nm ifconfig
 .Op Fl AaC
+.Op Fl M Ar lladdr
 .Op Ar interface
 .Op Ar address_family
 .Oo
@@ -88,6 +89,11 @@ This is the default, if no parameters ar
 Print the names of all network pseudo-devices that
 can be created dynamically at runtime using
 .Nm Cm create .
+.It Fl M Ar lladdr
+Scan the interface list for the MAC address
+.Ar lladdr
+and print the name of that interface.
+If the MAC address is found on multiple interfaces, print nothing.
 .It Ar interface
 The
 .Ar interface
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.457
diff -u -p -u -r1.457 ifconfig.c
--- ifconfig.c  26 Oct 2022 17:06:31 -  1.457
+++ ifconfig.c  22 Nov 2022 15:02:20 -
@@ -368,6 +368,8 @@ voidwg_status(int);
 void   setignore(const char *, int);
 #endif
 
+void   findmac(char *);
+
 /*
  * Media stuff.  Whenever a media command is first performed, the
  * currently select media is grabbed for this interface.  If `media'
@@ -759,6 +761,7 @@ main(int argc, char *argv[])
int create = 0;
int Cflag = 0;
int gflag = 0;
+   int Mflag = 0;
int found_rulefile = 0;
int i;
 
@@ -795,6 +798,12 @@ main(int argc, char *argv[])
Cflag = 1;
nomore = 1;
break;
+   case 'M':
+   if (argv[1] == NULL)
+   usage();
+   findmac(argv[1]);
+   exit(1);
+   break;
default:
usage();
break;
@@ -6614,7 +6623,7 @@ __dead void
 usage(void)
 {
fprintf(stderr,
-   "usage: ifconfig [-AaC] [interface] [address_family] "
+   "usage: ifconfig [-AaC] [-M lladdr] [interface] [address_family] "
"[address [dest_address]]\n"
"\t\t[parameters]\n");
exit(1);
@@ -6782,3 +6791,30 @@ setignore(const char *id, int param)
/* just digest the command */
 }
 #endif
+
+void
+findmac(char *mac)
+{
+   struct ifaddrs *ifap, *ifa;
+   char *ifnam = NULL;
+
+   if (getifaddrs() != 0)
+   err(1, "getifaddrs");
+
+   for (ifa = ifap; ifa; ifa = ifa->ifa_next) {
+   struct sockaddr_dl *sdl = (struct sockaddr_dl *)ifa->ifa_addr;
+
+   if (sdl != NULL && sdl->sdl_alen &&
+   (sdl->sdl_type == IFT_ETHER || sdl->sdl_type == IFT_CARP)) {
+   if (strcmp(ether_ntoa((struct ether_addr *)LLADDR(sdl)),
+   mac) == 0) {
+   if (ifnam)  /* same MAC on multiple ifp */
+   exit(1);
+   ifnam = ifa->ifa_name;
+   }
+   }
+   }
+   if (ifnam)
+   printf("%s\n", ifnam);
+   exit(0);
+}



Re: lladdr support for netstart/hostname.if

2022-11-22 Thread Theo de Raadt
Vitaliy Makkoveev  wrote:

> As dlg@ pointed, we have collisions with clonable devices, which inherit
> lladdr or could generate already existing lladdr. We need to handle
> this, for example exclude clobable devices from hostname.lladdr logic.

Noone is proposing deleting the existing support for 'hostname.if'.

hostname.mac will be an addition to identify SOME network interfaces.

Noone is suggesting that users use only hostname.MAC

Specific exclusions could be handled, for instance rejecting 00:00:00:00:00:00
only working on the first or last device with a specific MAC, or rejecting
operation if a MAC exists multiple times --> and thus forcing people back
to using hostname.IF for those cases

But if no such tests were added (to the already bloated) /etc/netstart,
the 'number of people harmed' will probably be zero.





Re: lladdr support for netstart/hostname.if

2022-11-22 Thread Theo de Raadt
Claudio Jeker  wrote:

> On Tue, Nov 22, 2022 at 09:25:08AM +, Stuart Henderson wrote:
> > Need to query (and set $if, which might be used in route commands etc) I 
> > think.
> > 
> 
> I would prefer if people took a step back from configuring interfaces by
> MAC address. It feels like a overly specific hack is introduced for
> a case that should be handled in a different way.
> 
> Not all interfaces have MAC addresses. E.g. umb(4) would need a
> different identifier (most probably the IMEI). Some interfaces inherit
> the MAC address from an other interface (vlan, trunk).
> 
> This requires the use of interface groups to 'rename' these interfaces
> e.g. as 'green' and 'blue' or 'in' and 'out'. So that you can use these
> handles in pf.conf and other commands (rad comes to mind). Not all
> commands work with interface groups. route(8) is such an example but there
> are more commands needing this.


The point of hostname.MAC is you'll be able to

1) set the address
2) set the group

and then

pf.conf will use the group


But that's no different than doing this in a hostname.IF file!

We've been encouraging people to use the group egress, as well as
predefined groups since they were invented!.  In this case, people will
start to use those more, but not because it is a MAC, but because the IF
name is unstable.  They can establish a stable group name, if they know
what interface-instance to assign a group to.

But otherwise, using groups to identify the specific interface position
is completely unrelated to setting the configuration on these interfaces
in the first place.

Claudio, you really should *SHOW* a working configuration using !, if
you believe in it so much.  And do it without a helper shell script,
because where are you going to slap that, into /etc, come on.  What I
came up before had 3 lines of ! command that were 70-90 characters long,
and each line had to to run ifconfig to COMPARE AT THE MAC, and then run
ifconfig to set a configuration; another example did the MAC and then
ran ifconfig multipel times but that single line wrapped the screen
multiple times.

It was a demo of how rough this problem is.  So maybe, show how you do !
commands in such files, so that everyone can see it is ugly as sin and
the wrong thing.



Re: lladdr support for netstart/hostname.if (was: Re: Locking network card configuration)

2022-11-22 Thread Theo de Raadt
Miod Vallat  wrote:

> I'm a bit late to the thread, but whatever its outcome, things have to
> work correctly on older sparc64 hardware, where the default behaviour
> for on-board and Sun-branded expansion card interfaces is to use the
> same MAC address.
> 
> This hints that hostname. should have priority over
> hoshname. for the latter will be ambiguous on these
> systems.

Don't use hostname.MAC in that case.

Noone is proposing removing hostname.IF0 support.



Just like noone is proposing deleting sed because awk can do the job.




Re: lladdr support for netstart/hostname.if

2022-11-22 Thread Theo de Raadt
Vitaliy Makkoveev  wrote:

> On Tue, Nov 22, 2022 at 11:25:55AM +0100, Claudio Jeker wrote:
> > On Tue, Nov 22, 2022 at 09:25:08AM +, Stuart Henderson wrote:
> > > Need to query (and set $if, which might be used in route commands etc) I 
> > > think.
> > > 
> > 
> > I would prefer if people took a step back from configuring interfaces by
> > MAC address. It feels like a overly specific hack is introduced for
> > a case that should be handled in a different way.
> > 
> 
> [skip]
> 
> > 
> > Btw. a lot of this can be done already now by using '!' in hostname.if
> > It wont be pretty but it is also not a common use case.
> 
> Agree.


Come on, that's just some incomplete claim.

I do not think you have tried this.

Try it.  I have actually tried it.  The results were so incredibly
disgusting that I gave up and used another machine.



Re: lladdr support for netstart/hostname.if

2022-11-22 Thread Theo de Raadt
Claudio Jeker  wrote:

> Not all interfaces have MAC addresses. E.g. umb(4) would need a
> different identifier (most probably the IMEI). Some interfaces inherit
> the MAC address from an other interface (vlan, trunk).


Then don't use hostname.MAC for those interfaces.

The other mechanism will remain.


And if that is the case, what is the fuss?


There is no other solution available for interfaces that attach out
of order.  Any attempt to solve this in subr_config.c to provide
stable device names / interface names is going to be a bigger mess.

 



Re: acpimadt: ignore OEM-reserved apic structures

2022-11-21 Thread Theo de Raadt
I agree.

Jonathan Matthew  wrote:

> On a Dell R6515, acpimadt(4) prints this 512 times during boot:
> 
>  acpimadt0: unknown apic structure type 80
> 
> Previous generations of machines had a few of these, and they were easy
> enough to ignore, but 512 is a bit excessive.
> 
> On further inspection, it seems types 0x80 through 0xFF are reserved for
> OEM specific uses, which we're never going to be able to work with, so
> complaining about it seems pointless.  If we encounter a non-OEM type we
> don't know about, we should still report that though.
> 
> ok?
> 
> 
> Index: acpimadt.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpimadt.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 acpimadt.c
> --- acpimadt.c6 Apr 2022 18:59:27 -   1.38
> +++ acpimadt.c22 Nov 2022 03:58:00 -
> @@ -418,8 +418,11 @@ acpimadt_attach(struct device *parent, s
>   break;
>  
>   default:
> - printf("%s: unknown apic structure type %x\n",
> - self->dv_xname, entry->madt_lapic.apic_type);
> + if (entry->madt_lapic.apic_type < ACPI_MADT_OEM_RSVD) {
> + printf("%s: unknown apic structure type %x\n",
> + self->dv_xname,
> + entry->madt_lapic.apic_type);
> + }
>   }
>  
>   addr += entry->madt_lapic.length;
> Index: acpireg.h
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpireg.h,v
> retrieving revision 1.58
> diff -u -p -r1.58 acpireg.h
> --- acpireg.h 9 Jan 2022 05:42:37 -   1.58
> +++ acpireg.h 22 Nov 2022 03:58:01 -
> @@ -352,6 +352,8 @@ struct acpi_madt_x2apic_nmi {
>   uint8_t reserved[3];
>  } __packed;
>  
> +#define ACPI_MADT_OEM_RSVD   128
> +
>  union acpi_madt_entry {
>   struct acpi_madt_lapic  madt_lapic;
>   struct acpi_madt_ioapic madt_ioapic;
> 



Re: systat(1): vmstat: compute rates with elapsed time instead of ticks

2022-11-21 Thread Theo de Raadt
David Gwynne  wrote:

> this is ok by me, obviously.

interesting backhistory of this problem:  it was critical for getting
suspend/resume working on many machines.  it's the only way you knew
the clocks were all correct...



Re: newsyslog alt compression support?

2022-11-18 Thread Theo de Raadt
I completely disagree on this, of course.

We do not make base use ports.  

Todd T. Fries  wrote:

> I love xz compression. It really pinches the bytes outa ascii files, which 
> log files
> are of course made of.
> 
> Is there a direction someone can point me in that would permit the 
> functionality this
> diff provides without hardcoding it and perhaps be acceptable for the tree?
> 
> 
> diff --git a/usr.bin/newsyslog/Makefile b/usr.bin/newsyslog/Makefile
> index 1bb0ce36439..03787a6439b 100644
> --- a/usr.bin/newsyslog/Makefile
> +++ b/usr.bin/newsyslog/Makefile
> @@ -6,4 +6,8 @@ BINOWN=   root
>  
>  MAN= newsyslog.8
>  
> +CFLAGS += -DCOMPRESS='"/usr/local/bin/xz"'
> +CFLAGS += -DCOMPRESS_FORCE='"-f9e"'
> +CFLAGS += -DCOMPRESS_POSTFIX='".xz"'
> +
>  .include 
> diff --git a/usr.bin/newsyslog/newsyslog.c b/usr.bin/newsyslog/newsyslog.c
> index 066167151ca..7d3a959ad90 100644
> --- a/usr.bin/newsyslog/newsyslog.c
> +++ b/usr.bin/newsyslog/newsyslog.c
> @@ -73,8 +73,15 @@
>  
>  #define CONF "/etc/newsyslog.conf"
>  #define PIDFILE "/var/run/syslog.pid"
> +#ifndef COMPRESS
>  #define COMPRESS "/usr/bin/gzip"
> +#endif
> +#ifndef COMPRESS_FORCE
> +#define COMPRESS_FORCE "-f"
> +#endif
> +#ifndef COMPRESS_POSTFIX
>  #define COMPRESS_POSTFIX ".gz"
> +#endif
>  #define STATS_DIR "/var/run"
>  #define SENDMAIL "/usr/sbin/sendmail"
>  
> @@ -925,7 +932,7 @@ compress_log(struct conf_entry *ent)
>   if (pid == -1) {
>   err(1, "fork");
>   } else if (pid == 0) {
> - (void)execl(COMPRESS, base, "-f", tmp, (char *)NULL);
> + (void)execl(COMPRESS, base, COMPRESS_FORCE, tmp, (char *)NULL);
>   warn(COMPRESS);
>   _exit(1);
>   }
> -- 
> Todd Fries .. t...@fries.net
> 
>  
> |\  1.636.410.0632 (voice)
> | Free Daemon Consulting, LLC\  1.405.227.9094 (voice)
> | http://FreeDaemonConsulting.com\  1.866.792.3418 (FAX)
> | PO Box 16169, Oklahoma City, OK 73113-2169 \  sip:freedae...@ekiga.net
> | "..in support of free software solutions." \  sip:4052279...@ekiga.net
>  \
>  
>   37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
> http://todd.fries.net/pgp.txt
> 



Re: nologin: Style fixes

2022-11-18 Thread Theo de Raadt
This does not help anything.


Josiah Frentsos  wrote:

> Index: nologin.c
> ===
> RCS file: /cvs/src/sbin/nologin/nologin.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 nologin.c
> --- nologin.c 12 Jul 2021 15:09:19 -  1.9
> +++ nologin.c 18 Nov 2022 16:59:31 -
> @@ -25,7 +25,6 @@
>   * SUCH DAMAGE.
>   */
>  
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -38,7 +37,6 @@
>  
>  #define DEFAULT_MESG "This account is currently not available.\n"
>  
> -/*ARGSUSED*/
>  int
>  main(int argc, char *argv[])
>  {
> @@ -51,15 +49,15 @@ main(int argc, char *argv[])
>   if (pledge("stdio rpath", NULL) == -1)
>   err(1, "pledge");
>  
> - nfd = open(_PATH_NOLOGIN_TXT, O_RDONLY);
> - if (nfd == -1) {
> + if ((nfd = open(_PATH_NOLOGIN_TXT, O_RDONLY)) == -1) {
>   write(STDOUT_FILENO, DEFAULT_MESG, strlen(DEFAULT_MESG));
> - exit (1);
> + exit(1);
>   }
>  
>   while ((nrd = read(nfd, nbuf, sizeof(nbuf))) != -1 && nrd != 0)
>   write(STDOUT_FILENO, nbuf, nrd);
> - close (nfd);
>  
> - exit (1);
> + close(nfd);
> +
> + exit(1);
>  }
> 



More on mimmutable

2022-11-17 Thread Theo de Raadt
[LONG]

I am getting close to having the big final step of mimmutable in the tree.
Here's a refresher on the how it works, what's already done, and the next
bit to land.

DESCRIPTION
 The mimmutable() system call changes currently mapped pages in the region
 to be marked immutable, which means their protection or mapping may not
 be changed in the future.  mmap(2), mprotect(2), and munmap(2) to pages
 marked immutable will return with error EPERM.

That's the system call.  In reality, almost no programs call it.

Let me start by explaining a process's address space, starting with the simplest
programs and then heading into more complicated cases.

A process runtime has a
  - stack (rwS permissions, S being the annotation used at system call entry
to ensure the "sp" register points to stack, and thus prevent a class
of ROP pivot methods),
  - a stack-guard (for growing the stack in case rlimits are changed, this
is is permission NONE)
  - a signal trampoline page, randomly placed, which will perform sigreturn(2),
(permission rwe, e being the annotation used at system call entry to ensure
the "pc" register points at a region allowed to system calls, thus 
preventing
attackers from uploading direct system call instruction code)

Those objects are automatically marked immutable by the kernel.

On to static executables.  The kernel loads a static ELF binary into
memory as a text segment (rx permission), followed by a data segment (rw
permission), a bss (zero'd data, rw permission), and a rodata segment
(ro permission).  The order of these varies per architecture.  There is
an overlay of this called the "GNU_RELRO", which is pretty uhm special.
I've created a new overlay called "OPENBSD_MUTABLE", which is
page-aligned and must not be made immutable.  As it happens, these two
special regions are the only part of the image load that cannot be marked
immutable, so the kernel proceeds to mark everything else immutable.

When that static program starts running, it will run the crt0 ("c run time")
startup code, which can make some small changes in the GNU_RELRO region,
and them mark it immutable.

So this static executable is completely immutable, except for the
OPENBSD_MUTABLE region.  This annotation is used in one place now, deep
inside libc's malloc(3) code, where a piece of code flips a data structure
between readonly and read-write as a security measure.  That does not become
immutable.  It happens to be an page.

There is another ugly old wart called "text relocations", and I won't
get into it except to say the kernel recognizes such binaries, and skips
some immutabilities, but of course crt0 finishes the job. 

I want to speak a bit about the mechanism.  Inside the kernel,
immutability is applied to all the regions.  And then the exceptions are
marked mutable.  The kernel is allowed to reverse setting immutability,
but userland cannot.  This will come up later.

Now let's talk about dynamic executables.  The same applies as above for
the main program, but then the kernel also loads another object into memory:
/usr/libexec/ld.so -- the shared library linker.  And instead of starting
to run the main program, execution starts in the shared library linker.

The shared library linker ELF image contains similar objects.  There is a
GNU_RELRO, which the kernel cannot mark immutable.  There is no OPENBSD_MUTABLE
because we don't request creation of one.  There is a special "boot.text"
section that the shared library linker unmaps upon startup, as a security
measure, and the kernel ignores that region.  All the other regions of
ld.so are marked immutable by the kernel automatically.

Now ld.so starts to execute, and the first job it does is to fix it's
own relro section, handle text relocations in the dynamic binary, repair
some permissions, and then mark itself and the main program immutable.
Completely immutable, except for the OPENBSD_MUTABLE page in malloc(2).

I was really surprised we got to this point without blowing up the ports
tree in a major way.  Some of these warts were found along the way and
changed the direction a little.  And I don't want to talk about sigaltstack
right now.

ld.so is now responsible for loading the shared libraries required by the
program.  Shared libraries have the same pieces as regular programs, so
they are loaded into memory, but here we hit a problem.  In the kernel we
could simplistically mark all the regions as immutable, and then reverse
it for the special cases.  Userland code cannot do that.  So we have to
keep track of the sections we want to be immutable, as well as the regions
that are immutable, and then subtract the differences, and apply the
immutables very late in the shared library loading process.  I call this
code the clipping engine, and I had a lot of bugs in it.

There is another way shared libraries are loaded:  via the dlopen()
call later at runtime.  With the flag RTLD_NODELETE, libraries can
be marked immutable.  

Re: rpki-client: add 'shortlist' functionality

2022-11-17 Thread Theo de Raadt
Job Snijders  wrote:

> rpki-client currently is using 'only' 18 out of the 66 ([a-zA-Z0-9).
> I am not very concerned in that regard. :-)


I have to disagree strongly -- Software bloat is dangerous.






Re: Patch for getopt_long.c

2022-11-15 Thread Theo de Raadt
Mathias Bavay  wrote:

> Hi,
> 
> Please find here attached a patch with minor touch up on 
> src/lib/libc/stdlib/getopt_long.c :
> 
>     * Added an SPDX license identifier;

No.



Re: reorder_kernel: suport ro /usr like library_aslr does

2022-11-14 Thread Theo de Raadt
Klemens Nanni  wrote:

> Reading /etc/rc I was under the impression that read-only /usr is indeed
> a scenario we support, since reorder_libs() already does what I propose,
> only in a more complicated way:
> 
>   revision 1.481
>   date: 2016/05/26 14:59:48;  author: rpe;  state: Exp;  lines: +32 -7;
>   - rename rebuildlibs() to reorder_libs()
>   - move the info message inside the function
>   - skip reordering if /usr/lib is on a nfs mounted filesystem
>   - temporarily remount rw if /usr/lib is on a ro ffs file-system
> 
>   OK deraadt
> 
> Did OpenBSD's stance on read-only /usr change between then and now?

The OpenBSD stance never changed.

If the configuration isn't created by the install script, you are on
your own.  Maybe one developer put some words in about ffs, but I am sure
the idea was to protect NFS diskless which cannot be mounted rw.

I do not see the point behind diff after diff trying to add scripting
for bizzare configurations that basically none of our users configure.
Those admins are fully aware that when they make weird configuration changes,
they are on their own, and they have to maintain their own diffs.

I do not agree with this continual pushiness you have to find weird
special cases and propose scripting changes to deal with it.

OpenBSD's prime principle is SIMPLICITY, even when it means there are
limited operations for operation, and you are going way out of bounds.

Take a step back.



Re: reorder_kernel: suport ro /usr like library_aslr does

2022-11-14 Thread Theo de Raadt
Readonly /usr is not a supported or recomended configuration.

This is adding a lot of scripting that we don't everyone to run.

I disagree strongly with this direction of OpenBSD having undocumented
(undocumentable?) little behaviours that allow root to configure their
machine in novel non-default ways and it will still work because there
piles of of trashy shell scripts which cope with the weird situations,
which under 1% of users will use.

I disagree with this flexiblity being a strength, I think it is very
fragile when we encourage users to do bizzare things to their machines
which they (also) will not include in future bug reports.

Klemens Nanni  wrote:

> On Tue, Nov 08, 2022 at 11:10:19AM +, Klemens Nanni wrote:
> > More read-only filesystems mean less fsck during boot after crashes.
> > Especially on crappy machines like the Pinebook Poop, I keep /usr
> > read-only and run with this diff so I still get a relinked kernel.
> > 
> > rc's reorder_libs() already does the same remount dance, but for
> > multiple directories/filesystems.
> > 
> > My diff works as expected with read-write and read-only /usr as well as
> > interrupting /usr/libexec/reorder_kernel runs with ^C, i.e. a failed run
> > will correctly mount /usr ro again if it was ro before the run.
> > 
> > Feedback? OK?
> 
> Ping.
> 
> Index: libexec/reorder_kernel/reorder_kernel.sh
> ===
> RCS file: /cvs/src/libexec/reorder_kernel/reorder_kernel.sh,v
> retrieving revision 1.13
> diff -u -p -r1.13 reorder_kernel.sh
> --- libexec/reorder_kernel/reorder_kernel.sh  7 Nov 2022 15:55:56 -   
> 1.13
> +++ libexec/reorder_kernel/reorder_kernel.sh  14 Nov 2022 19:33:25 -
> @@ -27,13 +27,32 @@ LOGFILE=$KERNEL_DIR/$KERNEL/relink.log
>  PROGNAME=${0##*/}
>  SHA256=/var/db/kernel.SHA256
>  
> -# Silently skip if on a NFS mounted filesystem.
> -df -t nonfs $KERNEL_DIR >/dev/null 2>&1
> +# Silently skip if on NFS, otherwise remount the filesystem read-write.
> +DEV=$(df -t ffs $KERNEL_DIR 2>/dev/null | awk 'NR == 2 { print $1 }')
> +MP=$(mount | grep ^$DEV)
> +RO=false
> +if [[ $MP == *read-only* ]]; then
> + MP=${MP%% *}
> + mount -u -w $MP
> + RO=true
> +fi
> +
> +restore_mount() {
> + if $RO; then
> + # Close the logfile to unbusy $MP by switching back to console.
> + exec 1>/dev/console
> + exec 2>&1
> + mount -u -r $MP
> + fi
> +}
>  
>  # Install trap handlers to inform about success or failure via syslog.
>  ERRMSG='failed'
> -trap 'trap - EXIT; logger -st $PROGNAME "$ERRMSG" >/dev/console 2>&1' ERR
> -trap 'logger -t $PROGNAME "kernel relinking done"' EXIT
> +trap 'trap - EXIT
> + logger -st $PROGNAME "$ERRMSG" 2>/dev/console
> + restore_mount' ERR
> +trap 'logger -t $PROGNAME "kernel relinking done"
> + restore_mount' EXIT
>  
>  # Create kernel compile dir and redirect stdout/stderr to a logfile.
>  mkdir -m 700 -p $KERNEL_DIR/$KERNEL
> 



Re: xenodm: save ~/.xesssion to ~/.xsession.old

2022-11-14 Thread Theo de Raadt
Klemens Nanni  wrote:

> On Mon, Nov 14, 2022 at 10:33:44AM -0700, Theo de Raadt wrote:
> > Stuart Henderson  wrote:
> > 
> > > > Index: app/xenodm//config/Xsession.in
> > > > ===
> > > > RCS file: /cvs/xenocara/app/xenodm/config/Xsession.in,v
> > > > retrieving revision 1.2
> > > > diff -u -p -r1.2 Xsession.in
> > > > --- app/xenodm//config/Xsession.in  1 Jul 2022 20:42:06 -   
> > > > 1.2
> > > > +++ app/xenodm//config/Xsession.in  14 Nov 2022 16:47:03 -
> > > > @@ -7,6 +7,7 @@ exec_prefix="@exec_prefix@"
> > > >  # redirect errors to a file in user's home directory if we can
> > > >  
> > > >  errfile="$HOME/.xsession-errors"
> > > > +cp -f "$errfile" "$errfile.old" 2> /dev/null
> > > 
> > > Those files can get pretty big. mv is probably a better idea than cp.
> > 
> > And consider the target being a symbolic link, both file and directory
> 
> `mv -f 2>/dev/null' should be good enough for all of this, no?
> It's a silent one-shot:  if it works, great.  If not, no .old backup and
> the file gets truncated as usual.

ln -s /tmp ~/.xsession-errors.old

Your plan is half baked.






Re: export {b,r}ootduid as sysctl, installer/sysupgrade improvements

2022-11-14 Thread Theo de Raadt
Mark Kettenis  wrote:

> > From: "Theo de Raadt" 
> > Date: Mon, 14 Nov 2022 10:02:40 -0700
> > 
> > An OpenBSD machine only has one OpenBSD install.
> 
> I have to disagree here.  Not everyone has a pile of test machines
> lying around.  

Are you going to work on the install script?

And then, after that, on the feature requests for sysupgrade?

> Well, that is the real question: will this increase complexity?

It will increase complexity.

> We
> currently have code that makes what I'd describe as an "educated
> guess" at what is the OpenBSD root disk of a machine.  If we can
> replace that with something that finds the disk based on its DUID,
> that would make things more robust and might even decrease complexity
> in the installer.

I don't believe either of you.

I believe that is_rootdisk() will be replaced with 30 lines of kernel
code, 10 lines in distrib/special/sysctl/sysctl.c, and 5 lines of
shell script ..

AND AFTER THAT IS DONE, a bunch of extensions will be proposed for
various other system install / update features, which will then increase
complexity.



And I claim that will happen because this is not proposing 1 new sysctl,
it is proposing 2 of them, without explaining why there needs to be 2.
I think the explanation for that is "undisclosed goals".







Re: xenodm: save ~/.xesssion to ~/.xsession.old

2022-11-14 Thread Theo de Raadt
Stuart Henderson  wrote:

> > Index: app/xenodm//config/Xsession.in
> > ===
> > RCS file: /cvs/xenocara/app/xenodm/config/Xsession.in,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 Xsession.in
> > --- app/xenodm//config/Xsession.in  1 Jul 2022 20:42:06 -   1.2
> > +++ app/xenodm//config/Xsession.in  14 Nov 2022 16:47:03 -
> > @@ -7,6 +7,7 @@ exec_prefix="@exec_prefix@"
> >  # redirect errors to a file in user's home directory if we can
> >  
> >  errfile="$HOME/.xsession-errors"
> > +cp -f "$errfile" "$errfile.old" 2> /dev/null
> 
> Those files can get pretty big. mv is probably a better idea than cp.

And consider the target being a symbolic link, both file and directory




Re: export {b,r}ootduid as sysctl, installer/sysupgrade improvements

2022-11-14 Thread Theo de Raadt
An OpenBSD machine only has one OpenBSD install.

As soon as we leave that model, and allow other setup models, perhaps you
think there will be two or three potential configurations that people setup.

I don't think so, I think it will keep being extended by people who do
more and more scewed up bizzare configurations, all of which (obviously, to
you) will need to be supported, and everything gets more complicated.

I think we should say "STOP". Now.  And not start down that roadmap.


How many Windows configurations can I put onto a PC?
Can I put two Andriod configurations onto my phone?


You built something for a testlab.  Your conclusion is that it should
work for everyone.  I simply cannot come to the same conclusion,
because it requires complexity, but instead I think we should embrace
simplicity even if it limits choice.

Klemens Nanni  wrote:

> On Mon, Nov 14, 2022 at 07:49:11AM -0700, Theo de Raadt wrote:
> > Klemens Nanni  wrote:
> > 
> > > This is because the installer always considers the first root disk it
> > > finds as the one to upgrade, which is certainly not what I intend or
> > > expect when booting/upgrading the softraid installation on sd1-3.
> > 
> > What does
> > 
> >  first root disk
> > 
> > Mean?
> 
> One machine with two phsyical disks, say one NVMe and regular SSD.
> Both disks contain a standalone OpenBSD installation.
> 
> I consider each of them a root disk.
> 
> > 
> > There is only one root disk.  The root disk is the one that actually 
> > contains
> > the / that is mounted.
> > 
> > It is this one:
> > 
> > root on sd0a (fb786f6b01042b30.a) swap on sd0b dump on sd0b
> > 
> > You cannot change this.  If you use the bootloader to tell the kernel do
> > do something else, then I argue that sysupgrade and the installer should
> > punish you unless you *manually tell it that every time*
> 
> I don't set anything in /etc/boot.conf or the boot> prompt.
> 
> I select the disk to boot from in the UEFI boot manager.
> 
> > 
> > The install script knows what the root filesystem is using very simple
> > heuristics, but by creating two new sysctl, I am afraid you will enrich
> > this ability to support bizzare configurations that did not work, and
> > I argue *should never work*.
> > 
> > > It is probably not that common to have multiple installations/root disks
> > > in one machine, but it isn't "weird" to me, either.
> > 
> > What?  It is not weird
> > 
> > I think this is unsupported bullshit.
> > 
> > Why do we need the install script to support this configuration you
> > created?  Why do we need to encourage other people to have such
> > configurations?  When they create such a configuration, and find the
> > tooling can support it, won't they go and do even stranger things, then
> > find the tooling doesn't support that even-stranger setup, and then
> > you'll come back adding support for increasingly strange setups, and
> > eventually we are going to end up with a large userbase *not using* a
> > single root filesystem?
> > 
> > > Overwriting the wrong system during an upgrade because the installer
> > > makes too big of an assumption about the first disk is weird to me.
> > > 
> > > 
> > > I can post console logs later showing how the installer picks the wrong
> > > disk, if you want.
> > 
> > There is only one possible root filesystem.
> > 
> > If you created multiple root filesystems, you have created a mess and
> > why is it wrong for me to argue you need to experience pain for the
> > decisions that led you there?
> > 
> > I do not think you are being honest about the reason for these extensions.
> > 
> 
> I'm pretty honest, but apparently not precise enough.
> 
> Now that all the softraid/installboot diffs landed and the dust has
> settled, let me iterate over and test my setup again to make sure I'm
> not tripping over my own mistakes.
> 
> Then I can come back with a clear update or reproducer.
> 



Re: export {b,r}ootduid as sysctl, installer/sysupgrade improvements

2022-11-14 Thread Theo de Raadt
> sd1-3 are softraid chunks hosting a separate installation for testing.
> Booting into this

I think this is where you went wrong.  Expecting this to work is going
to result in 20-40 diffs bloating all the media for a configuration which
less than than 1 in a thousand people need.





Re: export {b,r}ootduid as sysctl, installer/sysupgrade improvements

2022-11-14 Thread Theo de Raadt
Klemens Nanni  wrote:

> This is because the installer always considers the first root disk it
> finds as the one to upgrade, which is certainly not what I intend or
> expect when booting/upgrading the softraid installation on sd1-3.

What does

 first root disk

Mean?

There is only one root disk.  The root disk is the one that actually contains
the / that is mounted.

It is this one:

root on sd0a (fb786f6b01042b30.a) swap on sd0b dump on sd0b

You cannot change this.  If you use the bootloader to tell the kernel do
do something else, then I argue that sysupgrade and the installer should
punish you unless you *manually tell it that every time*

The install script knows what the root filesystem is using very simple
heuristics, but by creating two new sysctl, I am afraid you will enrich
this ability to support bizzare configurations that did not work, and
I argue *should never work*.

> It is probably not that common to have multiple installations/root disks
> in one machine, but it isn't "weird" to me, either.

What?  It is not weird

I think this is unsupported bullshit.

Why do we need the install script to support this configuration you
created?  Why do we need to encourage other people to have such
configurations?  When they create such a configuration, and find the
tooling can support it, won't they go and do even stranger things, then
find the tooling doesn't support that even-stranger setup, and then
you'll come back adding support for increasingly strange setups, and
eventually we are going to end up with a large userbase *not using* a
single root filesystem?

> Overwriting the wrong system during an upgrade because the installer
> makes too big of an assumption about the first disk is weird to me.
> 
> 
> I can post console logs later showing how the installer picks the wrong
> disk, if you want.

There is only one possible root filesystem.

If you created multiple root filesystems, you have created a mess and
why is it wrong for me to argue you need to experience pain for the
decisions that led you there?

I do not think you are being honest about the reason for these extensions.



Re: export {b,r}ootduid as sysctl, installer/sysupgrade improvements

2022-11-14 Thread Theo de Raadt
Klemens Nanni  wrote:

> I'd like to get on with this, can also add sysctl.2 bits to document
> those before sending diffs using them.

I want you to prove the use case first.

> Mark asked whether CTLTYPE_QUAD would be more suited, but I still don't
> understand how that is supposed to work and there was no answer in this
> thread's other mail.

All the consumers of this use strings.  It is a string in the disklabel
output, a string in the disklabel command, and they are managed as
strings everywhere else.  Outside the installer, the only place it is
handled is as a partition name, which is either DUID.a or sd0a, either
on the commandline or in fstab.  Always hanled as a string, because the
shell handles numbers poorly, let alone hex numbers with extra stuff
afterwards.



Re: export {b,r}ootduid as sysctl, installer/sysupgrade improvements

2022-11-14 Thread Theo de Raadt
Mark Kettenis  wrote:

> > > The installer considers a disk a root disk if 'a' is FFS and contains
> > > expected files.
> > > 
> > > Furthermore, unattended upgrades will always install to the first root
> > > disk that is found.
> > > 
> > > This works fine on machines with only one root disk, but it quickly
> > > behaves unexpectedly when having multiple disks/installations in one
> > > machine.
> > > 
> > > I run such machines, esp. since fiddling with softraid and installboot.


I don't understand the situation.

I suspect you are intentionally creating very weird setups, and now you
want install script to help people create such weird setups.  Then it
becomes an additional weird thing we must anticipate in the future.

Please show a valid reason why boot are different.  It is very hard to
reason about this when the rest of your email shows an example where
they are the same.

> > > The installer/sysupgrade experience can definitely be improved here, but
> > > that takes some consideration.
> > > 
> > > One requirement, imho, is knowing
> > > 1. which disk we booted from, i.e.
> > >from which disk the kernel (/bsd.rd or /bsd.upgrade) was loaded
> > > 2. which disk the root filesystem is on, i.e.
> > >likely the same disk holding /home where sysupgrade put the sets

Prove it.



Re: route(8) example for "out of prefix" default gateway

2022-11-09 Thread Theo de Raadt
Claudio Jeker  wrote:

> On Wed, Nov 09, 2022 at 07:37:50AM +, Stuart Henderson wrote:
> > Seems some hosting providers have annoying "out of prefix"
> > default gateways whuch are painful to configure
> > (https://marc.info/?t=16678224225=1=2), should
> > we give a pointer in route(8)?
> > 
> > Index: route.8
> > ===
> > RCS file: /cvs/src/sbin/route/route.8,v
> > retrieving revision 1.104
> > diff -u -p -r1.104 route.8
> > --- route.8 29 Jul 2022 18:28:32 -  1.104
> > +++ route.8 9 Nov 2022 07:29:59 -
> > @@ -596,6 +596,14 @@ Delete the
> >  route to the 192.168.5.0/24 network:
> >  .Pp
> >  .Dl # route delete -inet 192.168.5.0/24
> > +.Pp
> > +Add a static
> > +.Xr inet6 4
> > +route to a host which is on the vio0 interface that is outside the prefix
> > +configured on the interface, and use that host as a default gateway:
> > +.Pp
> > +.Dl # route add -inet6 2001:db8:efef::1 -cloning -link -iface vio0
> > +.Dl # route add -inet6 default 2001:db8:efef::1
> >  .Sh DIAGNOSTICS
> >  .Bl -diag
> >  .It "%s: gateway %s flags %x"
> > 
> 
> I'm fine with this for now. It would be great if we could make ifconfig do
> the right thing but that is more complex. Setting a destination (like on
> point-to-point interfaces) is shared with the broadcast address so
> IFF_BROADCAST handling needs to be adjusted.

Actually I prefer the route way, because it requires people to be explicit
in these circumstances.  If it is automatic, there is more chance of creating
non-working configurations no?



Re: rc(8): reorder_libs(): print names of relinked libraries

2022-11-08 Thread Theo de Raadt
Stuart Henderson  wrote:

> > But I am not sure people need to see this detail.  It just takes a bit
> > of time.  How does knowing what steps are being taken help...
> 
> Sometimes it's a bit of time, sometimes it's a _lot_ of time until
> people get a new computer or raid battery or something and it's less
> annoying if you can see _some_ progress.

Sigh.

Do we need a spinny thingy?



Re: rc(8): reorder_libs(): print names of relinked libraries

2022-11-08 Thread Theo de Raadt
Klemens Nanni  wrote:

> On Tue, Nov 08, 2022 at 10:23:23AM +, Stuart Henderson wrote:
> > On 2022/11/07 23:54, Theo de Raadt wrote:
> > > Klemens Nanni  wrote:
> > > 
> > > > > I know this makes rc(8) a bit noisier but it really does improve my
> > > > > (for want of a better term) "user experience" as I wait for my machine
> > > > > to boot.
> > > > 
> > > > I like this and it doesn't add more **lines** to the boot log, but maybe
> > > > print library names without versions to reduces noise?
> > > 
> > > Only if it is the short names.
> > 
> > No need for the .so really either. ld.so libc libcrypto is enough.
> 
> Yes, but that needs a little more shell tweaking as ${_lib%%.*} will
> turn "ld.so" into "ld", so I suggested a simple middle ground before
> blowing up the diff...

Sorry, but I insist on the shorters cute names.



Re: rc(8): reorder_libs(): print names of relinked libraries

2022-11-07 Thread Theo de Raadt
Klemens Nanni  wrote:

> > I know this makes rc(8) a bit noisier but it really does improve my
> > (for want of a better term) "user experience" as I wait for my machine
> > to boot.
> 
> I like this and it doesn't add more **lines** to the boot log, but maybe
> print library names without versions to reduces noise?

Only if it is the short names.

But I am not sure people need to see this detail.  It just takes a bit
of time.  How does knowing what steps are being taken help...



Re: sysupgrade: apply bsd.re-config(5) to /bsd.upgrade

2022-11-07 Thread Theo de Raadt
> I'm a bit torn on this one since it is pretty niche, but since this
> actually helps you, I am ok with the diff.

I worry about unexpected results, which might even be dangerous.

The bsd.re-config file is written by people to perform against a GENERIC
or GENERIC.MP kernel.

It is not written to edit a RAMDISK* kernel

I don't think we know what it means to apply this to such a different kernel,
and automatically...




Re: ssh-keygen(1): by default generate ed25519 key (instead of rsa)

2022-11-06 Thread Theo de Raadt
Should we have a small window where the key is generated, but not yet
the default?

Or should we use the snapshot period to create some pain, and see which
clouds react (we will allow them to self-publish their hate for the choices
of their customers), but then when release time comes, we can make a subtly
more conservative decision?



Re: Questions about the code review process in OpenBSD

2022-11-06 Thread Theo de Raadt
i...@tutanota.com wrote:

> Nov 6, 2022, 21:14 by dera...@openbsd.org:
> 
> > I suspect your company forces children to make shoes, and your bosses
> > kick dogs and cats.  Can you provide evidence that is not true?
> >
> >   that is what your messages come off like.
> >
> > Grow up.
> >
> I am sorry that you read it this way, but that was NOT my intent, I was
> seriously just asking. I am not native English, so maybe in my expression
> something gets twisted so it just gets read like that.
> 
> If you truly read it like that, I cannot fathom why you would not simply
> ignore it, but waste your time on - from your perspective - such a
> stupid email. Answering by saying "dickhead" and "grow up", I don't even
> know what to say. Maybe you're the one who needs to grow up?
> 

I'm sorry I cannot communicate any longer with you because you won't give
assurances that your company doesn't have really terrible practices.

Or, maybe you are just speaking dishonestly.



Re: Questions about the code review process in OpenBSD

2022-11-06 Thread Theo de Raadt
i...@tutanota.com wrote:

> Nov 6, 2022, 21:00 by dera...@openbsd.org:
> 
> > Everything is provided with no warranty and you cannot insist on us
> > telling you what our processes are.
> >
> > You are out of line.
> >
> I am not insisting on anything, I am simply asking.
> 
>  We have supported the project for many years and even know we very
> well know about the "no warranty" policy, I fail to see how asking a very
> specific question about how code commits are handled is "out of line".
> 


I suspect your company forces children to make shoes, and your bosses
kick dogs and cats.  Can you provide evidence that is not true?


 that is what your messages come off like.

Grow up.



Re: Questions about the code review process in OpenBSD

2022-11-06 Thread Theo de Raadt
i...@tutanota.com wrote:

> Nov 6, 2022, 20:16 by dera...@openbsd.org:
> 
> > Mr iio7,
> >
> > Your persistant questions as to our processes are pointless.
> >
> > You are asking these questions in this way to interfere.
> >
> > That is a dickhead move.
> >
> > Everyone can see it.
> >
> Well, then everyone needs glasses because I am NOT asking to
> interfere, I am asking in order to understand.
> 
> I am the sysadmin at our company responsible for the OpenBSD
> based projects. When I read about the problems at FreeBSD, after
> which I wrote to their list, I was sure that the process was different
> in OpenBSD, to which several users on FreeBSD replied, that
> OpenBSD doesn't do code review on each commit, yada yada.
> 
> I wanted to make sure that I did carry any misinformation.
> 
> I am sorry if my level of understanding and asking questions doesn't
>  meet your requirements to be taken serious such that you feel they
> deserve to be called dickhead moves.


Everything is provided with no warranty and you cannot insist on us
telling you what our processes are.

You are out of line.



Re: installer: MD post-install instructions on upgrades?

2022-11-06 Thread Theo de Raadt
Yeah sure why not.

Klemens Nanni  wrote:

> Upgrades are noiser on macppc (and loongson and octeon) than on other
> architectures because boot firmware changes and/or tips to complete an
> OpenBSD installation are always printed, even though they are not needed
> after an upgrade:
> 
>   INSTALL.macppc describes how to configure Open Firmware to boot 
> OpenBSD. The
>   command to boot OpenBSD will be something like 'boot hd:,ofwboot /bsd'.
> 
> Shall we limit those one-shot bits relevant to new installations to
> actual installations?
> 
> I don't see how those are useful after an upgrade of a working OpenBSD
> install.
> 
> Index: miniroot/install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.1213
> diff -u -p -r1.1213 install.sub
> --- miniroot/install.sub  19 Oct 2022 08:24:14 -  1.1213
> +++ miniroot/install.sub  5 Nov 2022 21:49:38 -
> @@ -2951,13 +2951,16 @@ __EOT
>  CONGRATULATIONS! Your OpenBSD $MODE has been successfully completed!
>  
>  __EOT
> - [[ $MODE == install ]] && cat <<__EOT
> + if [[ $MODE == install ]]; then
> + cat <<'__EOT'
>  When you login to your new system the first time, please read your mail
>  using the 'mail' command.
>  
>  __EOT
>  
> - md_congrats
> + md_congrats
> + fi
> +
>   $AI && >/tmp/ai/ai.done
>  }
>  
> 



Re: Questions about the code review process in OpenBSD

2022-11-06 Thread Theo de Raadt
i...@tutanota.com wrote:

> >>> That is not your responsibility. It is mine.
> >>>
> >>> You can stop asking.
> 
> I replied of list (by mistake by pressing reply rather than reply to all):
> 
> >> Why do you keep wasting your precious time with these completely
> >> useless comments?
> 
> To which Theo answered back:
> 
> > Hi Mr. Dickhead.
> >
> > Don't be a dickhead.
> >
> > Thanks.
> 
> Theo, obviously you don't give rats ass, which is very clear from the
> history of the mailing list, but you are actively driving people away from
>  OpenBSD by your childish  behavior.
> 
> Some day you'll be standing next to the wrong person when you call him
> a dickhead.

Mr iio7,

Your persistant questions as to our processes are pointless.

You are asking these questions in this way to interfere.

That is a dickhead move.

Everyone can see it.



Re: resolvd: write nameservers in expected order

2022-11-05 Thread Theo de Raadt
+   if (mergesort(learning, ASR_MAXNS, sizeof(learning[0]), cmp) == -1)
+   lerr(1, "mergesort");

So at runtime if mergesort() fails to allocate memory, the program will
simply exit?








Re: Questions about the code review process in OpenBSD

2022-11-05 Thread Theo de Raadt
That is not your responsibility.  It is mine.

You can stop asking.

>I am trying to understand how the code review process is conducted in
>OpenBSD. I can see all the OK's in the commit log, but not every commit
>has the OK.
>
>On FreeBSD there where a serious problem with a developer who was hired
>to by Netgear to create a WireGuard VPN implementation as a kernel-mode
>solution and this was then contributed to FreeBSD. It was removed in
>the last minute.
>
>https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/
>
>Is it a condition for code to go into the OpenBSD source tree (not
>talking about ports) that at least one other developer has reviewed the
>code?
>
>Is there a process in place to guarantee this?
>
>If it's not a condition and anyone with commit access can commit
>freely, how do you prevent something like a committer going "rogue" and
>inserts a backdoor or creates another serious problem?
>
>Cheers.
>
>



Re: resolvd: write nameservers in expected order

2022-11-03 Thread Theo de Raadt
If you do not sort the, you cannot remove duplicates.



Re: usbdevs(8) getopt tweak

2022-10-27 Thread Theo de Raadt
David Gwynne  wrote:

> usbdevs has "?" in the optstring is passes to getopt, but doesn't handle
> it specially. this is unnecessarily different to everything else in the
> tree, so i want to remove it. ok?
> 
> Index: usbdevs.c
> ===
> RCS file: /cvs/src/usr.sbin/usbdevs/usbdevs.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 usbdevs.c
> --- usbdevs.c 12 Jul 2021 15:09:22 -  1.34
> +++ usbdevs.c 28 Oct 2022 01:59:52 -
> @@ -239,7 +239,7 @@ main(int argc, char **argv)
>   uint8_t addr = 0;
>   const char *errstr;
>  
> - while ((ch = getopt(argc, argv, "a:d:v?")) != -1) {
> + while ((ch = getopt(argc, argv, "a:d:v")) != -1) {
>   switch (ch) {
>   case 'a':
>   addr = strtonum(optarg, 1, USB_MAX_DEVICES-1, );
> 

I thought we killed all of those two decades ago.



Re: sparc64: constify ddb instruction table

2022-10-21 Thread Theo de Raadt
Todd C. Miller  wrote:

> On Fri, 21 Oct 2022 22:55:57 +0200, Mark Kettenis wrote:
> 
> > Be careful.  By moving more stuff into .rodata, you may overflow the
> > .text/.rodata block.  Make sure you build and test the kernels and
> > also test an actual bsd.rd.
> 
> Do we know exactly what these limits are?  If so, couldn't we test
> for them in the kernel Makefile after the kernel is linked?

Sure, and the poeple making MI kernel changes will have no idea they just
broke sparc64 kernels for everyone else.

Eventually the kernel TLB management will need to change.



Re: sparc64: constify ddb instruction table

2022-10-21 Thread Theo de Raadt
Mark Kettenis  wrote:

> Be careful.  By moving more stuff into .rodata, you may overflow the
> .text/.rodata block.  Make sure you build and test the kernels and
> also test an actual bsd.rd.

Unless it fits, just barely, and then a commit three weeks later breaks it.
Or three months.  Or two years from now.



Re: ZZZ and extra mountpoints

2022-10-21 Thread Theo de Raadt
Mark Kettenis  wrote:

> > I tend to agree that the complexity of this is out of scope for
> > man pages. Understanding this properly requires reading books
> > about computer architecture first.
> 
> So I would phrase this as something like "device that the OpenBSD
> kernel considers removable".  And also note that the opposite happens
> as well: there are devices that our kernel considers non-removable
> that are in fact removable.  For example ExpressCard devices, which
> are considered non-removable since they are indistinguishable from
> normal PCIe devices.

Now you've really stepped in it.

I have an expresscard storage device.  At suspend time, it gets powered
off.  It detaches and reattaches at resume time.  Any partition mounts
are forceably unmounted when that happens.  Would softraid work in those
conditions?  I don't know, and I don't care.


I want us all to take a step back here.

Some of you want to describe the situation as accurately as possible,
and obviously then our users will take what they read as promises that
it works that way, it won't change, and they can build complicated
layers on top of it.

Describing it accurately will only encourage more people to create
fragile configurations, write blogs about it, and thus encourage even
more people to create more broken situations.

I think that procedure is hogwash.  A more accurate picture is that the
machines don't provide us with sufficient information, and therefore we
will do whatever it takes in the kernel to ensure that suspend/resume
works for 99% of the people, and the other 1% of people will lose.  If
people start constructing complicated scenarios, the number of losing
cases will increase.









Re: ZZZ and extra mountpoints

2022-10-21 Thread Theo de Raadt
Stefan Sperling  wrote:

> And perhaps the entire USB bus will be powered down when
> the host controller goes to sleep, and all connected devices
> will lose power.

 but oh ... the situation is even more
complicated:

There are situations where a machine won't suspend because a bus has
power-draw on it, because we didn't evict the sub-devices, so some code
kicks devices off, otherwise you can't suspend.

Now hibernate could be a bit different, but who is going to write this
code and validate it on all machines??

Not me.  Not anyone.  But oh, we can try to describe this strange situation
in a manual page which noone will read before they hit the situation of a
device disconnecting during suspend?  So helpful /sarc.



Re: ZZZ and extra mountpoints

2022-10-21 Thread Theo de Raadt
Jason McIntyre  wrote:

> > It is extremely complicated, there is no way to accurately explain
> > in user-speak what devices detach and what devices don't detach.
> > 
> 
> pluggable?

Sorry, that is completely untrue.

What kind of plug?
A USB plug?
A MMC plug?
A PCI plug?
A MINI-PCIE plug?
A docking station which has both USB or PCI plugins?
An internal USB plug?
How about an internal SDMMC device?
And how about thunderbolt?
How about an extern scsi chassis with it's own power?

I could probably write a 5-sentence paragraph delineating the boundaries
with great precision and yet the people reading it would find they still
cannot discern exactly what devices will be detached.

"If it loses power" isn't accurate either.

Some of our drivers even self-protect themselves by FORCING a detach of their
children.

you all seem to want a single word or a simple sentence, but I'm sorry it
isn't simple at all.


> > And if we can't write a correct sentence for that, maybe we should realize
> > we don't need to?
> > 
> > Make a proposal.
> > 
> 
> i agree that the original proposal was wrong. if anything, you'd maybe
> want to know, for example, how to make it that you *were* asked for your
> password when resuming an encrypted mount. that seems more pertinent to
> softraid(4) than apm(8).


I think that is nonsense.  These subsystems were not designed to work
together in the way that people _now believe_ they should work together.
Now they want to document small little edges of their experience without
understanding how the layers of different code actually works?  It is
trying to document based upon ignorance.




Re: ZZZ and extra mountpoints

2022-10-21 Thread Theo de Raadt
Solène Rapenne  wrote:

> I agree my sentence isn't good enough or is too much, but I think ZZZ
> explanations isn't enough in its current form

Maybe it is lacking.  But your previous diff didn't help anyone.

> from your reply I got
> information such as external devices that wasn't described in the man
> page.

External devices have to get detached.  They lose their configuration
because they lose their power.

The problem is that it is very difficult to explain to users, in a
precise way, what an 'external device' is versus an 'internal device'.

It is extremely complicated, there is no way to accurately explain
in user-speak what devices detach and what devices don't detach.

And if we can't write a correct sentence for that, maybe we should realize
we don't need to?

Make a proposal.



Re: ZZZ and extra mountpoints

2022-10-21 Thread Theo de Raadt
I disagree with this sentence.

The machine is unhiberated in the same way that an unsuspend happens.

EVERYTHING is as it was before, except for one thing: Devices which are
not known to be part of the machine, will have become detached, and
if/when they reattach, configuration of them will be missing.  But that
is not what you are describing here, in fact it is wrong, because a
softraid partition on a usb device (or similar) will be gone.  So you
are adding a detail which is unneccesary, but also inaccurate.

If you add this sentence, the next one sentence someone will propose
will likely be "network configuration" remains the same.  Then, a sentence
that your programs are still running.  And on and on, trying to explain
that this isn't like a reboot.

But all of that "state-maintained" information is already implied,
because that is what suspend/resume and hibernate/unhibernate means.

Solène Rapenne  wrote:

> hi
> 
> I'm using an dedicated encrypted partition for a mountpoint and I was
> wondering what would happen if I use ZZZ and then resume.
> 
> - will it work out of the box?
> - will it fail because the softraid device won't exist?
> - am I going to be asked the passphrase by my rc.local script?
> 
> It turned it worked out of the box, which mean the partitions remains
> unlocked. In my opinion it's worth documenting, however I'm really not
> sure how to word this in apm(8), here is an attempt
> 
> diff --git a/usr.sbin/apm/apm.8 b/usr.sbin/apm/apm.8
> index ed110e11f14..61d414da8f1 100644
> --- a/usr.sbin/apm/apm.8
> +++ b/usr.sbin/apm/apm.8
> @@ -105,6 +105,8 @@ boot will occur, followed by the reading of the saved
>  memory image.
>  The image will then be unpacked and the system resumed
>  at the point immediately after the hibernation request.
> +This implies that extra encrypted partitions (like an
> +external disk) will remain unlocked after the resume.
>  .It Fl z
>  Put the system into suspend (deep sleep) state.
>  .El
> 



Re: rm -P and no-write on files - perm denied, bail out?

2022-10-14 Thread Theo de Raadt
Mikolaj Kucharski  wrote:

> Hi,
> 
> Kind reminder. Diff re-attached at the end and on MARC:
> 
> https://marc.info/?l=openbsd-tech=166219807307308=2

I don't understand what your complaint is, because:

 -P  Attempt to overwrite regular writable files before deleting them.
 ^

Well, the attempt fails.

Then rm continues to do what rm does, which specifically is to not leave
files not removed.


> On Sat, Sep 03, 2022 at 09:44:46AM +, Mikolaj Kucharski wrote:
> > Hi,
> > 
> > I wanted to rm -rP some files on my disk and didn't notice that
> > they lacked write permission for the user who executed rm(1)
> > command.
> > 
> > $ echo foo > file-mode-444.txt
> > $ chmod 0444 file-mode-444.txt
> > $ ls -ln file-mode-444.txt
> > -r--r--r--  1 5001  5001  4 Sep  3 09:36 file-mode-444.txt
> > 
> > $ rm -vfP file-mode-444.txt
> > rm: file-mode-444.txt: Permission denied
> > file-mode-444.txt
> > $ echo $?
> > 1
> > 
> > $ ls -l file-mode-444.txt
> > ls: file-mode-444.txt: No such file or directory
> > 
> > I was not expecting this behaviour. My expectation was the file would
> > NOT be removed. Hence the diff below:
> > 
> > 
> > Index: rm.c
> > ===
> > RCS file: /cvs/src/bin/rm/rm.c,v
> > retrieving revision 1.44
> > diff -u -p -u -r1.44 rm.c
> > --- rm.c16 Aug 2022 13:52:41 -  1.44
> > +++ rm.c3 Sep 2022 09:37:44 -
> > @@ -215,8 +215,11 @@ rm_tree(char **argv)
> > case FTS_F:
> > case FTS_NSOK:
> > if (Pflag)
> > -   rm_overwrite(p->fts_accpath, p->fts_info ==
> > -   FTS_NSOK ? NULL : p->fts_statp);
> > +   if (!rm_overwrite(p->fts_accpath, p->fts_info ==
> > +   FTS_NSOK ? NULL : p->fts_statp)) {
> > +   eval = 1;
> > +   continue;
> > +   }
> > /* FALLTHROUGH */
> > default:
> > if (!unlink(p->fts_accpath)) {
> > @@ -267,7 +270,10 @@ rm_file(char **argv)
> > rval = rmdir(f);
> > else {
> > if (Pflag)
> > -   rm_overwrite(f, );
> > +   if (!rm_overwrite(f, )) {
> > +   eval = 1;
> > +   continue;
> > +   }
> > rval = unlink(f);
> > }
> > if (rval && (!fflag || errno != ENOENT)) {
> > 
> > 
> > What do you guys think?
> > 
> > 
> > $ ./obj/rm -vfP file-mode-444.txt
> > rm: file-mode-444.txt: Permission denied
> > $ echo $?
> > 1
> > 
> > $ ls -ln file-mode-444.txt
> > -r--r--r--  1 5001  5001  4 Sep  3 09:36 file-mode-444.txt
> > 
> > I did use `rm -fP` in the invocation, and reading the rm(1) manual page:
> > 
> >-f  Attempt to remove the files without prompting for confirmation,
> >regardless of the file's permissions.  If the file does not
> >exist, do not display a diagnostic message or modify the exit
> >status to reflect an error.  The -f option overrides any previous
> >-i options.
> > 
> > but not sure then what exactly should happen when -P and -f and no write
> > permission.
> > 
> 
> 
> Index: rm.c
> ===
> RCS file: /cvs/src/bin/rm/rm.c,v
> retrieving revision 1.44
> diff -u -p -u -r1.44 rm.c
> --- rm.c  16 Aug 2022 13:52:41 -  1.44
> +++ rm.c  14 Oct 2022 21:41:22 -
> @@ -215,8 +215,11 @@ rm_tree(char **argv)
>   case FTS_F:
>   case FTS_NSOK:
>   if (Pflag)
> - rm_overwrite(p->fts_accpath, p->fts_info ==
> - FTS_NSOK ? NULL : p->fts_statp);
> + if (!rm_overwrite(p->fts_accpath, p->fts_info ==
> + FTS_NSOK ? NULL : p->fts_statp)) {
> + eval = 1;
> + continue;
> + }
>   /* FALLTHROUGH */
>   default:
>   if (!unlink(p->fts_accpath)) {
> @@ -267,7 +270,10 @@ rm_file(char **argv)
>   rval = rmdir(f);
>   else {
>   if (Pflag)
> - rm_overwrite(f, );
> + if (!rm_overwrite(f, )) {
> + eval = 1;
> + continue;
> + }
>   rval = unlink(f);
>   }
>   if (rval && (!fflag || errno != ENOENT)) {
> 
> 
> -- 
> Regards,
>  Mikolaj
> 



Re: snmpd(8): don't link to libkvm

2022-10-14 Thread Theo de Raadt
Martijn van Duren  wrote:

> This one got overlooked when all the metrics moved to snmpd_metrics.
> 
> OK?
> 
> martijn@
> 
> Index: Makefile
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/Makefile,v
> retrieving revision 1.21
> diff -u -p -r1.21 Makefile
> --- Makefile  6 Oct 2022 14:41:08 -   1.21
> +++ Makefile  14 Oct 2022 15:28:48 -
> @@ -8,7 +8,7 @@ SRCS= parse.y log.c snmpe.c application
>   mps.c trap.c mib.c smi.c snmpd.c \
>   proc.c usm.c traphandler.c util.c
>  
> -LDADD=   -levent -lutil -lkvm -lcrypto
> +LDADD=   -levent -lutil -lcrypto
>  DPADD=   ${LIBEVENT} ${LIBUTIL}
>  CFLAGS+= -Wall -I${.CURDIR}
>  CFLAGS+= -Wstrict-prototypes -Wmissing-prototypes
> 

No kidding, but your DPADD dependency is also wrong.



Re: hostctl: Change from fixed length to variable length

2022-10-11 Thread Theo de Raadt
YASUOKA Masahiko  wrote:

> Currently the value on VMware may be truncated silently.  It's simply
> broken.  I think we should fix it by having a way to know if the value
> is reached the limit.
> 
> Also I think we should be able to pass larger size of data.  Since at
> least on VMware, people is useing for parameters when deployment
> through OVF tamplate.  Sometimes the parameter includes large data
> like X.509 certificate.
> 
> https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-D0F9E3B9-B77B-4DEF-A982-49B9F6358FF3.html
> 
> What do you think?
> 
> > Prepare a variable like kern.maxpvbus and default it to
> > 4096.  Futhermore, how about free() after copyout() to user space?
> 
> I suppose we can use the space prepared by the userland directly.

An example of this mechanism is SIOCGIFCONF.  The ioctl passes a pointer
to a struct containing length & pointer to data.  See net/if.c ifconf()
There are other similar schemes, but they all come down to asking the
kernel for the size and then doing a 2nd ioctl.

Or a 3rd or more calls, in case the value has changed in the meantime and
grown even further, but userland can realloc() the storage until it wins.



Re: sysupgrade: exit 1 instead of exit 0 when ending early

2022-10-10 Thread Theo de Raadt
It's been explained a few times that being up-to-date is not an error.
It's a good thing, and no action is neccessary when up-to-date.

Any non-zero value indicates an error, that would include 2.  You are
marking this as an error, when it isn't.

You think this will help your scripting.  Do you not realize the proposed
changes will break someone else's scripting?

Mikolaj Kucharski  wrote:

> On Fri, Oct 07, 2022 at 02:39:01PM -0400, Josh Grosse wrote:
> > For ease of running sysupgrade from within a script.
> > 
> 
> > diff --git a/usr.sbin/sysupgrade/sysupgrade.sh 
> > b/usr.sbin/sysupgrade/sysupgrade.sh
> > index d80ff127ffa..ce5800093c9 100644
> > --- a/usr.sbin/sysupgrade/sysupgrade.sh
> > +++ b/usr.sbin/sysupgrade/sysupgrade.sh
> > @@ -153,7 +153,7 @@ rm SHA256.sig
> >  
> >  if cmp -s /var/db/installed.SHA256 SHA256 && ! $FORCE; then
> > echo "Already on latest snapshot."
> > -   exit 0
> > +   exit 1
> >  fi
> >  
> >  # INSTALL.*, bsd*, *.tgz
> 
> Maybe something like this?
> 
> 
> Index: sysupgrade.8
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.8,v
> retrieving revision 1.13
> diff -u -p -u -r1.13 sysupgrade.8
> --- sysupgrade.8  8 Jun 2022 09:03:11 -   1.13
> +++ sysupgrade.8  10 Oct 2022 06:59:49 -
> @@ -89,6 +89,10 @@ mirror top-level URL for fetching an upg
>  .It Pa /home/_sysupgrade
>  Directory the upgrade is downloaded to.
>  .El
> +.Sh EXIT STATUS
> +.Ex -std sysupgrade
> +In particular, 2 indicates upgraded was requested but
> +system is already on the latest snapshot.
>  .Sh SEE ALSO
>  .Xr signify 1 ,
>  .Xr installurl 5 ,
> Index: sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.48
> diff -u -p -u -r1.48 sysupgrade.sh
> --- sysupgrade.sh 8 Jun 2022 09:03:11 -   1.48
> +++ sysupgrade.sh 10 Oct 2022 06:59:49 -
> @@ -153,7 +153,7 @@ rm SHA256.sig
>  
>  if cmp -s /var/db/installed.SHA256 SHA256 && ! $FORCE; then
>   echo "Already on latest snapshot."
> - exit 0
> + exit 2
>  fi
>  
>  # INSTALL.*, bsd*, *.tgz
> 
> 
> -- 
> Regards,
>  Mikolaj
> 



Re: EFI runtime services support on amd64

2022-10-08 Thread Theo de Raadt
I'm not worried until it gets exposed to userland.

Mark Kettenis  wrote:

> Here is a diff that implements EFI runtime services support on amd64
> in much the same way as we already do on arm64.  This will be used in
> the future to implement support for EFI variables.
> 
> Some initial testing among OpenBSD developers did not uncover any
> issues.  So I'd like to move ahead with this.  If this ends up
> breaking machines we can always disable the 
> 
> ok?
> 
> 
> Index: arch/amd64/amd64/bios.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/bios.c,v
> retrieving revision 1.45
> diff -u -p -r1.45 bios.c
> --- arch/amd64/amd64/bios.c   21 Feb 2022 11:03:39 -  1.45
> +++ arch/amd64/amd64/bios.c   8 Oct 2022 16:07:02 -
> @@ -30,6 +30,7 @@
>  #include 
>  
>  #include "acpi.h"
> +#include "efi.h"
>  #include "mpbios.h"
>  #include "pci.h"
>  
> @@ -189,6 +190,18 @@ out:
>   break;
>   }
>   }
> +
> +#if NEFI > 0
> + if (bios_efiinfo != NULL) {
> + struct bios_attach_args ba;
> +
> + memset(, 0, sizeof(ba));
> + ba.ba_name = "efi";
> + ba.ba_memt = X86_BUS_SPACE_MEM;
> +
> + config_found(self, , bios_print);
> + }
> +#endif
>  
>  #if NACPI > 0
>   {
> Index: arch/amd64/amd64/efi_machdep.c
> ===
> RCS file: arch/amd64/amd64/efi_machdep.c
> diff -N arch/amd64/amd64/efi_machdep.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ arch/amd64/amd64/efi_machdep.c8 Oct 2022 16:07:02 -
> @@ -0,0 +1,296 @@
> +/*   $OpenBSD$   */
> +
> +/*
> + * Copyright (c) 2022 Mark Kettenis 
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +extern paddr_t cr3_reuse_pcid;
> +
> +#include 
> +
> +#include 
> +
> +extern todr_chip_handle_t todr_handle;
> +
> +extern EFI_MEMORY_DESCRIPTOR *mmap;
> +
> +struct efi_softc {
> + struct device   sc_dev;
> + struct pmap *sc_pm;
> + EFI_RUNTIME_SERVICES *sc_rs;
> + u_long  sc_psw;
> + uint64_tsc_cr3;
> +
> + struct todr_chip_handle sc_todr;
> +};
> +
> +int  efi_match(struct device *, void *, void *);
> +void efi_attach(struct device *, struct device *, void *);
> +
> +const struct cfattach efi_ca = {
> + sizeof(struct efi_softc), efi_match, efi_attach
> +};
> +
> +struct cfdriver efi_cd = {
> + NULL, "efi", DV_DULL
> +};
> +
> +void efi_map_runtime(struct efi_softc *);
> +void efi_enter(struct efi_softc *);
> +void efi_leave(struct efi_softc *);
> +int  efi_gettime(struct todr_chip_handle *, struct timeval *);
> +int  efi_settime(struct todr_chip_handle *, struct timeval *);
> +
> +int
> +efi_match(struct device *parent, void *match, void *aux)
> +{
> + struct bios_attach_args *ba = aux;
> + struct cfdata *cf = match;
> +
> + if (strcmp(ba->ba_name, cf->cf_driver->cd_name) == 0 &&
> + bios_efiinfo->system_table != 0)
> + return 1;
> +
> + return 0;
> +}
> +
> +void
> +efi_attach(struct device *parent, struct device *self, void *aux)
> +{
> + struct efi_softc *sc = (struct efi_softc *)self;
> + struct bios_attach_args *ba = aux;
> + uint32_t mmap_desc_ver = bios_efiinfo->mmap_desc_ver;
> + uint64_t system_table;
> + bus_space_handle_t memh;
> + EFI_SYSTEM_TABLE *st;
> + EFI_TIME time;
> + EFI_STATUS status;
> + uint16_t major, minor;
> + int i;
> +
> + if (mmap_desc_ver != EFI_MEMORY_DESCRIPTOR_VERSION) {
> + printf(": unsupported memory descriptor version %d\n",
> + mmap_desc_ver);
> + return;
> + }
> +
> + system_table = bios_efiinfo->system_table;
> + KASSERT(system_table);
> +
> + if (bus_space_map(ba->ba_memt, system_table, sizeof(EFI_SYSTEM_TABLE),
> + BUS_SPACE_MAP_LINEAR | BUS_SPACE_MAP_CACHEABLE, )) {
> + printf(": can't map system table\n");
> + return;
> + }
> +
> + st = bus_space_vaddr(ba->ba_memt, memh);
> + sc->sc_rs = st->RuntimeServices;
> +
> + major = 

Re: ldomctl: console: add -E escape_char

2022-10-06 Thread Theo de Raadt
I think if we make all the escape options in all the programs changable
via an option -- there will be only one person using it: Klemens Nanni.

This is 2022.  This is not a new problem, multi-layer escape with various
characters have been in ssh, cu, tmux, and other things for basicallyt forever.

People have lived with it for multiple decades.  They have gotten used to
the situation.

So I do not think it needs a new solution -- because I think noone will
discover the solution, and noone will use it.

Mark Kettenis  wrote:

> > Date: Sat, 17 Sep 2022 10:50:46 +
> > From: Klemens Nanni 
> > 
> > In my case, accessing guest domain consoles always happens through SSH,
> > ILOM, or conserver, so there's usually one more level to escape.
> > 
> > Changing cu(1)'s escape character makes things easier to type and harder
> > to mess up (~. instead of ~~. kills SSH/whatever instead of the guest
> > console).
> > 
> > Using 'cu -l ttyV* -E@' is not an option as 'ldomctl console -E@ foo'
> > takes care of the name-to-tty mapping, which may change with ldom.conf
> > changes.
> > 
> > 'ldomctl start|panic -c foo' also drop into the console but seem like
> > briefly used shortcuts (watch boot log, debug a specific thing) whereas
> > 'ldomctl console foo' is usually used for long running console access.
> > 
> > Feedback? OK? (for after release)
> 
> Doesn't really make sense to me.  I looked at vmctl(4) and it doesn't
> have this option.
> 
> > diff --git a/usr.sbin/ldomctl/ldomctl.8 b/usr.sbin/ldomctl/ldomctl.8
> > index 6d4b6dee6b5..776a2270809 100644
> > --- a/usr.sbin/ldomctl/ldomctl.8
> > +++ b/usr.sbin/ldomctl/ldomctl.8
> > @@ -44,10 +44,16 @@ in bytes.
> >  can be specified with a human-readable scale, using the format described in
> >  .Xr scan_scaled 3 ,
> >  e.g. 512M.
> > -.It Cm console Ar domain
> > +.It Cm console Oo Fl E Ar escape_char Oc Ar domain
> >  Using
> >  .Xr cu 1
> >  connect to the console of the guest domain.
> > +.Bl -tag -width 3n
> > +.It Fl E Ar escape_char
> > +Specify an escape character as per
> > +.Xr cu 1
> > +.Fl E .
> > +.El
> >  .It Cm delete Ar configuration
> >  Delete the specified configuration from non-volatile storage.
> >  .It Cm download Ar directory
> > diff --git a/usr.sbin/ldomctl/ldomctl.c b/usr.sbin/ldomctl/ldomctl.c
> > index e48a560f7db..906ab414488 100644
> > --- a/usr.sbin/ldomctl/ldomctl.c
> > +++ b/usr.sbin/ldomctl/ldomctl.c
> > @@ -131,7 +131,8 @@ usage(void)
> > "\t%1$s init-system [-n] file\n"
> > "\t%1$s create-vdisk -s size file\n"
> > "\t%1$s panic|start [-c] domain\n"
> > -   "\t%1$s console|status|stop [domain]\n",
> > +   "\t%1$s status|stop [domain]\n"
> > +   "\t%1$s console [-E escape_char] domain\n",
> > getprogname());
> >  
> > exit(EXIT_FAILURE);
> > @@ -403,7 +404,7 @@ download(int argc, char **argv)
> >  }
> >  
> >  void
> > -console_exec(uint64_t gid)
> > +console_exec(uint64_t gid, const char *escape_char)
> >  {
> > struct guest *guest;
> > char console_str[8];
> > @@ -419,6 +420,7 @@ console_exec(uint64_t gid)
> >  
> > closefrom(STDERR_FILENO + 1);
> > execl(LDOMCTL_CU, LDOMCTL_CU, "-r", "-l", console_str,
> > +   "-E", (escape_char != NULL) ? escape_char : "~",
> > (char *)NULL);
> > err(1, "failed to open console");
> > }
> > @@ -468,7 +470,7 @@ guest_start(int argc, char **argv)
> > err(1, "read");
> >  
> > if (console)
> > -   console_exec(gid);
> > +   console_exec(gid, NULL);
> >  }
> >  
> >  void
> > @@ -543,7 +545,7 @@ guest_panic(int argc, char **argv)
> > err(1, "read");
> >  
> > if (console)
> > -   console_exec(gid);
> > +   console_exec(gid, NULL);
> >  }
> >  
> >  void
> > @@ -680,15 +682,29 @@ void
> >  guest_console(int argc, char **argv)
> >  {
> > uint64_t gid;
> > +   int ch;
> > +   const char *Earg = NULL;
> >  
> > -   if (argc != 2)
> > +   while ((ch = getopt(argc, argv, "E:")) != -1) {
> > +   switch (ch) {
> > +   case 'E':
> > +   Earg = optarg;
> > +   break;
> > +   default:
> > +   usage();
> > +   }
> > +   }
> > +   argc -= optind;
> > +   argv += optind;
> > +
> > +   if (argc != 1)
> > usage();
> >  
> > hv_config();
> >  
> > -   gid = find_guest(argv[1]);
> > +   gid = find_guest(argv[0]);
> >  
> > -   console_exec(gid);
> > +   console_exec(gid, Earg);
> >  }
> >  
> >  void
> > 
> > 
> 



Re: malloc: prep for immutable pages

2022-10-06 Thread Theo de Raadt
Marc Espie  wrote:

> On Wed, Oct 05, 2022 at 07:54:41AM -0600, Theo de Raadt wrote:
> > Marc Espie  wrote:
> > 
> > > On Tue, Oct 04, 2022 at 10:15:51AM -0600, Theo de Raadt wrote:
> > > > A note on why this chance is coming.
> > > > 
> > > > malloc.c (as it is today), does mprotects back and forth between RW and
> > > > R, to protect an internal object.  This object is in bss, it is not
> > > > allocated with mmap.  With the upcoming mimmutable change, the bss will
> > > > become immutable by default, at program load time.  mimmutable even 
> > > > prevents
> > > > changing a RW object to R.
> > > 
> > > I'm probably missing something here, but for me, traditionally,
> > > BSS is the "set to 0" section of global variables of a program... which 
> > > are
> > > usually going to be changed to some other value.
> > > 
> > > Or are we talking at cross purposes ?
> > 
> > If you read the mimmutable diff, it has a manual page, and the answer is in
> > there.
> 
> Ah my mistake, I read a bit fast, and I thought the *pages* themselves were
> immutable.
> 
> Stupid question time: is there any reason not to allow further changes that
> would *restrict* the pages further ?
> 
> A bit like pledge works.
> 
> Like, say you mark a region "immutable" with RW rights, then later on
> use mprotect to mark it down RO, and you can never get back ?


I considered this when I first ran into the malloc and relpro issues, but
after consideration I found no use for such a semantic.

1. that is even more difficult to explain
2. if permissions are reduced, it can still result in a program flow control
   behaviour via a signal handler
3. mimmutable's job is to change mmap/munmap/mprotect to return -1, it does not
   terminate programs
4. Many programs don't check for mprotect failure, so the addition of mimmutable
   already going to be interesting enough without adding demotion to the picture



Re: malloc: prep for immutable pages

2022-10-05 Thread Theo de Raadt
Marc Espie  wrote:

> On Tue, Oct 04, 2022 at 10:15:51AM -0600, Theo de Raadt wrote:
> > A note on why this chance is coming.
> > 
> > malloc.c (as it is today), does mprotects back and forth between RW and
> > R, to protect an internal object.  This object is in bss, it is not
> > allocated with mmap.  With the upcoming mimmutable change, the bss will
> > become immutable by default, at program load time.  mimmutable even prevents
> > changing a RW object to R.
> 
> I'm probably missing something here, but for me, traditionally,
> BSS is the "set to 0" section of global variables of a program... which are
> usually going to be changed to some other value.
> 
> Or are we talking at cross purposes ?

If you read the mimmutable diff, it has a manual page, and the answer is in
there.



Re: hostctl: Change from fixed length to variable length

2022-10-04 Thread Theo de Raadt
Masato Asou  wrote:

> As you pointed out, it is not a good idea to allocate large spaces
> in kernel.
> 
> Would it be better to keep the current fixed length?
> 
> Prepare a variable like kern.maxpvbus and default it to
> 4096.  Futhermore, how about free() after copyout() to user space?

Sorry I did not look further since I am not familiar with the subsystem
or what the purpose of the change is.  Hopefully someone else who uses
it will speak up and you can come up with a compromise.



Re: hostctl: Change from fixed length to variable length

2022-10-04 Thread Theo de Raadt
Looking at these pieces:

+   sc->sc_rpc_buf = malloc(sc->sc_rpc_buflen, M_DEVBUF, M_NOWAIT);
...
+vm_rpc_buf_realloc(struct vmt_softc *sc, size_t len)
+{
+   free(sc->sc_rpc_buf, M_DEVBUF, sc->sc_rpc_buflen);
+
+   sc->sc_rpc_buflen = len / VMT_RPC_BUFLEN * VMT_RPC_BUFLEN;
+   sc->sc_rpc_buflen += ((len % VMT_RPC_BUFLEN) <= 0) ? 0 : VMT_RPC_BUFLEN;
+   sc->sc_rpc_buf = malloc(sc->sc_rpc_buflen, M_DEVBUF, M_NOWAIT);
...
+   else if (srclen > SIZE_T_MAX)
return (ENAMETOOLONG);

*dstp = dst = malloc(srclen + 1, M_TEMP|M_ZERO, M_WAITOK);

Userland may not ask the kernel to allocate such a huge object.  The
kernel address space is quite small.  First off, huge allocations will
fail.

But it is worse -- the small kernel address space is shared for many
purposes, so large allocations will harm the other subsystems.

As written, this diff is too dangerous.  Arbitrary allocation inside
the kernel is not reasonable.  object sizes requested by userland must
be small, or the operations must be cut up, which does create impact
on atomicity or other things.




Re: ps(1) unveils

2022-10-04 Thread Theo de Raadt
I think the idea was to do the unveil+pledge before kvm_openfiles, but
I ran into some other difficulty.  I wonder if issues remain.  It means
someone must play with dead kernels...

Theo Buehler  wrote:

> kvm_openfiles() happens before unveil. It opens these files (or falls
> back to defaults), stores the opened fds (but not their names) in kd,
> and the file names are never used later. So these unveils seem
> unnecessary.
> 
> I don't think the intention was to unveil before kvm_openfiles(), since
> then the unveils would be incomplete.
> 
> Am I missing something? 
> 
> Index: ps.c
> ===
> RCS file: /cvs/src/bin/ps/ps.c,v
> retrieving revision 1.79
> diff -u -p -r1.79 ps.c
> --- ps.c  1 Sep 2022 21:15:54 -   1.79
> +++ ps.c  3 Oct 2022 06:14:31 -
> @@ -287,15 +287,6 @@ main(int argc, char *argv[])
>   err(1, "unveil %s", _PATH_DEVDB);
>   if (unveil(_PATH_DEV, "r") == -1 && errno != ENOENT)
>   err(1, "unveil %s", _PATH_DEV);
> - if (swapf)
> - if (unveil(swapf, "r") == -1)
> - err(1, "unveil %s", swapf);
> - if (nlistf)
> - if (unveil(nlistf, "r") == -1)
> - err(1, "unveil %s", nlistf);
> - if (memf)
> - if (unveil(memf, "r") == -1)
> - err(1, "unveil %s", memf);
>   if (pledge("stdio rpath getpw ps", NULL) == -1)
>   err(1, "pledge");
>  
> 



Re: rc: do not clear mfs /tmp

2022-10-04 Thread Theo de Raadt
If it is empty at the beginning, the operation is free.

Today it is a narrow check for mfs.  Tomorrow someone will want to
add tmpfs to this.  And next month, some other crazy configuration.

So I do not see the point of this diff, at all.

The find operation is free.  The echo doesn't stab you in the eye.
Just ignore it.

Klemens Nanni  wrote:

> There is no problem to fix, but every boot I read "/clearing /tmp" and
> know it is a useless step since my /tmp live on volatile RAM anyway.
> 
> Other steps in rc(8) also check and print/log conditionally, so this
> can do as well, saving yet another line.
> 
> There is also the unconditional
>   echo 'preserving editor files.'; /usr/libexec/vi.recover
> which will never find anything to recover on mfs, but the script also
> creates directories, so skipping it on mfs would actually break things.
> 
> cvs diff -wU0:
>   |@@ -544,0 +545 @@ fi
>   |+if ! df -t mfs /tmp >/dev/null 2>&1; then
>   |@@ -548 +548,0 @@ echo clearing /tmp
>   |-# (not needed with mfs /tmp, but doesn't hurt there...).
>   |@@ -552,0 +553 @@ echo clearing /tmp
>   |+fi
> 
> Feedback? Objection? OK?
> 
> Index: rc
> ===
> RCS file: /cvs/src/etc/rc,v
> retrieving revision 1.564
> diff -u -p -r1.564 rc
> --- rc29 Aug 2022 11:51:05 -  1.564
> +++ rc4 Oct 2022 22:45:09 -
> @@ -542,14 +542,15 @@ if [[ -f /etc/ptmp ]]; then
>   'password file may be incorrect -- /etc/ptmp exists'
>  fi
>  
> -echo clearing /tmp
> +if ! df -t mfs /tmp >/dev/null 2>&1; then
> + echo clearing /tmp
>  
> -# Prune quickly with one rm, then use find to clean up /tmp/[lqv]*
> -# (not needed with mfs /tmp, but doesn't hurt there...).
> -(cd /tmp && rm -rf [a-km-pr-uw-zA-Z]*)
> -(cd /tmp &&
> -find . -maxdepth 1 ! -name . ! -name lost+found ! -name quota.user \
> - ! -name quota.group ! -name vi.recover -execdir rm -rf -- {} \;)
> + # Prune quickly with one rm, then use find to clean up /tmp/[lqv]*
> + (cd /tmp && rm -rf [a-km-pr-uw-zA-Z]*)
> + (cd /tmp &&
> + find . -maxdepth 1 ! -name . ! -name lost+found ! -name quota.user \
> + ! -name quota.group ! -name vi.recover -execdir rm -rf -- {} \;)
> +fi
>  
>  # Create Unix sockets directories for X if needed and make sure they have
>  # correct permissions.
> 



Re: malloc: prep for immutable pages

2022-10-04 Thread Theo de Raadt
A note on why this chance is coming.

malloc.c (as it is today), does mprotects back and forth between RW and
R, to protect an internal object.  This object is in bss, it is not
allocated with mmap.  With the upcoming mimmutable change, the bss will
become immutable by default, at program load time.  mimmutable even prevents
changing a RW object to R.

So I have added an elf section which indicates non-immutable sections in
the address space, and placed this object there.  That solves the problem
at hand.

However, this is leading otto to look at the life-cycle of this object,
to change when it's protection is changed, and consider that the code can
make the object immutable by itself, at the right time.

This diff should be tested in isolation from the immutable changes.
immutable changes will start coming into the tree soon...


Otto Moerbeek  wrote:

> Hi,
> 
> Rearrange things so that we do not have to flip protection of r/o
> pages back and forth when swicthing from single-threaded to
> multi-threaded. Also saves work in many cases by not initing pools
> until they are used: the pool used for MAP_CONCEAL pages is not used
> by very many processes and if you have just a few threads only a few
> pools will be set up.
> 
> The actual mimmutable calls are to be added later. I marked the places where
> they should end up. 
> 
> Please test, 
> 
>   -Otto
> 
> 
> Index: stdlib/malloc.c
> ===
> RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
> retrieving revision 1.274
> diff -u -p -r1.274 malloc.c
> --- stdlib/malloc.c   30 Jun 2022 17:15:48 -  1.274
> +++ stdlib/malloc.c   29 Sep 2022 09:42:57 -
> @@ -142,6 +142,7 @@ struct dir_info {
>   int malloc_junk;/* junk fill? */
>   int mmap_flag;  /* extra flag for mmap */
>   int mutex;
> + int malloc_mt;  /* multi-threaded mode? */
>   /* lists of free chunk info structs */
>   struct chunk_head chunk_info_list[MALLOC_MAXSHIFT + 1];
>   /* lists of chunks with free slots */
> @@ -181,8 +182,6 @@ struct dir_info {
>  #endif /* MALLOC_STATS */
>   u_int32_t canary2;
>  };
> -#define DIR_INFO_RSZ ((sizeof(struct dir_info) + MALLOC_PAGEMASK) & \
> - ~MALLOC_PAGEMASK)
>  
>  static void unmap(struct dir_info *d, void *p, size_t sz, size_t clear);
>  
> @@ -208,7 +207,6 @@ struct malloc_readonly {
>   /* Main bookkeeping information */
>   struct dir_info *malloc_pool[_MALLOC_MUTEXES];
>   u_int   malloc_mutexes; /* how much in actual use? */
> - int malloc_mt;  /* multi-threaded mode? */
>   int malloc_freecheck;   /* Extensive double free check */
>   int malloc_freeunmap;   /* mprotect free pages PROT_NONE? */
>   int def_malloc_junk;/* junk fill? */
> @@ -257,7 +255,7 @@ static void malloc_exit(void);
>  static inline void
>  _MALLOC_LEAVE(struct dir_info *d)
>  {
> - if (mopts.malloc_mt) {
> + if (d->malloc_mt) {
>   d->active--;
>   _MALLOC_UNLOCK(d->mutex);
>   }
> @@ -266,7 +264,7 @@ _MALLOC_LEAVE(struct dir_info *d)
>  static inline void
>  _MALLOC_ENTER(struct dir_info *d)
>  {
> - if (mopts.malloc_mt) {
> + if (d->malloc_mt) {
>   _MALLOC_LOCK(d->mutex);
>   d->active++;
>   }
> @@ -291,7 +289,7 @@ hash(void *p)
>  static inline struct dir_info *
>  getpool(void)
>  {
> - if (!mopts.malloc_mt)
> + if (mopts.malloc_pool[1] == NULL || !mopts.malloc_pool[1]->malloc_mt)
>   return mopts.malloc_pool[1];
>   else/* first one reserved for special pool */
>   return mopts.malloc_pool[1 + TIB_GET()->tib_tid %
> @@ -496,46 +494,22 @@ omalloc_init(void)
>  }
>  
>  static void
> -omalloc_poolinit(struct dir_info **dp, int mmap_flag)
> +omalloc_poolinit(struct dir_info *d, int mmap_flag)
>  {
> - char *p;
> - size_t d_avail, regioninfo_size;
> - struct dir_info *d;
>   int i, j;
>  
> - /*
> -  * Allocate dir_info with a guard page on either side. Also
> -  * randomise offset inside the page at which the dir_info
> -  * lies (subject to alignment by 1 << MALLOC_MINSHIFT)
> -  */
> - if ((p = MMAPNONE(DIR_INFO_RSZ + (MALLOC_PAGESIZE * 2), mmap_flag)) ==
> - MAP_FAILED)
> - wrterror(NULL, "malloc init mmap failed");
> - mprotect(p + MALLOC_PAGESIZE, DIR_INFO_RSZ, PROT_READ | PROT_WRITE);
> - d_avail = (DIR_INFO_RSZ - sizeof(*d)) >> MALLOC_MINSHIFT;
> - d = (struct dir_info *)(p + MALLOC_PAGESIZE +
> - (arc4random_uniform(d_avail) << MALLOC_MINSHIFT));
> -
> - rbytes_init(d);
> - d->regions_free = d->regions_total = MALLOC_INITIAL_REGIONS;
> - regioninfo_size = d->regions_total * sizeof(struct region_info);
> - d->r = 

Re: tftpd: add -R for read-only mode/reduced pledges

2022-10-03 Thread Theo de Raadt
David Gwynne  wrote:

> On Sun, Oct 02, 2022 at 06:32:04PM +, Klemens Nanni wrote:
> > diskless(8) just needs tftpd(8) to deliver files, none of the possibly
> > untrusted clients are supposed to ever write anything.
> > 
> > Either way, even when run without -c, a single file writable by _tftpd
> > might be enough for a malicious client to fill up the server's disk.
> > 
> > A proper read-only mode ("stdio rpath dns inet") seems much safer.
> 
> agreed. i'm ok with this diff, but it's worth asking if we can make the
> default read-only and ask people to opt in for write (and create) before
> this specific diff goes in. ie, read-only be default, '-w' to enable
> write mode, '-c' to enable write+create?

we were read-only believers a long time ago, and it seems the world has
caught up to our way of thinking so yes maybe it is time to make it an
option you must specify.



Re: rarpd: clarify synopsis

2022-10-02 Thread Theo de Raadt
Klemens Nanni  wrote:

> rarpd(8) is small enough where my impression is that refining it a
> little would be good, but it quickly comes down to personal taste.

And I continue to disagree.

Another example of the same pattern is ifconfig.  Here you will see it
is not documented that [-a] is incompatible with [interface], but the
program does actually enforce it (refuses to act).

Even later in the man page, this is not actually described.  Yet noone is
dying from this.

The synopsis / usage language simply cannot describe this, and I argue
that it SHOULD NOT describe the situation, because past attempts at
being complete precise have made the SYNOPSIS / usage cluttered, and
thus less valuable to the users.

Another way of looking at it is that the grammer is permissive, rather
than proscriptive.

So I suggest you get over it.



Re: Data Independent Timing on arm64

2022-10-02 Thread Theo de Raadt
ok, let's give it a shot then.

And watch for behaviour changes...


Mark Kettenis  wrote:

> > From: "Theo de Raadt" 
> > Date: Sat, 01 Oct 2022 09:37:01 -0600
> > 
> > Mark Kettenis  wrote:
> > 
> > > Armv8.4 introduced a feature that provides data independent timing for
> > > data processing instructions.  This feature is obviously introduced to
> > > mitigate timing side-channel attacks.  Presumably enabling the feature
> > > has some impact on performance as it would disable certain
> > > optimizations to guarantee constant-time execution of instructions.
> > 
> > But what impact does it have on all regular code?  I cannot find that
> > answer in the quoted email thread.  And I don't even see the question
> > being asked, because those people aren't talking about changing the
> > cpu to this mode permanently & completely.
> > 
> > > The only hardware that implements this feature that I've seen so far
> > > is Apple's Icestorm/Firestorm (M1) and Avalanche/Blizzard (M2) cores.
> > > I ran some benchmarks on an M2 Macbook Air.  In particular, I ran
> > > "eopenssl30 speed" bound to a "performance" core.
> > 
> > That is testing the performance of a program which uses a very narrow
> > set of cpu behaviours.  For example, it has almost no crossings in & out
> > of the kernel: system calls and page faults.  The class of operations
> > being tested are mostly pure compute against the register set rather
> > than memory, and when it does perform memory loads, it does so in quite
> > linear fashion.  It also does relatively few memory writes.
> 
> I also tested kernel builds.  I don't see any evidence of any
> significant impact on those.  
> 
> > It is a program that would be slower if they implimented the feature
> > poorly, but using such a small subset of system behaviours, I don't
> > think it can identify things which might be slower in part, and thus
> > have an effect on whole system performance.
> 
> The ARM ARM is rather explicit on the instructions that might be
> affected by those flags.  That list makes me believe any performance
> impact would show up most prominantly in code that uses the ARMv8
> crypto instructions.
> 
> > > I could not detect a significant slowdown with this feature enabled.
> > 
> > Then why did they make it a chicken bit?  Why did the cpu makers not
> > simply make the cpus always act this way?  There must be a reason,
> > probably undisclosed.  They have been conservative for some reasons.
> 
> I wouldn't call it a chicken bit.  But obviously those in charge of
> the architecture spec anticipated some significant speedup from having
> instructions that have data-dependent timings.  It appears that
> Apple's implementation doesn't though.
> 
> What might be going on here is that Apple is just ticking boxes to
> make their implementation spec compliant.  The feature is required for
> ARMv8.4 and above.  But if none of their instructions have
> data-dependent timing, they could implement the "chicken bit" without
> it actually having an effect.
> 
> > Is there an impact on the performance of building a full snapshot?  That
> > at least has a richer use of all code flows, with lots of kernel crossings,
> > as opposed to the openssl speed command.
> 
> I didn't test full snapshot builds.  I think the kernel builds I did
> should be representative enough.  But I certainly can do more
> benchmarking if you think that would be desirable.
> 
> > > Therefore I think we should enable this feature by default on OpenBSD.
> > 
> > Maybe.  But I am a bit unconvinced.
> > 
> > > The use of this feature is still being discussed in the wider
> > > comminity.  See for example the following thread:
> > > 
> > >   
> > > https://lore.kernel.org/linux-arm-kernel/ywgcrqutxmx0w...@gmail.com/T/#mfcba14511c69461bd8921fef758baae120d090dc
> > > 
> > 
> > That discussion is talking about providing the ability for programs to
> > request that mode of operation.  They are not talking about switching
> > into that mode for the kernel and all processes.
> > 
> > That seems like a big difference.
> > 
> > >From a security perspective it might make some sense, but this isn't
> > like some x86 catastrophy level speculation. I'm not sure there is
> > enough evidence yet that this is required for all modes of operation.
> 
> In principle this should be only necessary for code that is sensitive
> to timing side-channel attacks.  But the way I see it, the ecosystem
&

Re: rarpd: clarify synopsis

2022-10-02 Thread Theo de Raadt
The getopt language is imprecise, and attempts to be precise with it
usually go poorly.

For example,

SYNOPSIS
 ls [-1AaCcdFfgHhikLlmnopqRrSsTtux] [file ...]

% ls -1AaCcdFfgHhikLlmnopqRrSsTtux

The result may seem surprising.  I claim the result is not surprising.

It is unsurprising because the getopt langauge makes no claim about
which options are prioritized over other options, nor does it make
claims about which option combinations will be rejected and result
in error.

It only lists possibilities.  Sometimes the words in the manual page
describe the subset that will work, but sometimes it doesn't.  Sometimes
a program enforces a strict set of combinations, and somethings there
are surprises.

And that's fine.  Imagine trying to change the ls SYNOPSIS into 15 valid
combination so options, and then enforcing the priority and overlap
inside ls.c, and describing the reason why the priorites are chosen as
such (and probably introducing incompatibilities with other systems in
the process).  I think that would be a gigantic waste of time to do just
in ls, and I think we should only try to improve this in extremely
narrow cases when it really matters.

Klemens Nanni  wrote:

> rarpd(8) either "Listen[s] on all the Ethernets attached to the system"
> or requires an explicit list, not both:
> 
>   $ rarpd -a em0
>   usage: rarpd [-adflt] if0 [... ifN]
>   $ ./obj/rarpd -a em0
>   usage: rarpd [-dflt] -a | if ...
> 
> Or would this be better?
>   rarpd [-dflt] if ...
>   rarpd -a [-dflt]
> 
> Feedback? OK?
> 
> Index: rarpd.8
> ===
> RCS file: /cvs/src/usr.sbin/rarpd/rarpd.8,v
> retrieving revision 1.21
> diff -u -p -r1.21 rarpd.8
> --- rarpd.8   28 Oct 2015 10:02:59 -  1.21
> +++ rarpd.8   29 Sep 2022 21:04:29 -
> @@ -29,8 +29,8 @@
>  .Nd reverse ARP daemon
>  .Sh SYNOPSIS
>  .Nm rarpd
> -.Op Fl adflt
> -.Ar if0 Op Ar ... ifN
> +.Op Fl dflt
> +.Fl a | Ar if ...
>  .Sh DESCRIPTION
>  .Nm
>  services Reverse ARP requests on the Ethernet connected to
> Index: rarpd.c
> ===
> RCS file: /cvs/src/usr.sbin/rarpd/rarpd.c,v
> retrieving revision 1.79
> diff -u -p -r1.79 rarpd.c
> --- rarpd.c   15 Nov 2021 15:14:24 -  1.79
> +++ rarpd.c   29 Sep 2022 21:05:35 -
> @@ -217,7 +217,7 @@ init_all(void)
>  __dead void
>  usage(void)
>  {
> - (void) fprintf(stderr, "usage: rarpd [-adflt] if0 [... ifN]\n");
> + fprintf(stderr, "usage: rarpd [-dflt] -a | if ...\n");
>   exit(1);
>  }
>  
> 



Re: Data Independent Timing on arm64

2022-10-01 Thread Theo de Raadt
Mark Kettenis  wrote:

> Armv8.4 introduced a feature that provides data independent timing for
> data processing instructions.  This feature is obviously introduced to
> mitigate timing side-channel attacks.  Presumably enabling the feature
> has some impact on performance as it would disable certain
> optimizations to guarantee constant-time execution of instructions.

But what impact does it have on all regular code?  I cannot find that
answer in the quoted email thread.  And I don't even see the question
being asked, because those people aren't talking about changing the
cpu to this mode permanently & completely.

> The only hardware that implements this feature that I've seen so far
> is Apple's Icestorm/Firestorm (M1) and Avalanche/Blizzard (M2) cores.
> I ran some benchmarks on an M2 Macbook Air.  In particular, I ran
> "eopenssl30 speed" bound to a "performance" core.

That is testing the performance of a program which uses a very narrow
set of cpu behaviours.  For example, it has almost no crossings in & out
of the kernel: system calls and page faults.  The class of operations
being tested are mostly pure compute against the register set rather
than memory, and when it does perform memory loads, it does so in quite
linear fashion.  It also does relatively few memory writes.

It is a program that would be slower if they implimented the feature
poorly, but using such a small subset of system behaviours, I don't
think it can identify things which might be slower in part, and thus
have an effect on whole system performance.

> I could not detect a significant slowdown with this feature enabled.

Then why did they make it a chicken bit?  Why did the cpu makers not
simply make the cpus always act this way?  There must be a reason,
probably undisclosed.  They have been conservative for some reasons.

Is there an impact on the performance of building a full snapshot?  That
at least has a richer use of all code flows, with lots of kernel crossings,
as opposed to the openssl speed command.

> Therefore I think we should enable this feature by default on OpenBSD.

Maybe.  But I am a bit unconvinced.

> The use of this feature is still being discussed in the wider
> comminity.  See for example the following thread:
> 
>   
> https://lore.kernel.org/linux-arm-kernel/ywgcrqutxmx0w...@gmail.com/T/#mfcba14511c69461bd8921fef758baae120d090dc
> 

That discussion is talking about providing the ability for programs to
request that mode of operation.  They are not talking about switching
into that mode for the kernel and all processes.

That seems like a big difference.

>From a security perspective it might make some sense, but this isn't
like some x86 catastrophy level speculation. I'm not sure there is
enough evidence yet that this is required for all modes of operation.

> On arm64, the feature can be controlled from userland, so even if we
> turn it on by default, userland code can still make its own decisions
> on whether it wants the feature enabled or disabled.  We may have to
> expose the ID_AA64PFR0_EL1 register to userland when code shows uo
> that attempts to do that.

I suspect that is this will go.  Programs with specific libraries would
then request the feature on behalf of their entire runtime.  Something
like a constructor (or startup function) in libcrypto would enable it.
Meaning this program "might" care about timingsafe behaviour, so let's
enable it, for the remainder of the life of that program.




Re: wc(1): add -L flag to write length of longest line

2022-09-30 Thread Theo de Raadt
Todd C. Miller  wrote:

> On Thu, 29 Sep 2022 23:30:54 -0400, Daniel Dickman wrote:
> 
> > > On Sep 29, 2022, at 8:24 PM, Joerg Sonnenberger  wrote:
> > > 
> > > On Thu, Sep 29, 2022 at 08:39:16PM +1000, Jonathan Gray wrote:
> > >> wc counts items in files.  Finding the longest item indeed sounds
> > >> like a task better suited to awk.
> >
> > Doesn’t gnu wc show that tabs have length 8 rather than length 1?
> 
> Yes.
> 
> > Do the other wc implementations differ?
> 
> FreeBSD and NetBSD "wc -L" counts it as a single character.

How about if I want a feature that finds the shortest line?
Will that be -S?

And what about a feature to count dangling whitespace at the end of
lines?  -W looks available for use. Actually there are many flag
characters available, because wc hasn't jumped the shark yet, as ls did.

Imagine the eventual synopsis, it kind of rolls off the tongue

NAME
wc - word, line, and byte or character, or longest or shortest
 line, or dangling whitespace count

I'm looking forward to wc being able to edit files, and for further
extensibility because awk is slow, it can include a lisp interpreter.
Or maybe it should compile and run rust programs?  Safer that way.

I'm sure there are other people have other desireable features which I
haven't listed. For instance, could wc.c be the scaffold to use for the
long-desired web browser to be included in OpenBSD?



Re: immutable userland mappings

2022-09-28 Thread Theo de Raadt
Theo de Raadt  wrote:

> Theo de Raadt  wrote:
> 
> > > Yet another version of the diff as I incrementally get it working better.
> > > Call it version 22..
> 
> This is around version 30.

New version.

uvm_unmap_remove() now avoids doing entry splits as it scans for immutables
in the region.

Lots of // debug code remains, because there is a hunt for a linker bug;
some libraries are created subtly incorrectly, and it would be better if
they were correct and we could rip out some workarounds.

Index: gnu/llvm/lld/ELF/ScriptParser.cpp
===
RCS file: /cvs/src/gnu/llvm/lld/ELF/ScriptParser.cpp,v
retrieving revision 1.1.1.4
diff -u -p -u -r1.1.1.4 ScriptParser.cpp
--- gnu/llvm/lld/ELF/ScriptParser.cpp   17 Dec 2021 12:25:02 -  1.1.1.4
+++ gnu/llvm/lld/ELF/ScriptParser.cpp   17 Sep 2022 13:11:25 -
@@ -1478,6 +1478,7 @@ unsigned ScriptParser::readPhdrType() {
  .Case("PT_GNU_EH_FRAME", PT_GNU_EH_FRAME)
  .Case("PT_GNU_STACK", PT_GNU_STACK)
  .Case("PT_GNU_RELRO", PT_GNU_RELRO)
+ .Case("PT_OPENBSD_MUTABLE", PT_OPENBSD_MUTABLE)
  .Case("PT_OPENBSD_RANDOMIZE", PT_OPENBSD_RANDOMIZE)
  .Case("PT_OPENBSD_WXNEEDED", PT_OPENBSD_WXNEEDED)
  .Case("PT_OPENBSD_BOOTDATA", PT_OPENBSD_BOOTDATA)
Index: gnu/llvm/lld/ELF/Writer.cpp
===
RCS file: /cvs/src/gnu/llvm/lld/ELF/Writer.cpp,v
retrieving revision 1.3
diff -u -p -u -r1.3 Writer.cpp
--- gnu/llvm/lld/ELF/Writer.cpp 17 Dec 2021 14:46:47 -  1.3
+++ gnu/llvm/lld/ELF/Writer.cpp 17 Sep 2022 13:11:25 -
@@ -146,7 +146,7 @@ StringRef elf::getOutputSectionName(cons
{".text.", ".rodata.", ".data.rel.ro.", ".data.", ".bss.rel.ro.",
 ".bss.", ".init_array.", ".fini_array.", ".ctors.", ".dtors.", 
".tbss.",
 ".gcc_except_table.", ".tdata.", ".ARM.exidx.", ".ARM.extab.",
-".openbsd.randomdata."})
+".openbsd.randomdata.", ".openbsd.mutable." })
 if (isSectionPrefix(v, s->name))
   return v.drop_back();
 
@@ -2469,6 +2469,12 @@ std::vector Writer::c
   part.ehFrame->getParent() && part.ehFrameHdr->getParent())
 addHdr(PT_GNU_EH_FRAME, part.ehFrameHdr->getParent()->getPhdrFlags())
 ->add(part.ehFrameHdr->getParent());
+
+  // PT_OPENBSD_MUTABLE is an OpenBSD-specific feature. That makes
+  // the dynamic linker fill the segment with zero data, like bss, but
+  // it can be treated differently.
+  if (OutputSection *cmd = findSection(".openbsd.mutable", partNo))
+addHdr(PT_OPENBSD_MUTABLE, cmd->getPhdrFlags())->add(cmd);
 
   // PT_OPENBSD_RANDOMIZE is an OpenBSD-specific feature. That makes
   // the dynamic linker fill the segment with random data.
Index: gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h
===
RCS file: /cvs/src/gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h,v
retrieving revision 1.1.1.3
diff -u -p -u -r1.1.1.3 ELF.h
--- gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h   17 Dec 2021 12:23:22 
-  1.1.1.3
+++ gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h   17 Sep 2022 13:11:25 
-
@@ -1303,6 +1303,7 @@ enum {
   PT_GNU_RELRO = 0x6474e552,// Read-only after relocation.
   PT_GNU_PROPERTY = 0x6474e553, // .note.gnu.property notes sections.
 
+  PT_OPENBSD_MUTABLE = 0x65a3dbe5, // Like bss, but not immutable.
   PT_OPENBSD_RANDOMIZE = 0x65a3dbe6, // Fill with random data.
   PT_OPENBSD_WXNEEDED = 0x65a3dbe7,  // Program does W^X violations.
   PT_OPENBSD_BOOTDATA = 0x65a41be6,  // Section for boot arguments.
Index: gnu/usr.bin/binutils/bfd/elf.c
===
RCS file: /cvs/src/gnu/usr.bin/binutils/bfd/elf.c,v
retrieving revision 1.23
diff -u -p -u -r1.23 elf.c
--- gnu/usr.bin/binutils/bfd/elf.c  13 Jan 2015 20:05:01 -  1.23
+++ gnu/usr.bin/binutils/bfd/elf.c  17 Sep 2022 13:11:25 -
@@ -969,6 +969,7 @@ _bfd_elf_print_private_bfd_data (bfd *ab
case PT_GNU_EH_FRAME: pt = "EH_FRAME"; break;
case PT_GNU_STACK: pt = "STACK"; break;
case PT_OPENBSD_RANDOMIZE: pt = "OPENBSD_RANDOMIZE"; break;
+   case PT_OPENBSD_MUTABLE: pt = "OPENBSD_MUTABLE"; break;
default: sprintf (buf, "0x%lx", p->p_type); pt = buf; break;
}
  fprintf (f, "%8s off0x", pt);
@@ -2296,6 +2297,10 @@ bfd_section_from_phdr (bfd *abfd, Elf_In
   return

Re: Remove some unnecessary setproctitle(3) format strings

2022-09-27 Thread Theo de Raadt
Right.

This is called "idiomatic programming".

Sometimes it looks a bit idiotic (haha), but as the years go by, we've
learned that stylistic reminders that a rarely used function's parameter
is a variadic format string, helps us avoid introduction of new mistakes
during future development.

Stuart Henderson  wrote:

> These programs seem OK as-is, they are following the advice in
> https://man.openbsd.org/setproctitle.3#CAVEATS
> 
> On 2022/09/26 18:06, Josiah Frentsos wrote:
> > Index: sbin/dhcpleased/engine.c
> > ===
> > RCS file: /cvs/src/sbin/dhcpleased/engine.c,v
> > retrieving revision 1.38
> > diff -u -p -r1.38 engine.c
> > --- sbin/dhcpleased/engine.c5 May 2022 14:44:59 -   1.38
> > +++ sbin/dhcpleased/engine.c26 Sep 2022 21:43:28 -
> > @@ -197,7 +197,7 @@ engine(int debug, int verbose)
> > if (unveil(NULL, NULL) == -1)
> > fatal("unveil");
> >  
> > -   setproctitle("%s", "engine");
> > +   setproctitle("engine");
> > log_procinit("engine");
> >  
> > if (setgroups(1, >pw_gid) ||
> > Index: sbin/dhcpleased/frontend.c
> > ===
> > RCS file: /cvs/src/sbin/dhcpleased/frontend.c,v
> > retrieving revision 1.30
> > diff -u -p -r1.30 frontend.c
> > --- sbin/dhcpleased/frontend.c  14 Jul 2022 15:23:09 -  1.30
> > +++ sbin/dhcpleased/frontend.c  26 Sep 2022 21:43:29 -
> > @@ -151,7 +151,7 @@ frontend(int debug, int verbose)
> > if (unveil(NULL, NULL) == -1)
> > fatal("unveil");
> >  
> > -   setproctitle("%s", "frontend");
> > +   setproctitle("frontend");
> > log_procinit("frontend");
> >  
> > if ((ioctlsock = socket(AF_INET, SOCK_DGRAM | SOCK_CLOEXEC, 0)) == -1)
> > Index: sbin/slaacd/engine.c
> > ===
> > RCS file: /cvs/src/sbin/slaacd/engine.c,v
> > retrieving revision 1.84
> > diff -u -p -r1.84 engine.c
> > --- sbin/slaacd/engine.c26 Aug 2022 00:02:08 -  1.84
> > +++ sbin/slaacd/engine.c26 Sep 2022 21:43:29 -
> > @@ -372,7 +372,7 @@ engine(int debug, int verbose)
> > if (unveil(NULL, NULL) == -1)
> > fatal("unveil");
> >  
> > -   setproctitle("%s", "engine");
> > +   setproctitle("engine");
> > log_procinit("engine");
> >  
> > if (setgroups(1, >pw_gid) ||
> > Index: sbin/slaacd/frontend.c
> > ===
> > RCS file: /cvs/src/sbin/slaacd/frontend.c,v
> > retrieving revision 1.64
> > diff -u -p -r1.64 frontend.c
> > --- sbin/slaacd/frontend.c  12 Jul 2022 16:54:59 -  1.64
> > +++ sbin/slaacd/frontend.c  26 Sep 2022 21:43:29 -
> > @@ -153,7 +153,7 @@ frontend(int debug, int verbose)
> > if (unveil(NULL, NULL) == -1)
> > fatal("unveil");
> >  
> > -   setproctitle("%s", "frontend");
> > +   setproctitle("frontend");
> > log_procinit("frontend");
> >  
> > if ((ioctlsock = socket(AF_INET6, SOCK_DGRAM | SOCK_CLOEXEC, 0)) == -1)
> > Index: sbin/unwind/frontend.c
> > ===
> > RCS file: /cvs/src/sbin/unwind/frontend.c,v
> > retrieving revision 1.73
> > diff -u -p -r1.73 frontend.c
> > --- sbin/unwind/frontend.c  13 Mar 2022 15:14:01 -  1.73
> > +++ sbin/unwind/frontend.c  26 Sep 2022 21:43:30 -
> > @@ -207,7 +207,7 @@ frontend(int debug, int verbose)
> > if (chdir("/") == -1)
> > fatal("chdir(\"/\")");
> >  
> > -   setproctitle("%s", "frontend");
> > +   setproctitle("frontend");
> > log_procinit("frontend");
> >  
> > if (setgroups(1, >pw_gid) ||
> > Index: sbin/unwind/resolver.c
> > ===
> > RCS file: /cvs/src/sbin/unwind/resolver.c,v
> > retrieving revision 1.155
> > diff -u -p -r1.155 resolver.c
> > --- sbin/unwind/resolver.c  12 Mar 2022 14:35:29 -  1.155
> > +++ sbin/unwind/resolver.c  26 Sep 2022 21:43:30 -
> > @@ -368,7 +368,7 @@ resolver(int debug, int verbose)
> > if ((pw = getpwnam(UNWIND_USER)) == NULL)
> > fatal("getpwnam");
> >  
> > -   setproctitle("%s", "resolver");
> > +   setproctitle("resolver");
> > log_procinit("resolver");
> >  
> > if (setgroups(1, >pw_gid) ||
> > Index: usr.bin/ssh/sshd.c
> > ===
> > RCS file: /cvs/src/usr.bin/ssh/sshd.c,v
> > retrieving revision 1.591
> > diff -u -p -r1.591 sshd.c
> > --- usr.bin/ssh/sshd.c  17 Sep 2022 10:34:29 -  1.591
> > +++ usr.bin/ssh/sshd.c  26 Sep 2022 21:43:34 -
> > @@ -492,7 +492,7 @@ privsep_preauth(struct ssh *ssh)
> > set_log_handler(mm_log_handler, pmonitor);
> >  
> > privsep_preauth_child();
> > -   setproctitle("%s", "[net]");
> > +   setproctitle("[net]");
> > if (box != NULL)
> >

Re: [please test] tsc: derive frequency on AMD CPUs from MSRs

2022-09-25 Thread Theo de Raadt
This is not helping.

Please send Scott private replies regarding his diff.

Masato Asou  wrote:

> Hi,
> 
> I have new AMD laptop.  The dmesg is posted below:
> 
> OpenBSD 7.2 (GENERIC.MP) #2: Mon Sep 26 09:09:17 JST 2022
> a...@hp-obsd.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 7844245504 (7480MB)
> avail mem = 7589105664 (7237MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.3 @ 0xbc55d000 (35 entries)
> bios0: vendor AMI version "F.05" date 06/15/2022
> bios0: HP HP Laptop 14s-fq2xxx
> acpi0 at bios0: ACPI 6.2Undefined scope: \\_SB_.PCI0.28
> 
> acpi0: sleep states S0 S4 S5
> acpi0: tables DSDT FACP MSDM SSDT IVRS SSDT FIDT MCFG HPET VFCT SSDT TPM2 
> SSDT CRAT CDIT SSDT SSDT SSDT SSDT SSDT SSDT SSDT WSMT APIC SSDT SSDT SSDT 
> SSDT SSDT SSDT FPDT BGRT
> acpi0: wakeup devices GPP1(S4) GP17(S4) GPP0(S4)
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf000, bus 0-127
> acpihpet0 at acpi0: 14318180 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: MSR C001_0064: en 1 base 2 mul 92 div 8 freq 23 Hz
> cpu0: MSR C001_0065: en 1 base 2 mul 90 div 10 freq 18 Hz
> cpu0: MSR C001_0066: en 1 base 2 mul 96 div 12 freq 16 Hz
> cpu0: MSR C001_0067: en 0
> cpu0: MSR C001_0068: en 0
> cpu0: MSR C001_0069: en 0
> cpu0: MSR C001_006A: en 0
> cpu0: MSR C001_006B: en 0
> cpu0: AMD Ryzen 5 5625U with Radeon Graphics, 2295.73 MHz, 19-50-00
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 
> 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
> tsc: calibrating with acpihpet0: 2295691309 Hz
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=1.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD Ryzen 5 5625U with Radeon Graphics, 2295.69 MHz, 19-50-00
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 
> 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: AMD Ryzen 5 5625U with Radeon Graphics, 2295.69 MHz, 19-50-00
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 
> 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
> cpu2: smt 0, core 1, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: AMD Ryzen 5 5625U with Radeon Graphics, 2295.69 MHz, 19-50-00
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 
> 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
> cpu3: smt 1, core 1, package 0
> cpu4 at mainbus0: apid 4 (application processor)
> cpu4: AMD Ryzen 5 5625U with Radeon Graphics, 2295.69 MHz, 19-50-00
> cpu4: 
> 

Re: [please test] tsc: derive frequency on AMD CPUs from MSRs

2022-09-23 Thread Theo de Raadt
Scott Cheloha  wrote:

> > And it is the wrong time in the release cycle for this.
> 
> This doesn't need to make release, I'm just gauging interest and
> testing code.

But you didn't say that in your email.

But Worse, you didn't think that you need to say it.



Re: [please test] tsc: derive frequency on AMD CPUs from MSRs

2022-09-23 Thread Theo de Raadt
> And it is the wrong time in the release cycle for this.

No kidding.

As this makes absolutely no difference for any existing code in 7.2,
except the strong hazard of accidentally breaking a machine.



Re: CVS: cvs.openbsd.org: src

2022-09-21 Thread Theo de Raadt
This change fixes another wart in unveil/pledge which wasn't resolved in
the original design. pledge allows bypass-reading of
/usr/share/zoneinfo/ files for TZ=zone but absolute path support
remained a wart.

Once again, we have to remove a rarely used behavior of libc.  

During pledge and unveil propagation in programs, and even earlier with
privsep development (meaning use of chroot), we added many early calls
to tzset() in programs.  Some programs stopped using chroot, and rely upon
pledge and unveil instead.

Many of those tzset() calls could potentially be removed because other
libc functions can initialize late due to the zoneinfo directory bypass.
When doing so, please remmber -portable versions will still need to
perform the initialization calls early, and also the chroot case still
needs early initialization also.

Todd C. Miller  wrote:

> CVSROOT:  /cvs
> Module name:  src
> Changes by:   mill...@cvs.openbsd.org 2022/09/21 09:57:49
> 
> Modified files:
>   lib/libc/time  : localtime.c tzset.3 
> 
> Log message:
> tzset: ignore TZ if it contains an absolute path or issetugid().
> Reading time zone files from user-controlled paths can result in
> pledge(2) or unveil(2) violations.  We also ignore files that contain
> a '.' character to avoid paths containing ".." or hidden files.
> Work with and OK deraadt@
> 



Re: sysupgrade - Reading from socket: Undefined error: 0

2022-09-20 Thread Theo de Raadt
Florian Obser  wrote:

> On 2022-09-19 22:27 +02, Hrvoje Popovski  wrote:
> > Hi all,
> >
> > when doing sysupgrade few minutes ago on multiple machines i'm getting
> > error in subject
> >
> > smc24# sysupgrade -s
> > Fetching from https://cdn.openbsd.org/pub/OpenBSD/snapshots/amd64/
> > SHA256.sig   100% |*|
> > 2144   00:00
> > Signature Verified
> > INSTALL.amd64 100% ||
> > 43554   00:00
> > base72.tgz   100% |*|
> > 331 MB00:16
> > bsd  100% |*|
> > 22449 KB00:05
> > bsd.mp   100% |*|
> > 22562 KB00:04
> > bsd.rd   100% |*|
> > 4533 KB00:01
> > comp72.tgz   100% |*|
> > 74598 KB00:09
> > game72.tgz   100% |*|
> > 2745 KB00:01
> > man72.tgz100% |*|
> > 7610 KB00:02
> > xbase72.tgz   29% |**   |
> > 15744 KB00:14 ETAsysupgrade: Reading from socket: Undefined error: 0
> > smc24#
> >
> 
> Is this somehow coming from the non-blocking connect diff? I can't spot
> it though...

This was reproduced with ktrace.  It was a read() on the TLS socket, returning
0, or EOF.  Thus, errno is irrelevant.  The error printing code is being
dumb by printing this as an error.  But anyways, the connection was terminated,
and ...



Re: grdc: show timezone when TZ is set

2022-09-18 Thread Theo de Raadt
Paul Janzen  wrote:

> My issues with the time system are (a) it has to "just work", so it flees
> to UTC the instant something goes wrong, but never makes available any
> status as to whether the asked-for time zone is the one returned, except
> for (b) my program aborts if I'm pledged and I go do something silly with
> the TZ.

There is absolutely nothing wrong with this behaviour.

It is commonly known as 'garbage in, garbage in".



Re: grdc: show timezone when TZ is set

2022-09-18 Thread Theo de Raadt
Paul Janzen  wrote:

> Yeah, I know with pledge() you can't do testing like
> TZ=:/home/pjanzen/dev/usr/share/zoneinfo/testing/2022/America/Kentucky/Monticello
> any more, even though that's a perfectly cromulent and functional TZ on my
> system otherwise. So for the time being, probably any TZ that exists and
> doesn't abort grdc is 38 bytes or shorter.  Which works.


I disagree with the full-featured support of tzset() for all TZ paths.

and, of course your private Monticello file is corrupt TZ file, which exercises
a secret bug in the libc/time parser of the file, and you rely upon it to take
over control of this program, and other programs.


I despise this "feature".  It basically says that tzset() requires full
filesystem access during the whole program lifetime.

Actually it is worse than that.  Most programs do not call tzset().  I would
argue this program should not either.

Because there are 20+ libc API in src/lib/libc/time that will implicitly
do tzset(), whenever they need to.

And there are 10+ other libc API on that will call those libc/time API

And then there probably are thousands of API in other libraries which will
call those, late in a program's lifetime.


Backtracking, I think the idea that programs cannot be filesystem-contained
because of support for a stupid environment variable is dumb, and I think
it should fall back to the localtime or GMT for that program.

Otherwise if we wanted to be perfect, we should add tzset() as the first
function call in main() in ALL programs, which would be far more
repugnant than slowly taking the arbitrary path ability away from TZ, program
by program (in the same way we did for setuid/setgid binaries 20+ years ago).

tzload(const char *name, struct state *sp, int doextend)
...
if (name != NULL && issetugid() != 0) {
if ((name[0] == ':' && (strchr(name, '/') || strstr(name, 
".."))) ||
name[0] == '/' || strchr(name, '.'))
name = NULL;
}


I think you will notice noone notices or cares.


I can mock it further by suggesting we add a O_TZ flag to open() which
tzload() can use to bypass the restrictions, because pointing at a private
personal TZ file is a Unix Right /sarc



Re: apldckbd(4): add fn key combose for Page Up/Down

2022-09-16 Thread Theo de Raadt
> thing inside !SMALL_KERNEL

Is that neccessary?

Because arm64 has no limitation on bsd.rd size



Re: immutable userland mappings

2022-09-15 Thread Theo de Raadt
Theo de Raadt  wrote:

> > Yet another version of the diff as I incrementally get it working better.
> > Call it version 22..

This is around version 30.

There is still a subtle problem with RELRO, but it is masked with a hack.
arm64 also works correctly, and I'm onto the next architecture.  Systems
using bfd.ld need to be checked also.  There's a weird piece of logic
related to "libraries that never unload", I am not sure I did it right.

man page changes included.

Transition steps are:

   make new kernel, install, reboot
   [you will see uvm_unmap errors for various programs in dmesg]
   make includes
   cd gnu/usr.bin/clang; make && make install
   make backup copies of /usr/libexec/ld.so and the most recent libc.so
   build and install ld.so
   [you will now see uvm_map_protect errors in dmesg]
   build and install libc.so
   [the messages should go away]
   build everything

Index: gnu/llvm/lld/ELF/ScriptParser.cpp
===
RCS file: /cvs/src/gnu/llvm/lld/ELF/ScriptParser.cpp,v
retrieving revision 1.1.1.4
diff -u -p -u -r1.1.1.4 ScriptParser.cpp
--- gnu/llvm/lld/ELF/ScriptParser.cpp   17 Dec 2021 12:25:02 -  1.1.1.4
+++ gnu/llvm/lld/ELF/ScriptParser.cpp   2 Sep 2022 15:23:20 -
@@ -1478,6 +1478,7 @@ unsigned ScriptParser::readPhdrType() {
  .Case("PT_GNU_EH_FRAME", PT_GNU_EH_FRAME)
  .Case("PT_GNU_STACK", PT_GNU_STACK)
  .Case("PT_GNU_RELRO", PT_GNU_RELRO)
+ .Case("PT_OPENBSD_MUTABLE", PT_OPENBSD_MUTABLE)
  .Case("PT_OPENBSD_RANDOMIZE", PT_OPENBSD_RANDOMIZE)
  .Case("PT_OPENBSD_WXNEEDED", PT_OPENBSD_WXNEEDED)
  .Case("PT_OPENBSD_BOOTDATA", PT_OPENBSD_BOOTDATA)
Index: gnu/llvm/lld/ELF/Writer.cpp
===
RCS file: /cvs/src/gnu/llvm/lld/ELF/Writer.cpp,v
retrieving revision 1.3
diff -u -p -u -r1.3 Writer.cpp
--- gnu/llvm/lld/ELF/Writer.cpp 17 Dec 2021 14:46:47 -  1.3
+++ gnu/llvm/lld/ELF/Writer.cpp 2 Sep 2022 21:53:22 -
@@ -146,7 +146,7 @@ StringRef elf::getOutputSectionName(cons
{".text.", ".rodata.", ".data.rel.ro.", ".data.", ".bss.rel.ro.",
 ".bss.", ".init_array.", ".fini_array.", ".ctors.", ".dtors.", 
".tbss.",
 ".gcc_except_table.", ".tdata.", ".ARM.exidx.", ".ARM.extab.",
-".openbsd.randomdata."})
+".openbsd.randomdata.", ".openbsd.mutable." })
 if (isSectionPrefix(v, s->name))
   return v.drop_back();
 
@@ -2469,6 +2469,12 @@ std::vector Writer::c
   part.ehFrame->getParent() && part.ehFrameHdr->getParent())
 addHdr(PT_GNU_EH_FRAME, part.ehFrameHdr->getParent()->getPhdrFlags())
 ->add(part.ehFrameHdr->getParent());
+
+  // PT_OPENBSD_MUTABLE is an OpenBSD-specific feature. That makes
+  // the dynamic linker fill the segment with zero data, like bss, but
+  // it can be treated differently.
+  if (OutputSection *cmd = findSection(".openbsd.mutable", partNo))
+addHdr(PT_OPENBSD_MUTABLE, cmd->getPhdrFlags())->add(cmd);
 
   // PT_OPENBSD_RANDOMIZE is an OpenBSD-specific feature. That makes
   // the dynamic linker fill the segment with random data.
Index: gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h
===
RCS file: /cvs/src/gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h,v
retrieving revision 1.1.1.3
diff -u -p -u -r1.1.1.3 ELF.h
--- gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h   17 Dec 2021 12:23:22 
-  1.1.1.3
+++ gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h   14 Sep 2022 13:01:42 
-
@@ -1303,6 +1303,7 @@ enum {
   PT_GNU_RELRO = 0x6474e552,// Read-only after relocation.
   PT_GNU_PROPERTY = 0x6474e553, // .note.gnu.property notes sections.
 
+  PT_OPENBSD_MUTABLE = 0x65a3dbe5, // Like bss, but not immutable.
   PT_OPENBSD_RANDOMIZE = 0x65a3dbe6, // Fill with random data.
   PT_OPENBSD_WXNEEDED = 0x65a3dbe7,  // Program does W^X violations.
   PT_OPENBSD_BOOTDATA = 0x65a41be6,  // Section for boot arguments.
Index: gnu/usr.bin/binutils/bfd/elf.c
===
RCS file: /cvs/src/gnu/usr.bin/binutils/bfd/elf.c,v
retrieving revision 1.23
diff -u -p -u -r1.23 elf.c
--- gnu/usr.bin/binutils/bfd/elf.c  13 Jan 2015 20:05:01 -  1.23
+++ gnu/usr.bin/binutils/bfd/elf.c  14 Sep 2022 13:00:27 -
@@ -969,6 +969,7 @@ _bfd_elf_print_private_bfd_data (bfd *ab
case PT_GNU_EH_FRAME: pt = "EH_

Re: immutable userland mappings

2022-09-10 Thread Theo de Raadt
Theo de Raadt  wrote:

> Theo de Raadt  wrote:
> 
> > Theo de Raadt  wrote:
> > 
> > > In this version of the diff, the kernel manages to mark immutable most of
> > > the main binary, and in the shared-binary case, also most of ld.so.  But 
> > > it
> > > cannot mark all of the ELF mapping -- because of two remaining problems 
> > > (RELRO
> > > in .data, and the malloc.c self-protected bookkeeping page in .bss).  I am
> > > looking into various solutions for both of those.
> 
> Yet another version of the diff as I incrementally get it working better.
> Call it version 22..
> 
> Some things of note:
> 
> 1. Some linkers appear to be creating non-aligned relro sections, which
>has security implications as they cannot be mprotected correctly.  I
>am happy this work has exposed the problem as severe.  I have a
>workaround in ld.so for now that allows these cases to work, and
>later on we can perhaps add a warning to ld.so to identify these
>linkers and get them fixed.
> 
> 2. But the relro is still not handled perfectly, and I hope someone else's
>eyes can compare addresses and spot what's wrong.
> 
> 3. ld.so has to cut the list of mutable mappings from the immutable mappings,
>before applying them (late, to satisfy 1).This is in 
> _dl_apply_mutable().
>After redoing this a couple of times, I am still not proud of it.
> 
> 4. uvm_unmap_remove() must walk the entries in the region twice.  It cannot
>do unmapping work until it knows the region is completely muteable.  This
>might turn into a performance issue.
> 
> 5. binutils ld support completely untested, I mainly went in there to fix
>objdump and readelf.
> 
> 6. It would be nice to hear of a pkg that actually has a problem with this
>change.  I haven't found any yet but don't run many myself.
> 
> If anyone wants to debug issues, uncomment the // _dl_printf's in ld.so,
> and expect a lot of noise.  Then do something like "ktrace -di program
> >& log", and generate a kdump seperately.  It also helps if you test
> with programs that don't exit, so you can procmap -a -p $pid.  In the
> kdump output, it is important to look for "mprotect -1", because that
> provides evidence of the worst (silent) problems...

Oops, 1 line error in the diff, try this instead.

And to point 1 above, notice that a rare page of shared library mapping
is not immutable, right on the edge of the relro...

Index: gnu/llvm/lld/ELF/ScriptParser.cpp
===
RCS file: /cvs/src/gnu/llvm/lld/ELF/ScriptParser.cpp,v
retrieving revision 1.1.1.4
diff -u -p -u -r1.1.1.4 ScriptParser.cpp
--- gnu/llvm/lld/ELF/ScriptParser.cpp   17 Dec 2021 12:25:02 -  1.1.1.4
+++ gnu/llvm/lld/ELF/ScriptParser.cpp   2 Sep 2022 15:23:20 -
@@ -1478,6 +1478,7 @@ unsigned ScriptParser::readPhdrType() {
  .Case("PT_GNU_EH_FRAME", PT_GNU_EH_FRAME)
  .Case("PT_GNU_STACK", PT_GNU_STACK)
  .Case("PT_GNU_RELRO", PT_GNU_RELRO)
+ .Case("PT_OPENBSD_MUTABLE", PT_OPENBSD_MUTABLE)
  .Case("PT_OPENBSD_RANDOMIZE", PT_OPENBSD_RANDOMIZE)
  .Case("PT_OPENBSD_WXNEEDED", PT_OPENBSD_WXNEEDED)
  .Case("PT_OPENBSD_BOOTDATA", PT_OPENBSD_BOOTDATA)
Index: gnu/llvm/lld/ELF/Writer.cpp
===
RCS file: /cvs/src/gnu/llvm/lld/ELF/Writer.cpp,v
retrieving revision 1.3
diff -u -p -u -r1.3 Writer.cpp
--- gnu/llvm/lld/ELF/Writer.cpp 17 Dec 2021 14:46:47 -  1.3
+++ gnu/llvm/lld/ELF/Writer.cpp 2 Sep 2022 21:53:22 -
@@ -146,7 +146,7 @@ StringRef elf::getOutputSectionName(cons
{".text.", ".rodata.", ".data.rel.ro.", ".data.", ".bss.rel.ro.",
 ".bss.", ".init_array.", ".fini_array.", ".ctors.", ".dtors.", 
".tbss.",
 ".gcc_except_table.", ".tdata.", ".ARM.exidx.", ".ARM.extab.",
-".openbsd.randomdata."})
+".openbsd.randomdata.", ".openbsd.mutable." })
 if (isSectionPrefix(v, s->name))
   return v.drop_back();
 
@@ -2469,6 +2469,12 @@ std::vector Writer::c
   part.ehFrame->getParent() && part.ehFrameHdr->getParent())
 addHdr(PT_GNU_EH_FRAME, part.ehFrameHdr->getParent()->getPhdrFlags())
 ->add(part.ehFrameHdr->getParent());
+
+  // PT_OPENBSD_MUTABLE is an OpenBSD-specific feature. That makes
+  // the dynamic linker fill the segment with zero data, like bss, but
+  // i

Re: immutable userland mappings

2022-09-10 Thread Theo de Raadt
Theo de Raadt  wrote:

> Theo de Raadt  wrote:
> 
> > In this version of the diff, the kernel manages to mark immutable most of
> > the main binary, and in the shared-binary case, also most of ld.so.  But it
> > cannot mark all of the ELF mapping -- because of two remaining problems 
> > (RELRO
> > in .data, and the malloc.c self-protected bookkeeping page in .bss).  I am
> > looking into various solutions for both of those.

Yet another version of the diff as I incrementally get it working better.
Call it version 22..

Some things of note:

1. Some linkers appear to be creating non-aligned relro sections, which
   has security implications as they cannot be mprotected correctly.  I
   am happy this work has exposed the problem as severe.  I have a
   workaround in ld.so for now that allows these cases to work, and
   later on we can perhaps add a warning to ld.so to identify these
   linkers and get them fixed.

2. But the relro is still not handled perfectly, and I hope someone else's
   eyes can compare addresses and spot what's wrong.

3. ld.so has to cut the list of mutable mappings from the immutable mappings,
   before applying them (late, to satisfy 1).This is in _dl_apply_mutable().
   After redoing this a couple of times, I am still not proud of it.

4. uvm_unmap_remove() must walk the entries in the region twice.  It cannot
   do unmapping work until it knows the region is completely muteable.  This
   might turn into a performance issue.

5. binutils ld support completely untested, I mainly went in there to fix
   objdump and readelf.

6. It would be nice to hear of a pkg that actually has a problem with this
   change.  I haven't found any yet but don't run many myself.

If anyone wants to debug issues, uncomment the // _dl_printf's in ld.so,
and expect a lot of noise.  Then do something like "ktrace -di program
>& log", and generate a kdump seperately.  It also helps if you test
with programs that don't exit, so you can procmap -a -p $pid.  In the
kdump output, it is important to look for "mprotect -1", because that
provides evidence of the worst (silent) problems...


Index: gnu/llvm/lld/ELF/ScriptParser.cpp
===
RCS file: /cvs/src/gnu/llvm/lld/ELF/ScriptParser.cpp,v
retrieving revision 1.1.1.4
diff -u -p -u -r1.1.1.4 ScriptParser.cpp
--- gnu/llvm/lld/ELF/ScriptParser.cpp   17 Dec 2021 12:25:02 -  1.1.1.4
+++ gnu/llvm/lld/ELF/ScriptParser.cpp   2 Sep 2022 15:23:20 -
@@ -1478,6 +1478,7 @@ unsigned ScriptParser::readPhdrType() {
  .Case("PT_GNU_EH_FRAME", PT_GNU_EH_FRAME)
  .Case("PT_GNU_STACK", PT_GNU_STACK)
  .Case("PT_GNU_RELRO", PT_GNU_RELRO)
+ .Case("PT_OPENBSD_MUTABLE", PT_OPENBSD_MUTABLE)
  .Case("PT_OPENBSD_RANDOMIZE", PT_OPENBSD_RANDOMIZE)
  .Case("PT_OPENBSD_WXNEEDED", PT_OPENBSD_WXNEEDED)
  .Case("PT_OPENBSD_BOOTDATA", PT_OPENBSD_BOOTDATA)
Index: gnu/llvm/lld/ELF/Writer.cpp
===
RCS file: /cvs/src/gnu/llvm/lld/ELF/Writer.cpp,v
retrieving revision 1.3
diff -u -p -u -r1.3 Writer.cpp
--- gnu/llvm/lld/ELF/Writer.cpp 17 Dec 2021 14:46:47 -  1.3
+++ gnu/llvm/lld/ELF/Writer.cpp 2 Sep 2022 21:53:22 -
@@ -146,7 +146,7 @@ StringRef elf::getOutputSectionName(cons
{".text.", ".rodata.", ".data.rel.ro.", ".data.", ".bss.rel.ro.",
 ".bss.", ".init_array.", ".fini_array.", ".ctors.", ".dtors.", 
".tbss.",
 ".gcc_except_table.", ".tdata.", ".ARM.exidx.", ".ARM.extab.",
-".openbsd.randomdata."})
+".openbsd.randomdata.", ".openbsd.mutable." })
 if (isSectionPrefix(v, s->name))
   return v.drop_back();
 
@@ -2469,6 +2469,12 @@ std::vector Writer::c
   part.ehFrame->getParent() && part.ehFrameHdr->getParent())
 addHdr(PT_GNU_EH_FRAME, part.ehFrameHdr->getParent()->getPhdrFlags())
 ->add(part.ehFrameHdr->getParent());
+
+  // PT_OPENBSD_MUTABLE is an OpenBSD-specific feature. That makes
+  // the dynamic linker fill the segment with zero data, like bss, but
+  // it can be treated differently.
+  if (OutputSection *cmd = findSection(".openbsd.mutable", partNo))
+addHdr(PT_OPENBSD_MUTABLE, cmd->getPhdrFlags())->add(cmd);
 
   // PT_OPENBSD_RANDOMIZE is an OpenBSD-specific feature. That makes
   // the dynamic linker fill the segment with random data.
Index: gnu/usr.bin/binutils/bfd/elf.c
===
RCS file: /cvs/src/gnu/usr.bin/binut

Re: immutable userland mappings

2022-09-03 Thread Theo de Raadt
Theo de Raadt  wrote:

> In this version of the diff, the kernel manages to mark immutable most of
> the main binary, and in the shared-binary case, also most of ld.so.  But it
> cannot mark all of the ELF mapping -- because of two remaining problems (RELRO
> in .data, and the malloc.c self-protected bookkeeping page in .bss).  I am
> looking into various solutions for both of those.

I have mostly succeeded at changing this to a better model.  The
previous version had a real difficult time finding the specific objects
which cannot become immutable, so I found a way to describe them to the
kernel.

The ELF program headers now contain a new PHDR for section
".openbsd.mutable", aka OPENBSD_MUTABLE.  This is placed on the malloc
self-protected bookkeeping page.

When the main binary & ld.so are loaded the kernel can make all LOAD
regions immutable, and then in a later pass the kernel is permitted to
undo the immutable on the OPENBSD_MUTABLE and GNU_RELRO regions.  Only
the kernel can undo immutability, in these specific cases.

When crt0 finishes RELRO adjustment and mprotects PROT_READ, it also
marks the region immutable.  ld.so does the same for it's RELRO.

The libc malloc self-protection scheme can mprotect RW and R back and
forth when it wants, and it will never make this region immutable. 

When ld.so loads a library, it creates a queue of immutable and mutable
work actions to do after the library is done.  ld.so cannot reverse an
immutable, so it must clip the mutable regions out of the immutables.
This clip piece of the diff is embarrassingly poor.  It is very forgiving,
which is why I can run multiuser.  I do know that the system libraries are
clean, and anyways the big problems were with the malloc, relro, main
programs, and ld.so, not the other libraries

This version is harder to cross compile through, but I wanted to show in
case someone is interested.  There are numberous gaps (binutils lacks
support, other architectures, but the worst part is the immutuble
clipping code.


Index: gnu/llvm/lld/ELF/ScriptParser.cpp
===
RCS file: /cvs/src/gnu/llvm/lld/ELF/ScriptParser.cpp,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 ScriptParser.cpp
--- gnu/llvm/lld/ELF/ScriptParser.cpp   17 Dec 2021 12:25:02 -  1.1.1.4
+++ gnu/llvm/lld/ELF/ScriptParser.cpp   2 Sep 2022 15:23:20 -
@@ -1478,6 +1478,7 @@
  .Case("PT_GNU_EH_FRAME", PT_GNU_EH_FRAME)
  .Case("PT_GNU_STACK", PT_GNU_STACK)
  .Case("PT_GNU_RELRO", PT_GNU_RELRO)
+ .Case("PT_OPENBSD_MUTABLE", PT_OPENBSD_MUTABLE)
  .Case("PT_OPENBSD_RANDOMIZE", PT_OPENBSD_RANDOMIZE)
  .Case("PT_OPENBSD_WXNEEDED", PT_OPENBSD_WXNEEDED)
  .Case("PT_OPENBSD_BOOTDATA", PT_OPENBSD_BOOTDATA)
Index: gnu/llvm/lld/ELF/Writer.cpp
===
RCS file: /cvs/src/gnu/llvm/lld/ELF/Writer.cpp,v
retrieving revision 1.3
diff -u -r1.3 Writer.cpp
--- gnu/llvm/lld/ELF/Writer.cpp 17 Dec 2021 14:46:47 -  1.3
+++ gnu/llvm/lld/ELF/Writer.cpp 2 Sep 2022 21:53:22 -
@@ -146,7 +146,7 @@
{".text.", ".rodata.", ".data.rel.ro.", ".data.", ".bss.rel.ro.",
 ".bss.", ".init_array.", ".fini_array.", ".ctors.", ".dtors.", 
".tbss.",
 ".gcc_except_table.", ".tdata.", ".ARM.exidx.", ".ARM.extab.",
-".openbsd.randomdata."})
+".openbsd.randomdata.", ".openbsd.mutable." })
 if (isSectionPrefix(v, s->name))
   return v.drop_back();
 
@@ -2469,6 +2469,12 @@
   part.ehFrame->getParent() && part.ehFrameHdr->getParent())
 addHdr(PT_GNU_EH_FRAME, part.ehFrameHdr->getParent()->getPhdrFlags())
 ->add(part.ehFrameHdr->getParent());
+
+  // PT_OPENBSD_MUTABLE is an OpenBSD-specific feature. That makes
+  // the dynamic linker fill the segment with zero data, like bss, but
+  // it can be treated differently.
+  if (OutputSection *cmd = findSection(".openbsd.mutable", partNo))
+addHdr(PT_OPENBSD_MUTABLE, cmd->getPhdrFlags())->add(cmd);
 
   // PT_OPENBSD_RANDOMIZE is an OpenBSD-specific feature. That makes
   // the dynamic linker fill the segment with random data.
Index: gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h
===
RCS file: /cvs/src/gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 ELF.h
--- gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h   17 Dec 2021 12:23:22 
-  1.1.1.3
+++ gnu/llvm/llvm/include/llvm/BinaryFormat/ELF

Re: ps(1): add -d (descendancy) option to display parent/child process relationships

2022-09-01 Thread Theo de Raadt
Florian Obser  wrote:

> On 2022-09-01 09:55 -06, "Theo de Raadt"  wrote:
> > Job Snijders  wrote:
> >
> >> On Thu, Sep 01, 2022 at 03:14:40PM +0200, Martin Schröder wrote:
> >> > Am Do., 1. Sept. 2022 um 05:38 Uhr schrieb Job Snijders 
> >> > :
> >> > > Some ps(1) implementations have an '-d' ('descendancy') option. Through
> >> > > ASCII art parent/child process relationships are grouped and displayed.
> >> > >
> >> > > Thoughts?
> >> > 
> >> > gnu ps has
> >> > 
> >> > -d Select all processes except session leaders.
> >> > 
> >> > and
> >> > 
> >> >f  ASCII art process hierarchy (forest).
> >> > 
> >> >--forest
> >> >   ASCII art process tree.
> >> 
> >> GNU ps uses both '-f', '--forest', and '-H' to display process
> >> hierarchy. The '-H' option uses indenting (no ASCII art).
> >> 
> >> NetBSD's and FreeBSD's ps(1) use '-d' to display process hierarchy.
> >
> > using -f would follow the path of least resistance.  Is there really a 
> > common
> > user commnity between freebsd netbsd and openbsd?  I doubt it.
> >
> 
> Curious, my Jesus Laptop (macOS 12.5) has
>  -A  Display information about other users' processes, including
>  those without controlling terminals.
> [...]
>  -d  Like -A, but excludes session leaders.
> 
> It does not have this feature at all. Is this a new thing in FreeBSD?

A lot of macos is really old, and does not follow any upstream.
 



Re: ps(1): add -d (descendancy) option to display parent/child process relationships

2022-09-01 Thread Theo de Raadt
Job Snijders  wrote:

> On Thu, Sep 01, 2022 at 03:14:40PM +0200, Martin Schröder wrote:
> > Am Do., 1. Sept. 2022 um 05:38 Uhr schrieb Job Snijders :
> > > Some ps(1) implementations have an '-d' ('descendancy') option. Through
> > > ASCII art parent/child process relationships are grouped and displayed.
> > >
> > > Thoughts?
> > 
> > gnu ps has
> > 
> > -d Select all processes except session leaders.
> > 
> > and
> > 
> >f  ASCII art process hierarchy (forest).
> > 
> >--forest
> >   ASCII art process tree.
> 
> GNU ps uses both '-f', '--forest', and '-H' to display process
> hierarchy. The '-H' option uses indenting (no ASCII art).
> 
> NetBSD's and FreeBSD's ps(1) use '-d' to display process hierarchy.

using -f would follow the path of least resistance.  Is there really a common
user commnity between freebsd netbsd and openbsd?  I doubt it.



immutable userland mappings

2022-09-01 Thread Theo de Raadt
In the last few years, I have been improving the strictness of userland
memory layout.

An example is the recent addition of MAP_STACK and msyscall().  The first one
marks pages that are stack, so that upon entry to the kernel we can check if
the stack-pointer is pointing in the stack range.  If it isn't, the most obvious
conclusion is that a ROP pivot has occured, and we kills the process.  The 
second
one marks the region which contains syscall traps, if upon entry to the kernel
the PC is not in that region, we know somone is trying to do system calls via
an unapproved method.

My next attempt is to lock memory mappings.  The current working name is
mimmutable(void *addr, size_t len).  This identifies all current mapped memory
in a region, and tags the mappings.  Such mappings can never be unmapped.
No new mmap can be done on top of the mappings.  And the permissions cannot
be changed.  Other than that, the underlying storage memory works fine, it is
just the mapping that is locked.

I'm aware of an method used at least once (not on openbsd) which managed
to mprotect a region of libc, and then place things there, for later
execution.  That makes msyscall() less useful, so I want to restore the
strenth.

In this version of the diff, the kernel manages to mark immutable most of
the main binary, and in the shared-binary case, also most of ld.so.  But it
cannot mark all of the ELF mapping -- because of two remaining problems (RELRO
in .data, and the malloc.c self-protected bookkeeping page in .bss).  I am
looking into various solutions for both of those.

So for now, crt0 self-immutables the remaining parts, and ld.so does the same
for itself.  ld.so is also responsible for immutable marking on libraries it
loads.

To my surprise, the diff is working quite well.  With kern.allowkmem=1,
"procmap -a" can see what process mappings look like, and they are quite
locked down.  This is a view of a "sed", with 'grep -v anon'.  The "I" marker
indicates mapping immutability.   A few small chunks must still be fixed.

StartEnd Size  Offset   rwxSeIpc  RWX  
I/W/A Dev Inode - File
03128621a000-03128621cfff  12k  rIp+ (rwx) 
1/0/0 04:05   77840 - /usr/bin/sed [0xfd83e38b3640]
03128621d000-031286222fff  24k 2000 r-x--Ip+ (rwx) 
1/0/0 04:05   77840 - /usr/bin/sed [0xfd83e38b3640]
03148bbc3000-03148bbc3fff   4k  rIs- (r--) 
1/0/1 00:00   0 -   [ uvm_aobj ]
0314ea4e7000-0314ea51dfff 220k  rIp+ (rwx) 
1/0/0 04:05  103688 - /usr/lib/libc.so.96.1 [0xfd83e0c62608]
0314ea51e000-0314ea5c2fff 660k 00036000 r-x-eIp+ (rwx) 
1/0/0 04:05  103688 - /usr/lib/libc.so.96.1 [0xfd83e0c62608]
0314ea5c3000-0314ea5c8fff  24k 000da000 rIp- (rwx) 
1/0/0 04:05  103688 - /usr/lib/libc.so.96.1 [0xfd83e0c62608]
0314ea5c9000-0314ea5cbfff  12k 000df000 rw---Ip- (rwx) 
1/0/0 04:05  103688 - /usr/lib/libc.so.96.1 [0xfd83e0c62608]
031526544000-031526544fff   4k  r-x-eIp+ (rwx) 
1/0/1 00:00   0 -   [ uvm_aobj ]
031535da7000-031535da9fff  12k  rIp+ (rwx) 
1/0/0 04:05  336963 - /usr/libexec/ld.so [0xfd83e27f90e8]
031535eac000-031535eb6fff  44k 5000 r-x-eIp+ (rwx) 
1/0/0 04:05  336963 - /usr/libexec/ld.so [0xfd83e27f90e8]
031535fa7000-031535fa7fff   4k 0001 r-p- (rwx) 
1/0/0 04:05  336963 - /usr/libexec/ld.so [0xfd83e27f90e8]
031535fa8000-031535fa8fff   4k 00011000 rwp- (rwx) 
1/0/0 04:05  336963 - /usr/libexec/ld.so [0xfd83e27f90e8]
03154a19e000-03154a1b1fff  80k  rIp+ (rwx) 
1/0/0 04:04 3654731 - /var/run/ld.so.hints [0xfd83e1098960]
7f7ffdebd000-7f7fffbbcfff   29696k  --p+ (rwx) 
1/0/0 00:00   0 -   [ stack ]
 total   5724k


I wanted to show it a bit early.  To try the diff:
  - apply patch
  - cd /usr/src/sys/kern; make syscalls
  - build and boot new kernel
  - cd /usr/src; make includes
  - cd lib/libc; make && make install
  - cd /usr/src/*/ld.so; make && make install
  - cd /usr/src/lib/csu; make && make install
  - then other binaries can be built, including procmap



Index: lib/csu/boot.h
===
RCS file: /cvs/src/lib/csu/boot.h,v
retrieving revision 1.33
diff -u -p -u -r1.33 boot.h
--- lib/csu/boot.h  12 Jan 2022 21:41:06 -  1.33
+++ lib/csu/boot.h  31 Aug 2022 05:14:09 -
@@ -35,7 +35,6 @@
 #define_DYN_LOADER
 
 #include 
-#include 
 
 #include 
 
@@ -50,6 +49,7 @@ void _dl_exit(int);
  */
 #define REDIRECT_SYSCALL(x)typeof(x) x asm("_libc_"#x) __dso_hidden
 REDIRECT_SYSCALL(mprotect);
+REDIRECT_SYSCALL(mimmutable);
 
 #if RELOC_TAG == DT_RELA
 typedef

Re: vnconfig: don't print device on failure

2022-08-31 Thread Theo de Raadt
Sure.

Klemens Nanni  wrote:

> Noticed by mistake (wanted `-l'):
> 
>   # vnconfig l
>   vnd0
>   vnconfig: VNDIOCSET: No such file or directory
> 
> Same happens if you try to load a bogus file:
> 
>   # vnconfig ./empty  
>   vnd0
>   vnconfig: VNDIOCSET: Input/output error
> 
> In both cases, the info on stdout is useless as vnd0 is not used.
> Defer printing the device until after the file is set up:
> 
>   # vnconfig l
>   vnconfig: VNDIOCSET: No such file or directory
>   # ./obj/vnconfig ./empty  
>   vnconfig: VNDIOCSET: Input/output error
> 
> OK?
> 
> 
> Index: vnconfig.c
> ===
> RCS file: /cvs/src/sbin/vnconfig/vnconfig.c,v
> retrieving revision 1.10
> diff -u -p -r1.10 vnconfig.c
> --- vnconfig.c20 Aug 2022 06:39:24 -  1.10
> +++ vnconfig.c1 Sep 2022 01:29:56 -
> @@ -289,7 +289,6 @@ config(char *file, char *dev, struct dis
>   if (dev == NULL) {
>   if (getinfo(NULL, ) == -1)
>   err(1, "no devices available");
> - printf("vnd%d\n", unit);
>   asprintf(, "vnd%d", unit);
>   }
>  
> @@ -312,9 +311,12 @@ config(char *file, char *dev, struct dis
>   rv = ioctl(fd, VNDIOCSET, );
>   if (rv)
>   warn("VNDIOCSET");
> - else if (verbose)
> - fprintf(stderr, "%s: %llu bytes on %s\n", dev, vndio.vnd_size,
> - file);
> + else {
> + printf("%s\n", dev);
> + if (verbose)
> + fprintf(stderr, "%s: %llu bytes on %s\n", dev,
> + vndio.vnd_size, file);
> + }
>  
>   close(fd);
>   fflush(stdout);
> 



Re: [PATCH] Correctly (per POSIX) round up df usage percentage

2022-08-29 Thread Theo de Raadt
I would really prefer if this did not need floating point.

>From owner-tech+m90...@openbsd.org Mon Aug 29 03:52:24 2022
>Delivered-To: dera...@cvs.openbsd.org
>Date: Mon, 29 Aug 2022 11:47:16 +0200
>From: =?utf-8?B?0L3QsNCx?= 
>To: Stuart Henderson 
>Cc: tech@openbsd.org
>Subject: Re: [PATCH] Correctly (per POSIX) round up df usage percentage
>References: <20220827135316.4l2aawaoylbmb...@tarta.nabijaczleweli.xyz>
> 
>MIME-Version: 1.0
>Content-Type: multipart/signed; micalg=pgp-sha512;
>   protocol="application/pgp-signature"; boundary="g24jmql4w5mrdtfc"
>Content-Disposition: inline
>In-Reply-To: 
>User-Agent: NeoMutt/20220429
>List-Help: 
>List-ID: 
>List-Owner: 
>List-Post: 
>List-Subscribe: 
>List-Unsubscribe: 
>X-Loop: tech@openbsd.org
>Precedence: list
>Sender: owner-t...@openbsd.org
>
>
>--g24jmql4w5mrdtfc
>Content-Type: text/plain; charset=utf-8
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>Hi!
>
>On Sat, Aug 27, 2022 at 05:20:00PM +0100, Stuart Henderson wrote:
>> df is used on the ramdisk, so this would need testing there (at least on
>> the tighter media on some archs).
>>=20
>> at least one other ramdisk binary does pull in libm so the overall size
>> increase might not be terrible, but definitely would need checking.
>
>I lack the knowledge and capability to do testing beyond "I just built
>the patched version on CI and it rounded correctly", sorry.
>
>But if linking to libm is an issue, we could substitute the ceil(3)s
>with something trivial like
>-- >8 --
>int iceil(double d) {
>  int ret =3D d;
>  if(ret < d)
>++ret;
>  return ret;
>}
>-- >8 --
>since all the formatting specifiers use %.0f anyway and the [0, 200)
>domain is small enough that precision loss/overflow is not a factor.
>
>Best,
>=D0=BD=D0=B0=D0=B1
>
>--g24jmql4w5mrdtfc
>Content-Type: application/pgp-signature; name="signature.asc"
>
>-BEGIN PGP SIGNATURE-
>
>iQIzBAABCgAdFiEEfWlHToQCjFzAxEFjvP0LAY0mWPEFAmMMiyEACgkQvP0LAY0m
>WPFsSBAAqhg/9kgI6wLF1tX/S8PslI/LcIarSSw5C97acfarU9KbI++k1doVsKL4
>MeCXfBYqHVN4abVjpnQdVbf+wxsbj0g+SYNj+bEs1kQnpt0444tfgN8ea/6KrDS2
>l4eUHss1Bp667BoWyil8MgIESyPyswxdRwk5Ik/sXCSj7f89xTJAnwfDuuqEZpU9
>/xIey7E0d72lhpiTXDFdB50TsH3Cvtggf/ImXgbLdALZ1L7j8LurOu5jtjENTWtL
>4lkP/h6J46yuh0NAAFQk35mP48zeuMuICt5KxdlSTJAdmrDpQz+4W74g0izF1Lqs
>SNUWrkIHYirtPtjbPLB/+FgQt9okGY7ZGrRFSAwR0jxQh28+xTxpyaLSbrUqxYor
>rKG5JsNtCkV9ylXHpeQNeXu7uGy7ZO6mdnVGnwK7CdiQCU0QQ/BbbnNJ1lyhgkiB
>gHuK4MibINo/psF33tDMfN4hck6X6FW6mfemYei8sEsVLI/L1ioECJLXLcUyZKGl
>v00g4usuAl8Xb/WRhSOnGc98HQEcDuLtiE3gc8VT30NsQsKruPtX4gf47aGUbt8S
>dRVM5sdSAaxMixS7VN2cmIOJtt1y4GysrO7v3Gt06mvcYLrRLkfazIWYMXTjpgRT
>7k4fTZqMFWa1wDuPe9wL72oVv/VKZsKUkfkpj3WQmFO9Wu4yCp8=
>=RKzL
>-END PGP SIGNATURE-
>
>--g24jmql4w5mrdtfc--
>
>



Re: When did PCs stop using ISA Timer 1?

2022-08-26 Thread Theo de Raadt
Jonathan Gray  wrote:

> On Fri, Aug 26, 2022 at 10:21:32PM -0500, Scott Cheloha wrote:
> > I noticed that on non-LAPIC systems we program channel 0 in periodic
> > mode with an initial count of 11932 to effect a 100hz clock interrupt.
> > And then we also use that same channel to count time, but because we
> > aren't using the full 16-bit range we need to do all this checking and
> > incrementing to handle premature overflow to make it appear as though
> > the full counter is being used.
> > 
> > And I had this whimsical idea: gee, wouldn't it be so much easier to
> > use channel 0 for clock interrupts and a different channel for
> > counting time?
> > 
> > But then I started reading and saw that channel 1 had a dedicated
> > purpose in the bad old days.
> > 
> > So I was left wondering when channel 1 stopped performing that task,
> > and whether those systems (a) predate the APIC and (b) can even run
> > OpenBSD at all.
> 
> Attempting to use counter 1 would be more trouble than it is worth.

I would not be surprised if there existed machines with broken counter 1
(in some subtle way).




Re: When did PCs stop using ISA Timer 1?

2022-08-26 Thread Theo de Raadt
Jonathan Gray  wrote:

>> What difference does it make?  We don't use counter 1.
> 
> The PCH datasheets from 100 series and later only document counter 0
> and counter 2.
> 
> 9 series and earlier datasheet has
> "The PCH contains three counters that have fixed uses."
> 100 series and later
> "The PCH contains two counters that have fixed uses."

In other words:

Since that counter was previously used for a well-defined purpose but
then stopped being used for that case, there may be chipset vendors
who decided to REMOVE or BREAK the hardware... I think you can assume
nothing about it.

This question can only be answered by finding a body of code which
reliably uses it.



Re: struct ifnet: remove unused if_switchport member

2022-08-26 Thread Theo de Raadt
Mark Kettenis  wrote:

> > From: "Theo de Raadt" 
> > Date: Fri, 26 Aug 2022 09:53:35 -0600
> > 
> > Klemens Nanni  wrote:
> > 
> > > On Fri, Aug 26, 2022 at 04:15:43PM +0100, Stuart Henderson wrote:
> > > > On 2022/08/26 09:49, Klemens Nanni wrote:
> > > > > grep and CVS agree that this is a switch(4) left-over.
> > > > > 
> > > > > OK?
> > > > 
> > > > This is exported to userland isn't it?
> > > 
> > > No, everything is under _KERNEL.
> > 
> > But there are a few libraries and programs which #define _KERNEL
> 
> Outside of base?  Folks who do that deserve what they get.

The upstreams won't really care, but our pkg people have to act upon it.
That's why Stuart got involved...



Re: struct ifnet: remove unused if_switchport member

2022-08-26 Thread Theo de Raadt
Klemens Nanni  wrote:

> On Fri, Aug 26, 2022 at 04:15:43PM +0100, Stuart Henderson wrote:
> > On 2022/08/26 09:49, Klemens Nanni wrote:
> > > grep and CVS agree that this is a switch(4) left-over.
> > > 
> > > OK?
> > 
> > This is exported to userland isn't it?
> 
> No, everything is under _KERNEL.

But there are a few libraries and programs which #define _KERNEL

So when you see _KERNEL, you need to remain a bit cynical, and check.



Re: installer: zap fdisk.8.gz and disklabel.8.gz

2022-08-25 Thread Theo de Raadt
Klemens Nanni  wrote:

> On Thu, Aug 25, 2022 at 07:07:27PM +, Miod Vallat wrote:
> > > Well, something tells me the inclusion of the manual pages for fdisk
> > > and disklabel is deliberate.  Makes some sense as these are complex
> > > utilities and their interactive use is documented in those pages.
> > 
> > The ability to be able to read the manual pages from the binaries
> > themselves, when running is interactive mode, is an intentional feature
> > and the reason they embed a gzipped version of the formatted manpage.
> 
> Even in the installer?
> 
> From looking at how distrib works and Makefile.inc unconditionally sets
> NOMAN=1, it seems to me that the odd-balls fdisk and disklabel were
> overlooked here.
> 
> The manual feature is handy, but I don't think it's worth having in
> install media.
> 
> But sure, if others want this in the installer, I'll just leave it.

Whoosh.



Re: installer: zap fdisk.8.gz and disklabel.8.gz

2022-08-25 Thread Theo de Raadt
Wow you have it so backwards.

So we will have embedded manuals for the case we don't need need the
embedded manual because you have manuals installed (type ^Z and run man)
but in the systems where you don't have manual pages, you won't have
the embedded manuals.

Very logical to forget why this was added...



Klemens Nanni  wrote:

> On Thu, Aug 25, 2022 at 06:36:55PM +, Klemens Nanni wrote:
> > Turns out all install media ship full copies of those two manuals due to
> > what can be described like a makefile TOCTOU.
> > 
> > In /usr/src/distrib/special, Makefile.inc sets NOMAN=1 but */Makefile
> > only includes it in the very end through .
> > 
> > fdisk and disklabel have NOMAN logic before that include, so they don't
> > see it set yet and include the whole thing:
> > 
> > $ make -C fdisk manual.o
> > mk -C fdisk manual.o
> > mandoc -Tascii 
> > /usr/src/distrib/special/fdisk/../../../sbin/fdisk/fdisk.8 > fdisk.cat8
> > (echo 'const unsigned char manpage[] = {';  cat fdisk.cat8 | gzip -9c | 
> > hexdump -ve '"0x" 1/1 "%02x,"';  echo '};'; echo 'const int manpage_sz = 
> > sizeof(manpage);') > manual.c
> > cc -O2 -pipe  -DHAS_MBR -fno-pie -Oz -fno-stack-protector 
> > -fno-unwind-tables -fno-asynchronous-unwind-tables -MD -MP  -c manual.c
> > $ size fdisk/obj/manual.o
> > textdatabss dec hex
> > 35520   0   3552de0
> > 
> > Forcing it on the command line yields the desired behaviour:
> > $ make -C fdisk NOMAN=1 manual.o
> > (echo 'const unsigned char manpage[] = {';  echo 'no manual' | gzip -9c 
> > | hexdump -ve '"0x" 1/1 "%02x,"';  echo '};'; echo 'const int manpage_sz = 
> > sizeof(manpage);') > manual.c
> > cc -O2 -pipe  -DHAS_MBR -fno-pie -Oz -fno-stack-protector 
> > -fno-unwind-tables -fno-asynchronous-unwind-tables -MD -MP  -c manual.c
> > $ size fdisk/obj/manual.o
> > textdatabss dec hex
> > 36  0   0   36  24
> > 
> > Same for disklabel,  size before/after:
> > textdatabss dec hex
> > 61600   0   61601810
> > 36  0   0   36  24
> > 
> > I've confirmed this through an amd64 snapshots bsd.rd where I paged
> > through disklabel(8) via the 'M' command...
> > 
> > Here's a minimal diff to highlight this non-obvious issue and avoid
> > reshuffling, i.e. cut down on differences with /usr/src/sbin/*/Makefile.
> 
> Alternatively, here's a more invasive diff that rips out the compile
> logic around what I understand as purely man-install related NOMAN.
> 
> Regular fdisk and disklabel always inlcude the manual and special ones
> just print "no manual." rather than gzipping the string, decompressing
> it at runtime and running a pager through it.
> 
> I do like this a bit more as it makes the code simpler and just uses
> SMALL for this, as I'd expect;  This saves even more bits.
> 
> > 
> > Haven't built ramdisks yet to see the final size decrease, but everyone
> > should be happy with this.
> > 
> > OK?
> 
> 
> Index: sbin/fdisk/Makefile
> ===
> RCS file: /cvs/src/sbin/fdisk/Makefile,v
> retrieving revision 1.46
> diff -u -p -r1.46 Makefile
> --- sbin/fdisk/Makefile   23 May 2022 16:58:11 -  1.46
> +++ sbin/fdisk/Makefile   25 Aug 2022 18:47:14 -
> @@ -23,12 +23,6 @@ CLEANFILES += fdisk.cat8 manual.c
>  
>  .include 
>  
> -.ifdef NOMAN
> -manual.c:
> - (echo 'const unsigned char manpage[] = {'; \
> - echo 'no manual' | gzip -9c | hexdump -ve '"0x" 1/1 "%02x,"'; \
> - echo '};'; echo 'const int manpage_sz = sizeof(manpage);') > manual.c
> -.else
>  fdisk.cat8:  fdisk.8
>   mandoc -Tascii ${.ALLSRC} > ${.TARGET}
>  
> @@ -36,7 +30,6 @@ manual.c:   fdisk.cat8
>   (echo 'const unsigned char manpage[] = {'; \
>   cat fdisk.cat8 | gzip -9c | hexdump -ve '"0x" 1/1 "%02x,"'; \
>   echo '};'; echo 'const int manpage_sz = sizeof(manpage);') > manual.c
> -.endif
>  
>  MAN= fdisk.8
>  
> Index: sbin/fdisk/cmd.c
> ===
> RCS file: /cvs/src/sbin/fdisk/cmd.c,v
> retrieving revision 1.164
> diff -u -p -r1.164 cmd.c
> --- sbin/fdisk/cmd.c  25 Jul 2022 17:45:16 -  1.164
> +++ sbin/fdisk/cmd.c  25 Aug 2022 18:51:02 -
> @@ -509,6 +509,9 @@ Xflag(const char *args, struct mbr *mbr)
>  int
>  Xmanual(const char *args, struct mbr *mbr)
>  {
> +#ifdef SMALL
> + printf("no manual.\n");
> +#else
>   char*pager = "/usr/bin/less";
>   char*p;
>   FILE*f;
> @@ -527,6 +530,7 @@ Xmanual(const char *args, struct mbr *mb
>   }
>  
>   signal(SIGPIPE, opipe);
> +#endif   /* !SMALL */
>  
>   return CMD_CONT;
>  }
> Index: sbin/disklabel/Makefile
> ===
> RCS file: /cvs/src/sbin/disklabel/Makefile,v
> retrieving 

Re: installer: zap fdisk.8.gz and disklabel.8.gz

2022-08-25 Thread Theo de Raadt
I think you have this wrong.

If someone is operating in the install media, and manually adjusting
their disk, and they don't know the commands they need,  where are they
going to find the instructions?

In 1997, we added the embedded manual pages to fdisk (inside the
'manual' command) and disklabel (the 'M' command) specifically for users
who encounter this problem.  The '?' command shows you that you can see
the manual, and then you can use "M" to get a complete manual.

We don't know how much it is used, but it was added *SPECIFICALLY* for
the install media usage case.

Perhaps in the past we had an architecture that didn't fit, and this
NOMAN logic was added??  But it fits today.  Why are you assuming it
should be deleted by default in the install media?

Like wow, the install media scenario is the ONE PLACE embedded manuals
are useful!  If you aren't on the install media, you don't NEED the
embedded manuals, you can type ^Z man disklabel instead!


Klemens Nanni  wrote:

> Turns out all install media ship full copies of those two manuals due to
> what can be described like a makefile TOCTOU.
> 
> In /usr/src/distrib/special, Makefile.inc sets NOMAN=1 but */Makefile
> only includes it in the very end through .
> 
> fdisk and disklabel have NOMAN logic before that include, so they don't
> see it set yet and include the whole thing:
> 
>   $ make -C fdisk manual.o
>   mk -C fdisk manual.o
>   mandoc -Tascii 
> /usr/src/distrib/special/fdisk/../../../sbin/fdisk/fdisk.8 > fdisk.cat8
>   (echo 'const unsigned char manpage[] = {';  cat fdisk.cat8 | gzip -9c | 
> hexdump -ve '"0x" 1/1 "%02x,"';  echo '};'; echo 'const int manpage_sz = 
> sizeof(manpage);') > manual.c
>   cc -O2 -pipe  -DHAS_MBR -fno-pie -Oz -fno-stack-protector 
> -fno-unwind-tables -fno-asynchronous-unwind-tables -MD -MP  -c manual.c
>   $ size fdisk/obj/manual.o
>   textdatabss dec hex
>   35520   0   3552de0
> 
> Forcing it on the command line yields the desired behaviour:
>   $ make -C fdisk NOMAN=1 manual.o
>   (echo 'const unsigned char manpage[] = {';  echo 'no manual' | gzip -9c 
> | hexdump -ve '"0x" 1/1 "%02x,"';  echo '};'; echo 'const int manpage_sz = 
> sizeof(manpage);') > manual.c
>   cc -O2 -pipe  -DHAS_MBR -fno-pie -Oz -fno-stack-protector 
> -fno-unwind-tables -fno-asynchronous-unwind-tables -MD -MP  -c manual.c
>   $ size fdisk/obj/manual.o
>   textdatabss dec hex
>   36  0   0   36  24
> 
> Same for disklabel,  size before/after:
>   textdatabss dec hex
>   61600   0   61601810
>   36  0   0   36  24
> 
> I've confirmed this through an amd64 snapshots bsd.rd where I paged
> through disklabel(8) via the 'M' command...
> 
> Here's a minimal diff to highlight this non-obvious issue and avoid
> reshuffling, i.e. cut down on differences with /usr/src/sbin/*/Makefile.
> 
> Haven't built ramdisks yet to see the final size decrease, but everyone
> should be happy with this.
> 
> OK?
> 
> 
> Index: disklabel/Makefile
> ===
> RCS file: /cvs/src/distrib/special/disklabel/Makefile,v
> retrieving revision 1.13
> diff -u -p -r1.13 Makefile
> --- disklabel/Makefile21 Sep 2021 18:36:09 -  1.13
> +++ disklabel/Makefile25 Aug 2022 18:34:31 -
> @@ -10,6 +10,8 @@ CLEANFILES += disklabel.cat8 manual.c
>  
>  .include 
>  
> +# XXX set in ../Makefile.inc already but only pulled in by 
> +NOMAN = 1
>  .ifdef NOMAN
>  manual.c:
>   (echo 'const unsigned char manpage[] = {'; \
> Index: fdisk/Makefile
> ===
> RCS file: /cvs/src/distrib/special/fdisk/Makefile,v
> retrieving revision 1.6
> diff -u -p -r1.6 Makefile
> --- fdisk/Makefile23 May 2022 16:58:11 -  1.6
> +++ fdisk/Makefile25 Aug 2022 18:34:15 -
> @@ -23,6 +23,8 @@ CLEANFILES += fdisk.cat8 manual.c
>  
>  .include 
>  
> +# XXX set in ../Makefile.inc already but only pulled in by 
> +NOMAN = 1
>  .ifdef NOMAN
>  manual.c:
>   (echo 'const unsigned char manpage[] = {'; \
> 



Re: installboot: link dynamically

2022-08-25 Thread Theo de Raadt
Klemens Nanni  wrote:

> Dynamic installboot would be nice but I don't have strong opinoins about
> it, so best drop the diff and retain the chance to repair your system.

These are the static binaries:

./libexec/ld.so/ldconfig
obvious why

./sbin/dhcpleased
./sbin/iked
./sbin/isakmpd
./sbin/mountd
./sbin/nfsd
./sbin/pflogd
./sbin/resolvd
./sbin/slaacd
./sbin/unwind
I have a diff (in snapshots) which makes some of these dynamic,
for shared-libraries-more-secure reasons

./usr.bin/kdump
./usr.bin/ktrace

when these are dynamic, ld.so development/debugging becomes
very difficult

./usr.sbin/watchdogd
to try to remain locked in memory.  I'm not sure it works.  

./usr.sbin/chroot
strange reasons

and the boot block related things:

./sys/arch/alpha/stand/installboot
./sys/arch/alpha/stand/setnetbootinfo
./sys/arch/hppa/stand/mkboot
./usr.sbin/installboot



  1   2   3   4   5   6   7   8   9   10   >