[patch] macppc.html and sparc64.html old devices

[Bryan Vyhmeister]

I was just looking at macppc.html and noticed that lmc(4) was listed
along with art(4) as available WAN adapters and both were sent to the
bit bucket in the sky 13 months and 19 months ago respectively. I
checked the other platform pages and found lmc(4) also listed on
sparc64.html. Since we don't support any WAN adapters, remove the whole
section (the only other one was san(4) and it was also removed 13 months
ago).

Bryan


Index: www/macppc.html
===
RCS file: /cvs/www/macppc.html,v
retrieving revision 1.249
diff -u -p -r1.249 macppc.html
--- www/macppc.html 13 May 2016 21:10:56 -  1.249
+++ www/macppc.html 15 May 2016 03:57:05 -
@@ -295,12 +295,6 @@ to mailto:dm...@openbsd.org;>dm
 
 
 
-WAN Adapters
-
-Accoom Networks Artery T1/E1 WAN interfaces (http://man.openbsd.org/?query=artarch=macppcsektion=4;>art)
-SBE (formerly Lan Media Corporation) SSI (T1)/HSSI/DS1/DS3 WAN interfaces 
(http://man.openbsd.org/?query=lmcarch=macppcsektion=4;>lmc)
-
-
 SCSI and IDE Host Adapters
 
   "Old World" Macintosh on-board SCSI(http://man.openbsd.org/?query=mesharch=macppcsektion=4;>mesh)
Index: www/sparc64.html
===
RCS file: /cvs/www/sparc64.html,v
retrieving revision 1.378
diff -u -p -r1.378 sparc64.html
--- www/sparc64.html8 Apr 2016 01:58:04 -   1.378
+++ www/sparc64.html15 May 2016 03:57:05 -
@@ -417,10 +417,6 @@ XVR-1200)
TI ACX100/ACX111 IEEE 802.11a/b/g PCI adapters (http://man.openbsd.org/?query=acxarch=sparc64sektion=4;>acx)
WaveLAN/IEEE, PRISM 2-3, and Spectrum24 IEEE 802.11b PCMCIA/PCI/USB (http://man.openbsd.org/?query=wiarch=sparc64sektion=4;>wi)
   
- WAN Adapters
-  
-  SBE (formerly Lan Media Corporation) SSI (T1)/HSSI/DS1/DS3 WAN 
interfaces (http://man.openbsd.org/?query=lmcarch=sparc64sektion=4;>lmc)
-  
  Universal Serial Bus (USB) Devices
   
   USB Audio (http://man.openbsd.org/?query=uaudioarch=sparc64sektion=4;>uaudio)

Re: Is loss of read-only /usr permanent?

[lists]

Sat, 14 May 2016 12:25:47 -0400 RD Thrush 
> On 05/14/16 04:34, Craig Skinner wrote:
> > Hi RD/all,
> > 
> > On 2016-05-13 Fri 17:16 PM |, RD Thrush wrote:  
> >>
> >> # cp -p /etc/fstab /etc/fstab.orig
> >> # sed -e 's,/usr ffs rw,/usr ffs ro,' /etc/fstab
> >> # shutdown -f now
> >> Shutdown NOW!
> >> shutdown: [pid 82541]  
> > 
> > Something like this in /etc/rc might help here:
> > 
> > rebuildlibs() {
> > mount -d /usr | fgrep -wq ro && _ro_usr='true'
> > [[ -n ${_ro_usr} ]] && mount -u -o 'nordonly' /usr
> > 
> > ...
> > ..
> > [[ -n ${_ro_usr} ]] && mount -u -o 'rdonly' /usr
> > }
> > 
> > 
> > Let us know what works for you.  
> 
> Thanks, Craig.  That is much better than what I proposed [1].  I'll update my
> autoinstall accordingly.
> 
> [1]

Just don't file bug reports for the installer later, when something
moves and your incompatible changes resurface again to bite on your.

Re: Headers cleanup + use getprogname() for test(1)

[Philip Guenther]

On Sat, May 14, 2016 at 2:28 AM, Mark Kettenis  wrote:
>> Date: Sat, 14 May 2016 13:08:54 +0200
>> From: Frederic Cambus 
>>
>> Hi tech@,
>>
>> Headers cleanup + use getprogname() for test(1)
>
> *Never* include  directly.

+1

> And despite some of the noises guenther@ made recenly, I don't think
> we have made the decision to drop __progname in favour of
> getprogname().

Geez, can't a guy rest a bit after committing a 10k line diff?  :-)

On the point: I continue to think we should move this direction.


Philip Guenther

Re: Is loss of read-only /usr permanent?

[Kevin Chadwick]

> Finally, the read only file systems on a writable medium susceptible
> to all sorts of failure modes is a silly silly useless trick.  This
> does not provide any real technical benefit but your own discomfort.
> 

Pipe it down a bit will you. I use ro root, /dev in tmpfs and /usr ro
as well as any partition where writes do not happen at any time. It is
called defence in depth. Consider a potential bug in tar when run as
root, damaged /usr or / is easily fixed with OpenBSD (one of it's ace
cards) but I have been saved time by ro root before, though I forget the
details and probably just a testing system. When considering doas,
etc., I believe a ro mount to be far simpler than DACs even if they are
well tested. It is also quite reassuring to see clean clean clean clean
after a power failure. Of course a hard drive head could have crashed
onto that area, but very unlikely and I'm not sure fsck would catch
that anyway.

UPS do fail too btw. I had to rip some cheap APC ones out because
they caused more downtime than they saved!

> 
> Except just this time now, when your self managing became a bug report,
> which is not a bug, and you insisted on your way of having it reported.
> 
> Now admit it, you support yourself when you make incompatible changes.

Which is fair enough but has already been said.

-- 

KISSIS - Keep It Simple So It's Securable

Re: Is loss of read-only /usr permanent?

[lists]

Sat, 14 May 2016 12:24:50 -0400 RD Thrush 
> On 05/13/16 23:34, Theo de Raadt wrote:
> >> The report is fairly easy to reproduce.  Make the /usr filesystem
> >> read-only in /etc/fstab, go to single user mode and exit back to
> >> multi-user.  I've appended a transcript.  
> > 
> > This does not matter.  It is your configuration.  It is not the default.
> > 
> > Can you make /usr readonly on 90% of other operating systems, without
> > downsides?  Then switch.  The reality is that you can't, since it is
> > your own brave configuration choice.  You own it.
> >   
> >> It's unfortunate that mounting /usr read-only is now a mis-configuration.  
> > 
> > It was never a valid configuration.  Next up, you will ask for readonly
> > /etc.  Or readonly /var.  Or readonly something.  Or operation without
> > half the files that are in /etc.  Who knows.
> > 
> > It is your change --> you own it.  
> 
> I have nothing but praise for the related security improvement as well as 
> countless others that influenced my choice of OpenBSD since 2.6. I have 
> upgraded 100s of times with /usr{,/X11R*,/local} as ro in /etc/fstab.  I made 
> the 'bugs' report including a diff [1] two weeks ago when I noticed the 
> conflict after a -current upgrade.

Look, you don't have to make it public, that you make changes your end.

You don't have to make requests that everyone gets a change because of
how you choose to use the system.  And you don't have to insist you're
doing what's appropriate for others, because you don't choose correct.

Finally, the read only file systems on a writable medium susceptible
to all sorts of failure modes is a silly silly useless trick.  This
does not provide any real technical benefit but your own discomfort.

> After no response, I asked again and unintentionally triggered angry 
> responses, although 2 good suggestions emerged.

Yes, one was don't deviate from the default in this respect, and the
other was, obviously, you're on your own with that change, you own it.

> Edgar Pettijohn [2] suggested adding the mount -ur ... commands to 
> /etc/rc.local which works but may warrant a note when [3] is created.
> 
> Craig Skinner [4] greatly improved my diff. 
> 
> I've been managing the read-only /usr partitions since the change w/ a custom 
> autoinstall.
> 
> [1]
> [2]
> [3]
> [4]

Except just this time now, when your self managing became a bug report,
which is not a bug, and you insisted on your way of having it reported.

Now admit it, you support yourself when you make incompatible changes.

Re: Is loss of read-only /usr permanent?

[Theo de Raadt]

> Thanks, that would work fine.  It may be useful as a note in the upgrade guide
> for 6.0 for those (apparently few of us) who have a read-only /usr.

The documentation describes the system as it is shipped.

It does not spend hundreds of pages satisfying tweakers.
 

Re: Is loss of read-only /usr permanent?

[RD Thrush]

On 05/13/16 19:37, Edgar Pettijohn wrote:
>> On May 13, 2016, at 4:16 PM, RD Thrush  wrote:
>>
>> On 05/13/16 11:07, Theo de Raadt wrote:
 Since the anti-ROP mechanism in libc [2] was added in late April, -current 
 with read-only /usr produces something like the following message:
 re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file 
 system
>>>
>>> Look, your statement is false.  I can install a snapshot right now,
>>> and I won't see what you report.
>>
>> The report is fairly easy to reproduce.  Make the /usr filesystem read-only 
>> in /etc/fstab, go to single user mode and exit back to multi-user.  I've 
>> appended a transcript.
>>
>>> That is the result of a mis-configuration on your part.
>>
>> It's unfortunate that mounting /usr read-only is now a mis-configuration.
>>
 I thought I was following best practice by mounting /usr,
 /usr/X11R6, and /usr/local read-only.  I submitted a bug report and a
 patch to fix my problem [2] but have had no response.
>>>
>>> That is not best practice.  If it was, we would be heading towards
>>> making it the default.
>>>
>>> And why is not best practice? Because it stands directly against the
>>> primary purpose of OpenBSD: A development platform, where people
>>> constantly rebuild their binaries, iterating and fixing bugs.
>>>
>>> What you are describing here is really just "you make a local change,
>>> you own it".
>>
>> [ ... snip ... ]
> 
> Why not just put the appropriate mount command in /etc/rc.local?

Thanks, that would work fine.  It may be useful as a note in the upgrade guide
for 6.0 for those (apparently few of us) who have a read-only /usr.

Re: Is loss of read-only /usr permanent?

[RD Thrush]

On 05/13/16 23:34, Theo de Raadt wrote:
>> The report is fairly easy to reproduce.  Make the /usr filesystem
>> read-only in /etc/fstab, go to single user mode and exit back to
>> multi-user.  I've appended a transcript.
> 
> This does not matter.  It is your configuration.  It is not the default.
> 
> Can you make /usr readonly on 90% of other operating systems, without
> downsides?  Then switch.  The reality is that you can't, since it is
> your own brave configuration choice.  You own it.
> 
>> It's unfortunate that mounting /usr read-only is now a mis-configuration.
> 
> It was never a valid configuration.  Next up, you will ask for readonly
> /etc.  Or readonly /var.  Or readonly something.  Or operation without
> half the files that are in /etc.  Who knows.
> 
> It is your change --> you own it.

I have nothing but praise for the related security improvement as well as 
countless others that influenced my choice of OpenBSD since 2.6. I have 
upgraded 100s of times with /usr{,/X11R*,/local} as ro in /etc/fstab.  I made 
the 'bugs' report including a diff [1] two weeks ago when I noticed the 
conflict after a -current upgrade.

After no response, I asked again and unintentionally triggered angry responses, 
although 2 good suggestions emerged.

Edgar Pettijohn [2] suggested adding the mount -ur ... commands to 
/etc/rc.local which works but may warrant a note when [3] is created.

Craig Skinner [4] greatly improved my diff. 

I've been managing the read-only /usr partitions since the change w/ a custom 
autoinstall.

[1]
[2]
[3]
[4]

Re: Is loss of read-only /usr permanent?

[RD Thrush]

On 05/13/16 19:40, Chris Cappuccio wrote:
> RD Thrush [openbsd-t...@thrush.com] wrote:
>> On 05/13/16 11:07, Theo de Raadt wrote:
 Since the anti-ROP mechanism in libc [2] was added in late April, -current 
 with read-only /usr produces something like the following message:
 re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file 
 system
>>>
>>> Look, your statement is false.  I can install a snapshot right now,
>>> and I won't see what you report.
>>
>> The report is fairly easy to reproduce.  Make the /usr filesystem read-only 
>> in /etc/fstab, go to single user mode and exit back to multi-user.  I've 
>> appended a transcript.
>>
>>> That is the result of a mis-configuration on your part.
>>
>> It's unfortunate that mounting /usr read-only is now a mis-configuration.
>>
> 
> Robert, what do you suggest?
> 
> 1. Say sorry, no mitigation because we want to support all possible
> configurations
> 
> 2. Say OK, and provide a work-around in /etc/rc that might (or might not)
> work with your situation, and makes the overall situation more complicated
> for everyone
> 
> 3. Say sorry, the mitigation technique will not be changed. You are on your
> own.
> 
> I think it comes down to this. If you want read-only /etc, you'll have to
> modify /etc/rc, if you still want the mitigation.

Thanks, Chris.  I provided a diff in my original bugs report.  Craig Skinner
enhanced it and I'll update my autoinstall accordingly.

I didn't mention read-only /etc.  Not sure where that came from.

Re: Is loss of read-only /usr permanent?

[RD Thrush]

On 05/14/16 04:34, Craig Skinner wrote:
> Hi RD/all,
> 
> On 2016-05-13 Fri 17:16 PM |, RD Thrush wrote:
>>
>> # cp -p /etc/fstab /etc/fstab.orig
>> # sed -e 's,/usr ffs rw,/usr ffs ro,' /etc/fstab
>> # shutdown -f now
>> Shutdown NOW!
>> shutdown: [pid 82541]
> 
> Something like this in /etc/rc might help here:
> 
> rebuildlibs() {
>   mount -d /usr | fgrep -wq ro && _ro_usr='true'
>   [[ -n ${_ro_usr} ]] && mount -u -o 'nordonly' /usr
>   
>   ...
>   ..
>   [[ -n ${_ro_usr} ]] && mount -u -o 'rdonly' /usr
> }
> 
> 
> Let us know what works for you.

Thanks, Craig.  That is much better than what I proposed [1].  I'll update my
autoinstall accordingly.

[1]

Re: opendev and pledge: "privsep" for dumpfs(8)

[Theo de Raadt]

> > Must say the forking and piping seems to be a bit silly for a program
> > like this.  Certainly adds alot of complexity.  Why not simply call
> > opendev up front for each filesystem, creating a list of names and
> > filedescriptors before you pledge, and then iterate over that list
> > afterwards?
> > 
> > KISS
> 
> I don't think that is a simple refactoring.
> 
> And, file descriptor limits.
> 
> The other option is to not pledge.  But the pledge has a real purpose
> here, to protect the program against hostile input from the disk.
> dumpfs(8) is similar to file(1), a program one runs to make sure
> something you got isn't hostile.  Same reason I added pledge to fsck
> and family.
> 
> Oddly, the synopsis for dumpfs does not say it supports multiple optarg.

cd /dev
ktrace dumpfs * > /dev/null
kdump | grep ' open' | grep CALL | wc -l
1186

Meanwhile, the default for root is

openfiles   128 

Yes a bit silly.  But I don't think substantial resource preallocation
is the answer here.

Re: opendev and pledge: "privsep" for dumpfs(8)

[Theo de Raadt]

> Must say the forking and piping seems to be a bit silly for a program
> like this.  Certainly adds alot of complexity.  Why not simply call
> opendev up front for each filesystem, creating a list of names and
> filedescriptors before you pledge, and then iterate over that list
> afterwards?
> 
> KISS

I don't think that is a simple refactoring.

And, file descriptor limits.

The other option is to not pledge.  But the pledge has a real purpose
here, to protect the program against hostile input from the disk.
dumpfs(8) is similar to file(1), a program one runs to make sure
something you got isn't hostile.  Same reason I added pledge to fsck
and family.

Oddly, the synopsis for dumpfs does not say it supports multiple optarg.

Re: opendev and pledge: "privsep" for dumpfs(8)

[Mark Kettenis]

> Date: Sat, 14 May 2016 17:07:45 +0200
> From: Theo Buehler 
> 
> Here's a new version with lots of help and input from semarie, thanks!
> Besides lots of small tweaks, the main improvements are:
> 
> * fork one pledged child per fs which reads the data.
> * pipe the data to the unpledged parent that dumps it to stdout.
> * parent waits for current child, then calls opendev(2) for next child.
> * make sure parent reports properly on child failure (e.g. pledge abort)

Must say the forking and piping seems to be a bit silly for a program
like this.  Certainly adds alot of complexity.  Why not simply call
opendev up front for each filesystem, creating a list of names and
filedescriptors before you pledge, and then iterate over that list
afterwards?

KISS

> Index: sbin/dumpfs/dumpfs.c
> ===
> RCS file: /var/cvs/src/sbin/dumpfs/dumpfs.c,v
> retrieving revision 1.33
> diff -u -p -r1.33 dumpfs.c
> --- sbin/dumpfs/dumpfs.c  23 Nov 2015 19:19:29 -  1.33
> +++ sbin/dumpfs/dumpfs.c  14 May 2016 15:02:24 -
> @@ -40,6 +40,7 @@
>  
>  #include/* DEV_BSIZE MAXBSIZE isset */
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -51,6 +52,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -73,6 +75,7 @@ int dumpcg(const char *, int, int);
>  int  marshal(const char *);
>  int  open_disk(const char *);
>  void pbits(void *, int);
> +void writedata(int, int);
>  __dead void  usage(void);
>  
>  int
> @@ -80,7 +83,9 @@ main(int argc, char *argv[])
>  {
>   struct fstab *fs;
>   const char *name;
> - int ch, domarshal, eval, fd;
> + pid_t pid, wpid;
> + int p[2];
> + int ch, domarshal, eval, fd, pstat;
>  
>   domarshal = eval = 0;
>  
> @@ -100,25 +105,69 @@ main(int argc, char *argv[])
>   if (argc < 1)
>   usage();
>  
> - if (pledge("stdio rpath disklabel", NULL) == -1)
> - err(1, "pledge");
> -
>   for (; *argv != NULL; argv++) {
>   if ((fs = getfsfile(*argv)) != NULL)
>   name = fs->fs_spec;
>   else
>   name = *argv;
> +
>   if ((fd = open_disk(name)) == -1) {
>   eval |= 1;
>   continue;
>   }
> - if (domarshal)
> - eval |= marshal(name);
> - else
> - eval |= dumpfs(fd, name);
> - close(fd);
> +
> + if (pipe(p) < 0)
> + err(1, "pipe");
> +
> + switch(pid = fork()) {
> + case -1:
> + err(1, "fork");
> +
> + case 0:
> + if (pledge("stdio", NULL) == -1)
> + err(1, "pledge");
> +
> + close(p[0]);
> + dup2(p[1], STDOUT_FILENO);
> + close(p[1]);
> +
> + if (domarshal)
> + eval |= marshal(name);
> + else
> + eval |= dumpfs(fd, name);
> +
> + close(fd);
> +
> + if (fflush(stdout))
> + err(1, "fflush");
> +
> + _exit(eval);
> +
> + default:
> + close(p[1]);
> + writedata(p[0], STDOUT_FILENO);
> + close(p[0]);
> + close(fd);
> +
> + do {
> + wpid = waitpid(pid, , 0);
> + } while (wpid == -1 && errno == EINTR);
> +
> + if (wpid == -1) {
> + warn("waitpid");
> + eval |= 1;
> + } else if (WIFEXITED(pstat))
> + eval |= WEXITSTATUS(pstat);
> + else if (WIFSIGNALED(pstat)) {
> + warnx("child processing %s terminated: %s%s",
> + name, strsignal(WTERMSIG(pstat)),
> + WCOREDUMP(pstat) ? " (core dumped)" : "");
> + eval |= 1;
> + }
> + }
>   }
> - exit(eval);
> +
> + return (eval);
>  }
>  
>  int
> @@ -458,6 +507,23 @@ pbits(void *vp, int max)
>   printf("-%d", i);
>   }
>   printf("\n");
> +}
> +
> +void
> +writedata(int ifd, int ofd)
> +{
> + int nr, nw, off;
> + char buf[1024];
> + 
> + while ((nr = read(ifd, buf, sizeof(buf))) != -1 && nr != 0) {
> + for (off = 0; nr; nr -= nw, off += nw) {
> + if ((nw = write(ofd, buf + off, nr)) == 0 || nw == -1)
> + err(1, "write");
> + }
> + }
> +
> + if (nr < 0)
> + warn("read");
>  }
>  
>  

Re: opendev and pledge: "privsep" for dumpfs(8)

[Theo Buehler]

Here's a new version with lots of help and input from semarie, thanks!
Besides lots of small tweaks, the main improvements are:

* fork one pledged child per fs which reads the data.
* pipe the data to the unpledged parent that dumps it to stdout.
* parent waits for current child, then calls opendev(2) for next child.
* make sure parent reports properly on child failure (e.g. pledge abort)

Index: sbin/dumpfs/dumpfs.c
===
RCS file: /var/cvs/src/sbin/dumpfs/dumpfs.c,v
retrieving revision 1.33
diff -u -p -r1.33 dumpfs.c
--- sbin/dumpfs/dumpfs.c23 Nov 2015 19:19:29 -  1.33
+++ sbin/dumpfs/dumpfs.c14 May 2016 15:02:24 -
@@ -40,6 +40,7 @@
 
 #include  /* DEV_BSIZE MAXBSIZE isset */
 #include 
+#include 
 
 #include 
 #include 
@@ -51,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -73,6 +75,7 @@ int   dumpcg(const char *, int, int);
 intmarshal(const char *);
 intopen_disk(const char *);
 void   pbits(void *, int);
+void   writedata(int, int);
 __dead voidusage(void);
 
 int
@@ -80,7 +83,9 @@ main(int argc, char *argv[])
 {
struct fstab *fs;
const char *name;
-   int ch, domarshal, eval, fd;
+   pid_t pid, wpid;
+   int p[2];
+   int ch, domarshal, eval, fd, pstat;
 
domarshal = eval = 0;
 
@@ -100,25 +105,69 @@ main(int argc, char *argv[])
if (argc < 1)
usage();
 
-   if (pledge("stdio rpath disklabel", NULL) == -1)
-   err(1, "pledge");
-
for (; *argv != NULL; argv++) {
if ((fs = getfsfile(*argv)) != NULL)
name = fs->fs_spec;
else
name = *argv;
+
if ((fd = open_disk(name)) == -1) {
eval |= 1;
continue;
}
-   if (domarshal)
-   eval |= marshal(name);
-   else
-   eval |= dumpfs(fd, name);
-   close(fd);
+
+   if (pipe(p) < 0)
+   err(1, "pipe");
+
+   switch(pid = fork()) {
+   case -1:
+   err(1, "fork");
+
+   case 0:
+   if (pledge("stdio", NULL) == -1)
+   err(1, "pledge");
+
+   close(p[0]);
+   dup2(p[1], STDOUT_FILENO);
+   close(p[1]);
+
+   if (domarshal)
+   eval |= marshal(name);
+   else
+   eval |= dumpfs(fd, name);
+
+   close(fd);
+
+   if (fflush(stdout))
+   err(1, "fflush");
+
+   _exit(eval);
+
+   default:
+   close(p[1]);
+   writedata(p[0], STDOUT_FILENO);
+   close(p[0]);
+   close(fd);
+
+   do {
+   wpid = waitpid(pid, , 0);
+   } while (wpid == -1 && errno == EINTR);
+
+   if (wpid == -1) {
+   warn("waitpid");
+   eval |= 1;
+   } else if (WIFEXITED(pstat))
+   eval |= WEXITSTATUS(pstat);
+   else if (WIFSIGNALED(pstat)) {
+   warnx("child processing %s terminated: %s%s",
+   name, strsignal(WTERMSIG(pstat)),
+   WCOREDUMP(pstat) ? " (core dumped)" : "");
+   eval |= 1;
+   }
+   }
}
-   exit(eval);
+
+   return (eval);
 }
 
 int
@@ -458,6 +507,23 @@ pbits(void *vp, int max)
printf("-%d", i);
}
printf("\n");
+}
+
+void
+writedata(int ifd, int ofd)
+{
+   int nr, nw, off;
+   char buf[1024];
+   
+   while ((nr = read(ifd, buf, sizeof(buf))) != -1 && nr != 0) {
+   for (off = 0; nr; nr -= nw, off += nw) {
+   if ((nw = write(ofd, buf + off, nr)) == 0 || nw == -1)
+   err(1, "write");
+   }
+   }
+
+   if (nr < 0)
+   warn("read");
 }
 
 __dead void

wsmouse_input: hidms, pms

[Ulf Brosziewski]

The new input-processing functions of wsmouse seem to work well
for touchpads, and it might be time to update the mouse drivers
now. I start with the two drivers that I could test myself, hidms
(ums) and pms.

Please note that hidms can mix, in principle, absolute and relative
coordinates. The new version doesn't change this property. I don't
know whether it is really necessary.

OK?


Index: dev/hid/hidms.c
===
RCS file: /cvs/src/sys/dev/hid/hidms.c,v
retrieving revision 1.2
diff -u -p -r1.2 hidms.c
--- dev/hid/hidms.c 10 Feb 2016 05:49:50 -  1.2
+++ dev/hid/hidms.c 14 May 2016 13:47:06 -
@@ -331,7 +331,6 @@ hidms_input(struct hidms *ms, uint8_t *d
 {
int dx, dy, dz, dw;
u_int32_t buttons = 0;
-   int flags;
int i, s;
 
DPRINTFN(5,("hidms_input: len=%d\n", len));
@@ -358,12 +357,6 @@ hidms_input(struct hidms *ms, uint8_t *d
return;
}
 
-   flags = WSMOUSE_INPUT_DELTA;
-   if (ms->sc_flags & HIDMS_ABSX)
-   flags |= WSMOUSE_INPUT_ABSOLUTE_X;
-   if (ms->sc_flags & HIDMS_ABSY)
-   flags |= WSMOUSE_INPUT_ABSOLUTE_Y;
-
dx =  hid_get_data(data, len, >sc_loc_x);
dy = -hid_get_data(data, len, >sc_loc_y);
dz =  hid_get_data(data, len, >sc_loc_z);
@@ -403,8 +396,18 @@ hidms_input(struct hidms *ms, uint8_t *d
ms->sc_buttons = buttons;
if (ms->sc_wsmousedev != NULL) {
s = spltty();
-   wsmouse_input(ms->sc_wsmousedev, buttons,
-   dx, dy, dz, dw, flags);
+   if (ms->sc_flags & HIDMS_ABSX) {
+   wsmouse_set(ms->sc_wsmousedev,
+   WSMOUSE_ABS_X, dx, 0);
+   dx = 0;
+   }
+   if (ms->sc_flags & HIDMS_ABSY) {
+   wsmouse_set(ms->sc_wsmousedev,
+   WSMOUSE_ABS_Y, dy, 0);
+   dy = 0;
+   }
+   WSMOUSE_INPUT(ms->sc_wsmousedev,
+   buttons, dx, dy, dz, dw);
splx(s);
}
}
Index: dev/pckbc/pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.69
diff -u -p -r1.69 pms.c
--- dev/pckbc/pms.c 30 Mar 2016 23:34:12 -  1.69
+++ dev/pckbc/pms.c 14 May 2016 13:47:06 -
@@ -632,8 +632,7 @@ pms_proc_mouse(struct pms_softc *sc)
else
dz = 0;
 
-   wsmouse_input(sc->sc_wsmousedev,
-   buttons, dx, dy, dz, 0, WSMOUSE_INPUT_DELTA);
+   WSMOUSE_INPUT(sc->sc_wsmousedev, buttons, dx, dy, dz, 0);
 }
 
 int

Re: Is loss of read-only /usr permanent?

[lists]

Fri, 13 May 2016 17:16:19 -0400 RD Thrush 
> On 05/13/16 11:07, Theo de Raadt wrote:
> >> Since the anti-ROP mechanism in libc [2] was added in late April, -current 
> >> with read-only /usr produces something like the following message:
> >> re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file 
> >> system  
> > 
> > Look, your statement is false.  I can install a snapshot right now,
> > and I won't see what you report.  
> 
> The report is fairly easy to reproduce.  Make the /usr filesystem read-only 
> in /etc/fstab, go to single user mode and exit back to multi-user.  I've 
> appended a transcript.

Then don't do what you report and it won't happen, it's like putting a
stick in your feet and complaining you nose dive roughly reproducible.

> > That is the result of a mis-configuration on your part.  
> 
> It's unfortunate that mounting /usr read-only is now a mis-configuration.

Yes, unlucky to be you having to do it and file a report that you did.

> >> I thought I was following best practice by mounting /usr,
> >> /usr/X11R6, and /usr/local read-only.  I submitted a bug report and a
> >> patch to fix my problem [2] but have had no response.  
> > 
> > That is not best practice.  If it was, we would be heading towards
> > making it the default.
> > 
> > And why is not best practice? Because it stands directly against the
> > primary purpose of OpenBSD: A development platform, where people
> > constantly rebuild their binaries, iterating and fixing bugs.
> > 
> > What you are describing here is really just "you make a local change,
> > you own it".

Re: Is loss of read-only /usr permanent?

[lists]

Fri, 13 May 2016 18:55:58 -0500 Chris Bennett

> I think you are totally missing the point that Theo just made.

You too.

> Marking partitions as read-only is useful, when and only when
> appropriate.

Expand on a wrong idea does not make it right.  Your advice is hurting
naive readers.  This thread is the result of a user error gone public.

> Why, because when the power fails, no data is lost and I'm quickly back
> up with minimal fsck'ing.

Obvious design error: you did not include uninterrupted power supply.
File system check is fast and safe even when power fails.  Still you
have a system reliability omission.  Consider a power unit next time.

> This has saved my ass twice now.

By hurting you in the long run, useless trick.

> Backup your data

After you have reliable power and learn a lot more on system design.

Use proper bool types in /usr/games

[Frederic Cambus]

Hi tech@,

Proper bool types for fortune(6) and monop(6).

Index: games/fortune/fortune/fortune.c
===
RCS file: /cvs/src/games/fortune/fortune/fortune.c,v
retrieving revision 1.55
diff -u -p -r1.55 fortune.c
--- games/fortune/fortune/fortune.c 7 Mar 2016 22:49:45 -   1.55
+++ games/fortune/fortune/fortune.c 14 May 2016 10:19:21 -
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -49,8 +50,6 @@
 
 #include "pathnames.h"
 #include "strfile.h"
-
-#defineboolshort
 
 #defineMINW6   /* minimum wait if desired */
 #defineCPERS   20  /* # of chars for each sec */
Index: games/monop/deck.h
===
RCS file: /cvs/src/games/monop/deck.h,v
retrieving revision 1.6
diff -u -p -r1.6 deck.h
--- games/monop/deck.h  8 Jan 2016 18:19:47 -   1.6
+++ games/monop/deck.h  14 May 2016 10:19:21 -
@@ -32,7 +32,7 @@
  * @(#)deck.h  8.1 (Berkeley) 5/31/93
  */
 
-#defineboolint8_t
+#include 
 
 #defineCC_Ddeck[0]
 #defineCH_Ddeck[1]
Index: games/monop/initdeck.c
===
RCS file: /cvs/src/games/monop/initdeck.c,v
retrieving revision 1.17
diff -u -p -r1.17 initdeck.c
--- games/monop/initdeck.c  8 Jan 2016 18:20:33 -   1.17
+++ games/monop/initdeck.c  14 May 2016 10:19:21 -
@@ -51,8 +51,6 @@
 #defineTRUE1
 #defineFALSE   0
 
-#defineboolint8_t
-
 char   *infile = "cards.inp",  /* input file   */
*outfile= "cards.pck";  /* "packed" file*/
 
Index: games/monop/monop.h
===
RCS file: /cvs/src/games/monop/monop.h,v
retrieving revision 1.8
diff -u -p -r1.8 monop.h
--- games/monop/monop.h 8 Jan 2016 18:19:47 -   1.8
+++ games/monop/monop.h 14 May 2016 10:19:21 -
@@ -37,7 +37,6 @@
 #else
 #defineshrtchar
 #endif
-#defineboolint8_t
 
 #defineTRUE(1)
 #defineFALSE   (0)

Re: Headers cleanup + use getprogname() for test(1)

[Mark Kettenis]

> Date: Sat, 14 May 2016 13:08:54 +0200
> From: Frederic Cambus 
> 
> Hi tech@,
> 
> Headers cleanup + use getprogname() for test(1)

*Never* include  directly.

And despite some of the noises guenther@ made recenly, I don't think
we have made the decision to drop __progname in favour of
getprogname().

> Index: bin/test/test.c
> ===
> RCS file: /cvs/src/bin/test/test.c,v
> retrieving revision 1.16
> diff -u -p -r1.16 test.c
> --- bin/test/test.c   13 Jan 2016 13:13:04 -  1.16
> +++ bin/test/test.c   14 May 2016 09:06:33 -
> @@ -11,7 +11,7 @@
>   * This program is in the Public Domain.
>   */
>  
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -155,13 +155,12 @@ static void syntax(const char *op, char 
>  int
>  main(int argc, char *argv[])
>  {
> - extern char *__progname;
>   int res;
>  
>   if (pledge("stdio rpath", NULL) == -1)
>   err(2, "pledge");
>  
> - if (strcmp(__progname, "[") == 0) {
> + if (strcmp(getprogname(), "[") == 0) {
>   if (strcmp(argv[--argc], "]"))
>   errx(2, "missing ]");
>   argv[argc] = NULL;
> 
> 

Headers cleanup + use getprogname() for test(1)

[Frederic Cambus]

Hi tech@,

Headers cleanup + use getprogname() for test(1)

Index: bin/test/test.c
===
RCS file: /cvs/src/bin/test/test.c,v
retrieving revision 1.16
diff -u -p -r1.16 test.c
--- bin/test/test.c 13 Jan 2016 13:13:04 -  1.16
+++ bin/test/test.c 14 May 2016 09:06:33 -
@@ -11,7 +11,7 @@
  * This program is in the Public Domain.
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -155,13 +155,12 @@ static void syntax(const char *op, char 
 int
 main(int argc, char *argv[])
 {
-   extern char *__progname;
int res;
 
if (pledge("stdio rpath", NULL) == -1)
err(2, "pledge");
 
-   if (strcmp(__progname, "[") == 0) {
+   if (strcmp(getprogname(), "[") == 0) {
if (strcmp(argv[--argc], "]"))
errx(2, "missing ]");
argv[argc] = NULL;

Re: Is loss of read-only /usr permanent?

[Craig Skinner]

Hi RD/all,

On 2016-05-13 Fri 17:16 PM |, RD Thrush wrote:
> 
> # cp -p /etc/fstab /etc/fstab.orig
> # sed -e 's,/usr ffs rw,/usr ffs ro,' /etc/fstab
> # shutdown -f now
> Shutdown NOW!
> shutdown: [pid 82541]

Something like this in /etc/rc might help here:

rebuildlibs() {
mount -d /usr | fgrep -wq ro && _ro_usr='true'
[[ -n ${_ro_usr} ]] && mount -u -o 'nordonly' /usr

...
..
[[ -n ${_ro_usr} ]] && mount -u -o 'rdonly' /usr
}


Let us know what works for you.

Thanks!
-- 
Paranoia doesn't mean the whole world isn't out to get you.