Re: add lld manual page

[Jason McIntyre]

On Thu, Mar 01, 2018 at 06:15:59PM +1100, Jonathan Gray wrote:
> From lld svn rev 324739 with -z muldefs and -z retpolineplt text removed
> to match lld 5.0.1.
> 

morning.

this will replace the ld page for archs building llvm, right? haven;t
the stomach to read it yet, but no objections. you should probably add
an Nm entry to NAME for "ld" though:

.Sh NAME
.Nm ld.lld ,
.Nm ld

also don;t know if you tag this stuff $OpenBSD$ or not.

jmc

> Index: usr.bin/clang/lld/Makefile
> ===
> RCS file: /cvs/src/gnu/usr.bin/clang/lld/Makefile,v
> retrieving revision 1.11
> diff -u -p -r1.11 Makefile
> --- usr.bin/clang/lld/Makefile4 Oct 2017 20:57:10 -   1.11
> +++ usr.bin/clang/lld/Makefile1 Mar 2018 05:50:09 -
> @@ -5,17 +5,18 @@
>  PROG=ld.lld
>  BINDIR=  /usr/bin
>  SRCS=lld.cpp
> -NOMAN=
>  
>  TARGET_ARCH?=${MACHINE_ARCH}
>  .if ${TARGET_ARCH} == "aarch64"
>  LINKS=   ${BINDIR}/ld.lld ${BINDIR}/ld
> +MLINKS=  ld.lld.1 ld.1
>  .endif
>  
>  CPPFLAGS+=   ${CLANG_INCLUDES}
>  CPPFLAGS+=   -I${.CURDIR}/../../../llvm/tools/lld/include
>  
>  .PATH:   ${.CURDIR}/../../../llvm/tools/lld/tools/lld
> +.PATH:   ${.CURDIR}/../../../llvm/tools/lld/docs
>  
>  LLVM_LIBDEPS=lldELF \
>   lldConfig \
> Index: llvm/tools/lld/docs/ld.lld.1
> ===
> RCS file: llvm/tools/lld/docs/ld.lld.1
> diff -N llvm/tools/lld/docs/ld.lld.1
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ llvm/tools/lld/docs/ld.lld.1  1 Mar 2018 05:23:10 -
> @@ -0,0 +1,518 @@
> +.\" This file is distributed under the University of Illinois Open Source
> +.\" License. See LICENSE.TXT for details.
> +.\"
> +.\" This man page documents only lld's ELF linking support, obtained 
> originally
> +.\" from FreeBSD.
> +.Dd February 9, 2018
> +.Dt LD.LLD 1
> +.Os
> +.Sh NAME
> +.Nm ld.lld
> +.Nd ELF linker from the LLVM project
> +.Sh SYNOPSIS
> +.Nm ld.lld
> +.Op Ar options
> +.Ar objfile ...
> +.Sh DESCRIPTION
> +A linker takes one or more object, archive, and library files, and combines
> +them into an output file (an executable, a shared library, or another object
> +file).
> +It relocates code and data from the input files and resolves symbol
> +references between them.
> +.Pp
> +.Nm
> +is a drop-in replacement for the GNU BFD and gold linkers.
> +It accepts most of the same command line arguments and linker scripts
> +as GNU linkers.
> +.Pp
> +These options are available:
> +.Bl -tag -width indent
> +.It Fl -allow-multiple-definition
> +Do not error if a symbol is defined multiple times.
> +The first definition will be used.
> +.It Fl -as-needed
> +Only set
> +.Dv DT_NEEDED
> +for shared libraries if used.
> +.It Fl -auxiliary Ar value
> +Set the
> +.Dv DT_AUXILIARY
> +field to the specified name.
> +.It Fl -Bdynamic
> +Link against shared libraries.
> +.It Fl -Bstatic
> +Do not link against shared libraries.
> +.It Fl -Bsymbolic-functions
> +Bind defined function symbols locally.
> +.It Fl -Bsymbolic
> +Bind defined symbols locally.
> +.It Fl -build-id= Ns Ar value
> +Generate a build ID note.
> +.Ar value
> +may be one of
> +.Cm fast ,
> +.Cm md5 ,
> +.Cm sha1 ,
> +.Cm tree ,
> +.Cm uuid ,
> +.Cm 0x Ns Ar hex-string ,
> +and
> +.Cm none .
> +.Cm tree
> +is an alias for
> +.Cm sha1 .
> +Build-IDs of type
> +.Cm fast ,
> +.Cm md5 ,
> +.Cm sha1 ,
> +and
> +.Cm tree
> +are calculated from the object contents.
> +.Cm fast
> +is not intended to be cryptographically secure.
> +.It Fl -build-id
> +Synonym for
> +.Fl -build-id= Ns Cm fast .
> +.It Fl -color-diagnostics= Ns Ar value
> +Use colors in diagnostics.
> +.Ar value
> +may be one of
> +.Cm always ,
> +.Cm auto ,
> +and
> +.Cm never .
> +.Cm auto
> +enables color if and only if output is to a terminal.
> +.It Fl -color-diagnostics
> +Alias for
> +.Fl -color-diagnostics= Ns Cm auto .
> +.It Fl -compress-debug-sections= Ns Ar value
> +Compress DWARF debug sections.
> +.Ar value
> +may be
> +.Cm none
> +or
> +.Cm zlib .
> +.It Fl -define-common
> +Assign space to common symbols.
> +.It Fl -defsym= Ns Ar symbol= Ns Ar expression
> +Define a symbol alias.
> +.Ar expression
> +may be another symbol or a linker script expression.
> +For example,
> +.Fl -defsym= Ns Cm foo= Ns Cm bar
> +or
> +.Fl -defsym= Ns Cm foo= Ns Cm bar+0x100 .
> +.It Fl -demangle
> +Demangle symbol names.
> +.It Fl -disable-new-dtags
> +Disable new dynamic tags.
> +.It Fl -discard-all
> +Delete all local symbols.
> +.It Fl -discard-locals
> +Delete temporary local symbols.
> +.It Fl -discard-none
> +Keep all symbols in the symbol table.
> +.It Fl -dynamic-linker Ar value
> +Specify the dynamic linker to be used for a dynamically linked executable.
> +This is recorded in an ELF segment of type
> +.Dv PT_INTERP .
> +.It Fl -dynamic-list Ar file
> +Read a list of dynamic symbols from
> +.Ar file .
> +.It 

add lld manual page

[Jonathan Gray]

>From lld svn rev 324739 with -z muldefs and -z retpolineplt text removed
to match lld 5.0.1.

Index: usr.bin/clang/lld/Makefile
===
RCS file: /cvs/src/gnu/usr.bin/clang/lld/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- usr.bin/clang/lld/Makefile  4 Oct 2017 20:57:10 -   1.11
+++ usr.bin/clang/lld/Makefile  1 Mar 2018 05:50:09 -
@@ -5,17 +5,18 @@
 PROG=  ld.lld
 BINDIR=/usr/bin
 SRCS=  lld.cpp
-NOMAN=
 
 TARGET_ARCH?=  ${MACHINE_ARCH}
 .if ${TARGET_ARCH} == "aarch64"
 LINKS= ${BINDIR}/ld.lld ${BINDIR}/ld
+MLINKS=ld.lld.1 ld.1
 .endif
 
 CPPFLAGS+= ${CLANG_INCLUDES}
 CPPFLAGS+= -I${.CURDIR}/../../../llvm/tools/lld/include
 
 .PATH: ${.CURDIR}/../../../llvm/tools/lld/tools/lld
+.PATH: ${.CURDIR}/../../../llvm/tools/lld/docs
 
 LLVM_LIBDEPS=  lldELF \
lldConfig \
Index: llvm/tools/lld/docs/ld.lld.1
===
RCS file: llvm/tools/lld/docs/ld.lld.1
diff -N llvm/tools/lld/docs/ld.lld.1
--- /dev/null   1 Jan 1970 00:00:00 -
+++ llvm/tools/lld/docs/ld.lld.11 Mar 2018 05:23:10 -
@@ -0,0 +1,518 @@
+.\" This file is distributed under the University of Illinois Open Source
+.\" License. See LICENSE.TXT for details.
+.\"
+.\" This man page documents only lld's ELF linking support, obtained originally
+.\" from FreeBSD.
+.Dd February 9, 2018
+.Dt LD.LLD 1
+.Os
+.Sh NAME
+.Nm ld.lld
+.Nd ELF linker from the LLVM project
+.Sh SYNOPSIS
+.Nm ld.lld
+.Op Ar options
+.Ar objfile ...
+.Sh DESCRIPTION
+A linker takes one or more object, archive, and library files, and combines
+them into an output file (an executable, a shared library, or another object
+file).
+It relocates code and data from the input files and resolves symbol
+references between them.
+.Pp
+.Nm
+is a drop-in replacement for the GNU BFD and gold linkers.
+It accepts most of the same command line arguments and linker scripts
+as GNU linkers.
+.Pp
+These options are available:
+.Bl -tag -width indent
+.It Fl -allow-multiple-definition
+Do not error if a symbol is defined multiple times.
+The first definition will be used.
+.It Fl -as-needed
+Only set
+.Dv DT_NEEDED
+for shared libraries if used.
+.It Fl -auxiliary Ar value
+Set the
+.Dv DT_AUXILIARY
+field to the specified name.
+.It Fl -Bdynamic
+Link against shared libraries.
+.It Fl -Bstatic
+Do not link against shared libraries.
+.It Fl -Bsymbolic-functions
+Bind defined function symbols locally.
+.It Fl -Bsymbolic
+Bind defined symbols locally.
+.It Fl -build-id= Ns Ar value
+Generate a build ID note.
+.Ar value
+may be one of
+.Cm fast ,
+.Cm md5 ,
+.Cm sha1 ,
+.Cm tree ,
+.Cm uuid ,
+.Cm 0x Ns Ar hex-string ,
+and
+.Cm none .
+.Cm tree
+is an alias for
+.Cm sha1 .
+Build-IDs of type
+.Cm fast ,
+.Cm md5 ,
+.Cm sha1 ,
+and
+.Cm tree
+are calculated from the object contents.
+.Cm fast
+is not intended to be cryptographically secure.
+.It Fl -build-id
+Synonym for
+.Fl -build-id= Ns Cm fast .
+.It Fl -color-diagnostics= Ns Ar value
+Use colors in diagnostics.
+.Ar value
+may be one of
+.Cm always ,
+.Cm auto ,
+and
+.Cm never .
+.Cm auto
+enables color if and only if output is to a terminal.
+.It Fl -color-diagnostics
+Alias for
+.Fl -color-diagnostics= Ns Cm auto .
+.It Fl -compress-debug-sections= Ns Ar value
+Compress DWARF debug sections.
+.Ar value
+may be
+.Cm none
+or
+.Cm zlib .
+.It Fl -define-common
+Assign space to common symbols.
+.It Fl -defsym= Ns Ar symbol= Ns Ar expression
+Define a symbol alias.
+.Ar expression
+may be another symbol or a linker script expression.
+For example,
+.Fl -defsym= Ns Cm foo= Ns Cm bar
+or
+.Fl -defsym= Ns Cm foo= Ns Cm bar+0x100 .
+.It Fl -demangle
+Demangle symbol names.
+.It Fl -disable-new-dtags
+Disable new dynamic tags.
+.It Fl -discard-all
+Delete all local symbols.
+.It Fl -discard-locals
+Delete temporary local symbols.
+.It Fl -discard-none
+Keep all symbols in the symbol table.
+.It Fl -dynamic-linker Ar value
+Specify the dynamic linker to be used for a dynamically linked executable.
+This is recorded in an ELF segment of type
+.Dv PT_INTERP .
+.It Fl -dynamic-list Ar file
+Read a list of dynamic symbols from
+.Ar file .
+.It Fl -eh-frame-hdr
+Request creation of
+.Li .eh_frame_hdr
+section and
+.Dv PT_GNU_EH_FRAME
+segment header.
+.It Fl -emit-relocs
+Generate relocations in the output.
+.It Fl -enable-new-dtags
+Enable new dynamic tags.
+.It Fl -end-lib
+End a grouping of objects that should be treated as if they were together
+in an archive.
+.It Fl -entry Ar entry
+Name of entry point symbol.
+.It Fl -error-limit Ar value
+Maximum number of errors to emit before stopping.
+A value of zero indicates that there is no limit.
+.It Fl -error-unresolved-symbols
+Report unresolved symbols as errors.
+.It Fl -exclude-libs Ar value
+Exclude static libraries from automatic export.
+.It Fl -export-dynamic-symbol Ar symbol
+Include
+.Ar symbol
+in the 

Re: disable efi watchdog

[Jonathan Gray]

On Sun, Feb 11, 2018 at 04:38:18PM +1100, Jonathan Gray wrote:
> The UEFI specification states a watchdog should be armed for 5 minutes.
> Stop this from resetting a system when in efiboot.

Anyone?  It is annoying to have the system reset itself when trying
to do something in boot or purposefully leaving it at the prompt.

> 
> Index: amd64/stand/efiboot/efiboot.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
> retrieving revision 1.28
> diff -u -p -r1.28 efiboot.c
> --- amd64/stand/efiboot/efiboot.c 25 Nov 2017 19:02:07 -  1.28
> +++ amd64/stand/efiboot/efiboot.c 11 Feb 2018 05:25:11 -
> @@ -81,6 +81,9 @@ efi_main(EFI_HANDLE image, EFI_SYSTEM_TA
>   RS = ST->RuntimeServices;
>   IH = image;
>  
> + /* disable reset by watchdog after 5 minutes */
> + EFI_CALL(BS->SetWatchdogTimer, 0, 0, 0, NULL);
> +
>   efi_video_init();
>   efi_heap_init();
>  
> Index: armv7/stand/efiboot/efiboot.c
> ===
> RCS file: /cvs/src/sys/arch/armv7/stand/efiboot/efiboot.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 efiboot.c
> --- armv7/stand/efiboot/efiboot.c 21 Aug 2017 20:05:32 -  1.19
> +++ armv7/stand/efiboot/efiboot.c 11 Feb 2018 05:25:11 -
> @@ -71,6 +71,9 @@ efi_main(EFI_HANDLE image, EFI_SYSTEM_TA
>   BS = ST->BootServices;
>   IH = image;
>  
> + /* disable reset by watchdog after 5 minutes */
> + EFI_CALL(BS->SetWatchdogTimer, 0, 0, 0, NULL);
> +
>   status = EFI_CALL(BS->HandleProtocol, image, _guid,
>   (void **));
>   if (status == EFI_SUCCESS)
> Index: arm64/stand/efiboot/efiboot.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/stand/efiboot/efiboot.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 efiboot.c
> --- arm64/stand/efiboot/efiboot.c 6 Feb 2018 20:35:21 -   1.15
> +++ arm64/stand/efiboot/efiboot.c 11 Feb 2018 05:25:12 -
> @@ -74,6 +74,9 @@ efi_main(EFI_HANDLE image, EFI_SYSTEM_TA
>   BS = ST->BootServices;
>   IH = image;
>  
> + /* disable reset by watchdog after 5 minutes */
> + EFI_CALL(BS->SetWatchdogTimer, 0, 0, 0, NULL);
> +
>   status = EFI_CALL(BS->HandleProtocol, image, _guid,
>   (void **));
>   if (status == EFI_SUCCESS)
> 

Re: More useful: something like doasedit

[Emille Blanc]

On 28.02.2018 15:10, Ingo Schwarze wrote:

Hi,

Felix Maschek wrote on Wed, Feb 28, 2018 at 08:24:19PM +0100:

How would you prevent that something like 'doas vi /etc/fstab' 
(which
will run as root) doesn't offer the user to enter a root shell 
within vi

(by typing '.sh')?


The sudo(8) utility has become able, over the decades, to do very
complex things and supports fine granularity for assigning rights
to administrators.  As a consequence, it has also become somewhat
large and complicated.  As a consequence, Michael Lucas has become
able to write a book about it and to hold tutorials about it at BSD
conferences.

The design goal of doas(1) is not to reproduce the full range
of sudo(8) functionality, but to provide a smaller tool that
is easier to maintain, use, and audit.  When writing it, it was
intentional that tedu@ did not include doasedit(1) functionality -
because providing selective editing capabilities of certain
root-owned files to certain non-root administrators is among the
things that can be considered complex, fine-grained control.

During the Cambridge Hackathon, one OpenBSD developer actually
implemented doasedit(1) nevertheless.  But the result was indeed
complicated enough that committing it wasn't a no-brainer, several
developers doubted whether we should have it at all, and nobody
tried very hard to hammer the diff into a form that might meet
consensus for commit.

The question comes up now and again, but not all that often...

Yours,
  Ingo


I've run into this more than a few times, but found it's easier to just 
setup sudo for the few cases where needed as a supplement to doas for 
those cases.
I appreciate the idea of leaving the complexity of sudo where it is, 
and keeping doas neat and tidy.
Otherwise, the hardest part in living with doas so far, is coping with 
muscle memory.  'sudo something' always comes out first, other times 
'doas -e /file', both of which make me feel stupid for a brief moment. 
But that's my problem, not doas'.

A patch that fixes /usr/games/hack

[tonypony76]

The game /usr/games/hack is currently broken.

 http://marc.info/?l=openbsd-cvs=147343518631317

A patch that fixes /usr/games/hack is included below.  The patch moves
the hackdir from /var/games to a user-specified directory.  Procedures
for specifying the directory (either on the command line, or with an
environment variable) are described on the hack man page.

The main change is that if two users want to share a hackdir (so that
they have a common high-score list, for example), they will need to
create a directory that they both have access to.  For example, if both
users are in the same group, they could create a directory that is owned
by that group.

The patch also moves the read-only datafiles from /var/games/hackdir to
/usr/share/games/hack.  Before attempting to install the patched version
of hack, be sure to create the /usr/share/games/hack directory.

Also, I noticed that the rumors file wasn't being installed by the
Makefile.  I fixed that bug, too.


--- games/hack/config.h.origFri Oct 16 07:37:46 2015
+++ games/hack/config.h Wed Feb 28 22:27:25 2018
@@ -77,10 +77,10 @@
 #define WIZARD  "bruno"/* the person allowed to use the -D option */
 #define RECORD "record"/* the file containing the list of topscorers */
 #defineNEWS"news"  /* the file containing the latest hack news */
-#defineHELP"help"  /* the file containing a description of the 
commands */
-#defineSHELP   "hh"/* abbreviated form of the same */
-#defineRUMORFILE   "rumors"/* a file with fortune cookies 
*/
-#defineDATAFILE"data"  /* a file giving the meaning of symbols 
used */
+#defineHELP"/usr/share/games/hack/help"/* the file containing 
a description of the commands */
+#defineSHELP   "/usr/share/games/hack/hh"  /* abbreviated form of 
the same */
+#defineRUMORFILE   "/usr/share/games/hack/rumors"  /* a file with 
fortune cookies */
+#defineDATAFILE"/usr/share/games/hack/data"/* a file 
giving the meaning of symbols used */
 #defineFMASK   0660/* file creation mask */
 #defineHLOCK   "perm"  /* an empty file used for locking purposes */
 #define LLOCK  "safelock"  /* link to previous */
@@ -93,7 +93,7 @@
  * (This might be preferable for security reasons.)
  * #define DEF_PAGER   ".../mydir/mypager"
  */
-#defineDEF_PAGER   _PATH_PAGER
+/* #define DEF_PAGER   _PATH_PAGER */
 
 /*
  * If you define MAIL, then the player will be notified of new mail
@@ -120,7 +120,7 @@
 #ifdef QUEST
 #define HACKDIR _PATH_QUEST
 #else /* QUEST */
-#define HACKDIR_PATH_HACK
+/* #define HACKDIR _PATH_HACK */
 #endif /* QUEST */
 
 /*
@@ -130,7 +130,7 @@
  * since the user might create files in a directory of his choice.
  * Of course SECURE is meaningful only if HACKDIR is defined.
  */
-#define SECURE /* do setuid(getuid()) after chdir() */
+/* #define SECURE */   /* do setuid(getuid()) after chdir() */
 
 /*
  * If it is desirable to limit the number of people that can play Hack
--- games/hack/hack.main.c.orig Sat Jan  9 21:54:11 2016
+++ games/hack/hack.main.c  Wed Feb 28 21:03:02 2018
@@ -89,7 +89,7 @@
 #ifdef DEF_PAGER
 char *catmore; /* default pager */
 #endif
-char SAVEF[PL_NSIZ + 11] = "save/";/* save/9player */
+char SAVEF[PL_NSIZ + 6] = "";  /* 9player */
 char obuf[BUFSIZ]; /* BUFSIZ is defined in stdio.h */
 
 extern char *nomovemsg;
@@ -295,7 +295,7 @@
}
 #endif
setftty();
-   (void) snprintf(SAVEF, sizeof SAVEF, "save/%u%s", getuid(), plname);
+   (void) snprintf(SAVEF, sizeof SAVEF, "%u%s", getuid(), plname);
regularize(SAVEF+5);/* avoid . or / in name */
if((fd = open(SAVEF, O_RDONLY)) >= 0 &&
   (uptodate(fd) || unlink(SAVEF) == 666)) {
@@ -538,6 +538,7 @@
}
 
/* warn the player if he cannot write the record file */
+   /* warn the player if he cannot read the permanent lock file */
/* perhaps we should also test whether . is writable */
/* unfortunately the access systemcall is worthless */
if(wr) {
@@ -545,8 +546,13 @@
 
if(dir == NULL)
dir = ".";
-   if((fd = open(RECORD, O_RDWR)) < 0) {
+   if((fd = open(RECORD, O_RDWR | O_CREAT, FMASK)) < 0) {
printf("Warning: cannot write %s/%s", dir, RECORD);
+   getret();
+   } else
+   (void) close(fd);
+   if((fd = open(HLOCK, O_RDONLY | O_CREAT, FMASK)) < 0) {
+   printf("Warning: cannot read %s/%s", dir, HLOCK);
getret();
} else
(void) close(fd);
--- games/hack/Makefile.origMon Jul 10 21:30:37 2017
+++ games/hack/Makefile Wed Feb 28 16:39:15 2018
@@ -27,12 +27,7 @@
${HOSTCC} ${CFLAGS} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET} 
${.CURDIR}/${.PREFIX}.c 

Re: More useful: something like doasedit

[Ingo Schwarze]

Hi,

Felix Maschek wrote on Wed, Feb 28, 2018 at 08:24:19PM +0100:

> How would you prevent that something like 'doas vi /etc/fstab' (which 
> will run as root) doesn't offer the user to enter a root shell within vi 
> (by typing '.sh')?

The sudo(8) utility has become able, over the decades, to do very
complex things and supports fine granularity for assigning rights
to administrators.  As a consequence, it has also become somewhat
large and complicated.  As a consequence, Michael Lucas has become
able to write a book about it and to hold tutorials about it at BSD
conferences.

The design goal of doas(1) is not to reproduce the full range
of sudo(8) functionality, but to provide a smaller tool that
is easier to maintain, use, and audit.  When writing it, it was
intentional that tedu@ did not include doasedit(1) functionality -
because providing selective editing capabilities of certain
root-owned files to certain non-root administrators is among the
things that can be considered complex, fine-grained control.

During the Cambridge Hackathon, one OpenBSD developer actually
implemented doasedit(1) nevertheless.  But the result was indeed
complicated enough that committing it wasn't a no-brainer, several
developers doubted whether we should have it at all, and nobody
tried very hard to hammer the diff into a form that might meet
consensus for commit.

The question comes up now and again, but not all that often...

Yours,
  Ingo

Re: openssl.1 diff

[Ingo Schwarze]

Hi,

Holger Mikolon wrote on Tue, Feb 27, 2018 at 11:04:10PM +0100:
> jmc@ wrote:

>> i wonder whether we could more simply just use the date format [YY]YY,
>> explain the 2050 cutoff, and forget about mentioning asn.1 time
>> structures.
>> 
>> or do you think there is a practical reason why the user would need to
>> know it? i suspect not.

Don't forget that the openssl(1) utility is intended as a test tool
for developers, in particular when they want to test whether functions
documented in section 3 work correctly, and that it is *not* intended
as a production tool for end users, so in general, the same level
of technicality as in section 3 manual pages is adequate.

> Actually the mentioning of the asn.1 time structure helped me to identify
> the RFC 5280 and finally helped solve my parameter usage. If the man page
> was fixed, I couldn't anymore think of a practical reason to mention the 
> structure. 

In the case at hand, removing the reference to UTCTime was apparently
not only correct, but required.  I didn't test myself nor inspect the
code, but from the test results you report, it appears that both
GeneralizedTime and UTCTime format are accepted.

So what Jason committed is fine.

> However (and I don't know if that's relevant to someone) the ASN.1
> structure used for dates before 2050 is always "UTCTime", no matter
> if the  or YY format was provided on command line.

That is required by RFC 5280, paragraph 4.1.2.5. "Validity":

   [...]
   CAs conforming to this profile MUST always encode certificate
   validity dates through the year 2049 as UTCTime; certificate validity
   dates in 2050 or later MUST be encoded as GeneralizedTime.
   Conforming applications MUST be able to process validity dates that
   are encoded in either UTCTime or GeneralizedTime.
   [...]

The joys of X.509.

Yours,
  Ingo

axen invalid buffer printf

[Jan Schreiber]

I connect to a lot of different networks with an axen(4) driven USB
network dongle. I often get spammed with "invalid buffer..." messages in
my dmesg.

This mail thread on bugs@ happened a while back but no patch was
submitted: https://marc.info/?l=openbsd-bugs=149138214725080=2

I now changed the printfs do DPRINTFs and increment the error count for
each packet. I didn't see a reason why to add the specific package
number.


diff --git sys/dev/usb/if_axen.c sys/dev/usb/if_axen.c
index 325ae548e7f..fc375d3cea9 100644
--- sys/dev/usb/if_axen.c
+++ sys/dev/usb/if_axen.c
@@ -901,8 +901,8 @@ axen_rxeof(struct usbd_xfer *xfer, void *priv, usbd_status 
status)
if (status == USBD_NOT_STARTED || status == USBD_CANCELLED)
return;
if (usbd_ratecheck(>axen_rx_notice)) {
-   printf("%s: usb errors on rx: %s\n",
-   sc->axen_dev.dv_xname, usbd_errstr(status));
+   DPRINTF(("%s: usb errors on rx: %s\n",
+   sc->axen_dev.dv_xname, usbd_errstr(status)));
}
if (status == USBD_STALLED)

usbd_clear_endpoint_stall_async(sc->axen_ep[AXEN_ENDPT_RX]);
@@ -927,7 +927,7 @@ axen_rxeof(struct usbd_xfer *xfer, void *priv, usbd_status 
status)
pkt_count  = (u_int16_t)(rx_hdr & 0x);
 
if (total_len > sc->axen_bufsz) {
-   printf("rxeof: too large transfer\n");
+   DPRINTF(("rxeof: too large transfer\n"));
goto done;
}
 
@@ -957,8 +957,8 @@ axen_rxeof(struct usbd_xfer *xfer, void *priv, usbd_status 
status)
 
do {
if ((buf[0] != 0xee) || (buf[1] != 0xee)){
-   printf("invalid buffer(pkt#%d), continue\n", pkt_count);
-   ifp->if_ierrors += pkt_count;
+   DPRINTF(("invalid buffer(pkt#%d), continue\n", 
pkt_count));
+   ifp->if_ierrors++;
goto done;
}
 
@@ -991,7 +991,7 @@ axen_rxeof(struct usbd_xfer *xfer, void *priv, usbd_status 
status)
/* cheksum err */
if ((pkt_hdr & AXEN_RXHDR_L3CSUM_ERR) || 
(pkt_hdr & AXEN_RXHDR_L4CSUM_ERR)) {
-   printf("checksum err (pkt#%d)\n", pkt_count);
+   DPRINTF(("checksum err (pkt#%d)\n", pkt_count));
goto nextpkt;
} else {
m->m_pkthdr.csum_flags |= M_IPV4_CSUM_IN_OK;
@@ -1069,8 +1069,8 @@ axen_txeof(struct usbd_xfer *xfer, void *priv, 
usbd_status status)
return;
}
ifp->if_oerrors++;
-   printf("axen%d: usb error on tx: %s\n", sc->axen_unit,
-   usbd_errstr(status));
+   DPRINTF(("axen%d: usb error on tx: %s\n", sc->axen_unit,
+   usbd_errstr(status)));
if (status == USBD_STALLED)

usbd_clear_endpoint_stall_async(sc->axen_ep[AXEN_ENDPT_TX]);
splx(s);

[OT] VISUAL vs. EDITOR vs. vi [Was: Re: Utility to safely edit doas.conf]

[Raf Czlonka]

On Wed, Feb 28, 2018 at 06:08:42PM GMT, Tom Davis wrote:
> Additionally, as Martin Schröder pointed out, all editor calls
> should use $EDITOR, but in case a user doesn't have that
> defined, use
> 
> ${EDITOR:-vi}
> 

${VISUAL:-${EDITOR:-vi}}

... and everyone's happy :^)

Raf

Re: [PATCH] src - fix IPsec capitalisation

[Jason McIntyre]

On Mon, Feb 26, 2018 at 12:15:28PM +, Raf Czlonka wrote:
> Hi all,
> 
> Fix capitalisation of IPsec as per the RFC[0] - obviously, only
> where this makes sense.
> 
> The remaining one in cert.pem[1] will get fixed automatically once
> the file is regenerated, after the object identifiers' description
> changes.
> 
> If this gets in, I'd like to submit a patch for www - *not* individual
> presentations or papers, though.
> 
> [0] https://tools.ietf.org/html/rfc4301#page-4
> [1] https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/cert.pem
> 
> Regards,
> 
> Raf
> 

i'm ok with this diff. i don;t want to commit it as-is though, because
of the code bits.

if no one shows any interest in taking it, i'll look at at least fixing the
man/calendar parts.

jmc

> Index: include/arpa/nameser.h
> ===
> RCS file: /cvs/src/include/arpa/nameser.h,v
> retrieving revision 1.13
> diff -u -p -r1.13 nameser.h
> --- include/arpa/nameser.h16 Jan 2015 00:01:28 -  1.13
> +++ include/arpa/nameser.h26 Feb 2018 11:03:07 -
> @@ -223,7 +223,7 @@
>  #define  KEYFLAG_USERACCOUNT 0x0400  /* key is assoc. with a user 
> acct */
>  #define  KEYFLAG_ENTITY  0x0200  /* key is assoc. with entity eg 
> host */
>  #define  KEYFLAG_ZONEKEY 0x0100  /* key is zone key for the zone 
> named */
> -#define  KEYFLAG_IPSEC   0x0080  /* key is for IPSEC use (host 
> or user)*/
> +#define  KEYFLAG_IPSEC   0x0080  /* key is for IPsec use (host 
> or user)*/
>  #define  KEYFLAG_EMAIL   0x0040  /* key is for email (MIME 
> security) */
>  #define  KEYFLAG_RESERVED10  0x0020  /* reserved - must be zero */
>  #define  KEYFLAG_RESERVED11  0x0010  /* reserved - must be zero */
> Index: lib/libcrypto/ec/ec_curve.c
> ===
> RCS file: /cvs/src/lib/libcrypto/ec/ec_curve.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 ec_curve.c
> --- lib/libcrypto/ec/ec_curve.c   29 Jan 2017 17:49:23 -  1.15
> +++ lib/libcrypto/ec/ec_curve.c   26 Feb 2018 11:03:09 -
> @@ -2135,7 +2135,7 @@ static const struct {
>   }
>  };
>  
> -/* IPSec curves */
> +/* IPsec curves */
>  /* NOTE: The of curves over a extension field of non prime degree
>   * is not recommended (Weil-descent).
>   * As the group order is not a prime this curve is not suitable
> @@ -3116,10 +3116,10 @@ static const ec_list_element curve_list[
>  #endif
>   {NID_wap_wsg_idm_ecid_wtls12, &_EC_WTLS_12.h, 0, "WTLS curve over a 224 
> bit prime field"},
>  #ifndef OPENSSL_NO_EC2M
> - /* IPSec curves */
> - {NID_ipsec3, &_EC_IPSEC_155_ID3.h, 0, "\n\tIPSec/IKE/Oakley curve #3 
> over a 155 bit binary field.\n"
> + /* IPsec curves */
> + {NID_ipsec3, &_EC_IPSEC_155_ID3.h, 0, "\n\tIPsec/IKE/Oakley curve #3 
> over a 155 bit binary field.\n"
>   "\tNot suitable for ECDSA.\n\tQuestionable extension field!"},
> - {NID_ipsec4, &_EC_IPSEC_185_ID4.h, 0, "\n\tIPSec/IKE/Oakley curve #4 
> over a 185 bit binary field.\n"
> + {NID_ipsec4, &_EC_IPSEC_185_ID4.h, 0, "\n\tIPsec/IKE/Oakley curve #4 
> over a 185 bit binary field.\n"
>   "\tNot suitable for ECDSA.\n\tQuestionable extension field!"},
>  #endif
>   /* RFC 5639 curves */
> Index: lib/libcrypto/objects/objects.txt
> ===
> RCS file: /cvs/src/lib/libcrypto/objects/objects.txt,v
> retrieving revision 1.19
> diff -u -p -r1.19 objects.txt
> --- lib/libcrypto/objects/objects.txt 25 May 2017 17:00:24 -  1.19
> +++ lib/libcrypto/objects/objects.txt 26 Feb 2018 11:03:09 -
> @@ -486,9 +486,9 @@ id-kp 2   : clientAuth: TLS 
> Web Client
>  id-kp 3  : codeSigning   : Code Signing
>  !Cname email-protect
>  id-kp 4  : emailProtection   : E-mail Protection
> -id-kp 5  : ipsecEndSystem: IPSec End System
> -id-kp 6  : ipsecTunnel   : IPSec Tunnel
> -id-kp 7  : ipsecUser : IPSec User
> +id-kp 5  : ipsecEndSystem: IPsec End System
> +id-kp 6  : ipsecTunnel   : IPsec Tunnel
> +id-kp 7  : ipsecUser : IPsec User
>  !Cname time-stamp
>  id-kp 8  : timeStamping  : Time Stamping
>  # From OCSP spec RFC2560
> Index: sbin/iked/iked.h
> ===
> RCS file: /cvs/src/sbin/iked/iked.h,v
> retrieving revision 1.117
> diff -u -p -r1.117 iked.h
> --- sbin/iked/iked.h  30 Nov 2017 12:18:44 -  1.117
> +++ sbin/iked/iked.h  26 Feb 2018 11:03:14 -
> @@ -165,7 +165,7 @@ RB_HEAD(iked_flows, iked_flow);
>  TAILQ_HEAD(iked_saflows, iked_flow);
>  
>  struct iked_childsa {
> - uint8_t 

Re: openssl.1 diff

[Jason McIntyre]

On Wed, Feb 28, 2018 at 08:43:34PM +0100, Holger Mikolon wrote:
> > > > Index: openssl.1
> > > > ===
> > > > RCS file: /cvs/src/usr.bin/openssl/openssl.1,v
> > > > retrieving revision 1.87
> > > > diff -u -r1.87 openssl.1
> > > > --- openssl.1   18 Feb 2018 07:43:55 -  1.87
> > > > +++ openssl.1   27 Feb 2018 21:38:06 -
> > > > @@ -360,8 +360,8 @@
> > > >  The number of days to certify the certificate for.
> > > >  .It Fl enddate Ar date
> > > >  Set the expiry date.
> > > > -The format of the date is YYMMDDHHMMSSZ
> > > > -.Pq the same as an ASN.1 UTCTime structure .
> > > > +The format of the date is [YY]YYMMDDHHMMSSZ,
> > > > +with all four year digits required for dates after 2050.
> > > 
> > > "dates after 2050" reads like "2051 and later" to me, which would be 
> > > wrong.
> > > It should rather be "dates after 31 Dec 2049". In other words:
> > > You must specify 2049 as 49 and 2050 as 2050.
> > > 
> > 
> > so dates *from* 2050, rather than after?
> > 
> > but..."you *must* specify 2049 as 49": "2049" is valid, right?
> > 
> > jmc
> 
> I did some experiments today; you're right, "2049" works just like "49".
> Sorry for the wrong claim - it's been obviously too late yesterday  :- )
> 
> Specifying "2050", however, is not equal to "50" (==1950).
> So the wording "from 2050" or "after 2049" would both work. With that
> exception your above diff reads correct to me. And I checked that
> -startdate and -enddate behave equally.
> 

great. thanks for verifying that.

> However (and I don't know if that's relevant to someone) the ASN.1
> structure used for dates before 2050 is always "UTCTime", no matter if the
>  or YY format was provided on command line. I checked it by parsing a
> certifciate with "openssl asn1parse". As already said, I don't see a value
> in documenting that structure. Others might.
> 

i am zapping the asn.1 refs, as i see no benefit in keeping it and it
will keep the text from getting bigger.

jmc

> Holger
> 

Re: openssl.1 diff

[Holger Mikolon]

> > > Index: openssl.1
> > > ===
> > > RCS file: /cvs/src/usr.bin/openssl/openssl.1,v
> > > retrieving revision 1.87
> > > diff -u -r1.87 openssl.1
> > > --- openssl.1 18 Feb 2018 07:43:55 -  1.87
> > > +++ openssl.1 27 Feb 2018 21:38:06 -
> > > @@ -360,8 +360,8 @@
> > >  The number of days to certify the certificate for.
> > >  .It Fl enddate Ar date
> > >  Set the expiry date.
> > > -The format of the date is YYMMDDHHMMSSZ
> > > -.Pq the same as an ASN.1 UTCTime structure .
> > > +The format of the date is [YY]YYMMDDHHMMSSZ,
> > > +with all four year digits required for dates after 2050.
> > 
> > "dates after 2050" reads like "2051 and later" to me, which would be wrong.
> > It should rather be "dates after 31 Dec 2049". In other words:
> > You must specify 2049 as 49 and 2050 as 2050.
> > 
> 
> so dates *from* 2050, rather than after?
> 
> but..."you *must* specify 2049 as 49": "2049" is valid, right?
> 
> jmc

I did some experiments today; you're right, "2049" works just like "49".
Sorry for the wrong claim - it's been obviously too late yesterday  :- )

Specifying "2050", however, is not equal to "50" (==1950).
So the wording "from 2050" or "after 2049" would both work. With that
exception your above diff reads correct to me. And I checked that
-startdate and -enddate behave equally.

However (and I don't know if that's relevant to someone) the ASN.1
structure used for dates before 2050 is always "UTCTime", no matter if the
 or YY format was provided on command line. I checked it by parsing a
certifciate with "openssl asn1parse". As already said, I don't see a value
in documenting that structure. Others might.

Holger

Re: More useful: something like doasedit (was: Utility to safely edit doas.conf)

[Felix Maschek]

Hi,

possibly there is only some missing enlightenment for me.

How would you prevent that something like 'doas vi /etc/fstab' (which 
will run as root) doesn't offer the user to enter a root shell within vi 
(by typing '.sh')?


You may direct me to appropriate man pages.

Thank you!

Kind regards
Felix

On 28.02.2018 19:32, Michael Price wrote:
Perhaps I am just dense, but what problem does sudoedit solve that is 
not

easily solved with groups and chmod?

Michael

On Wed, Feb 28, 2018 at 12:57 PM Felix Maschek  
wrote:



Hi,

to prevent privilege escalation by allowing 'sudo vi' (simple by
invoking a shell from within vi) there is a special command 
'sudoedit'.

So far I can see this is missing currently if I use doas instead of
sudo.

So adding a similar command is more helpful to secure a system than
special editors for every config file.

Kind regards
Felix

On 28.02.2018 18:22, Frans Haarman wrote:
> I've wondered about the usefulness of something like 'rcctl edit
> bgpd'and a
> bgpd_conf=/etc/bgpd.conf in rc.conf.
>
> Together with a 'rcctl clone' creating rc.d/bgpd symlink and
> rc.conf.local
> flags.
>
> Might make it easier running multiple of the same daemons?
>
> Add more cool stuff later like 'rcctl edit bgpd commit' and 'rcctl edit
> bgpd confirm'.
>
> Just wondering out loud now :)
>
> Regards,
> Frans
>
> Op woensdag 28 februari 2018 heeft Theo de Raadt 
> het
> volgende geschreven:
>> Yeah.
>>
>> And I suppose we also need seperate programs for all the other files
>> in /etc?
>>
>> Such as visysctl.conf, vivm.conf, vigroup, vishells, virc.conf.local,
>> visshd, vissh, etc
>>
>> After all, someone could create unsafe configurations, and lots of
> handholding
>> is needed everywhere, yes?
>>
>> I'm sorry, but I disagree.  The tooling already exists to let you do
>> this carefully.  It is up to people to use their brains. And your
>> script doesn't have any locking, so it is still error prone.
>>
>> I really don't see the point of these wrappers.
>>
>>> The following is a shell script to safely edit /etc/doas.conf so that
>>> you
> avoid locking yourself out with a bad config. I managed to do this
> myself,
> so thought it might be useful to a wider audience.
>>>
>>> It is inspired by the 'visudo' tool: it copies doas.conf to a
>>> temporary
> directory then opens it in vi. When you exit vi it checks the format of
> the
> config file, and if it passes then it will overwrite the original one
> then
> delete the copy. If it fails a warning is shown, and the file is
> re-opened
> for editing.
>>>
>>> It will not create /etc/doas.conf if it does not already exist (I
>>> could
> add a separate warning for this if needed).
>>>
>>> diff -u /dev/null usr.bin/doas/vidoas
>>> --- /dev/null2018-02-22 08:14:04.607259461 +
>>> +++ usr.bin/doas/vidoas2018-02-28 15:50:35.358895700 +
>>> @@ -0,0 +1,36 @@
>>> +#!/bin/sh
>>> +
>>> +# $OpenBSD$
>>> +#
>>> +# Copyright (c) 2018 Anthony Perkins 
>>> +#
>>> +# 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.
>>> +
>>> +doasconf=/etc/doas.conf
>>> +tempfile=$(mktemp -t doas. || exit 1)
>>> +if [ -w $doasconf ]; then
>>> +cp $doasconf $tempfile
>>> +vi $tempfile
>>> +while ! doas -C $tempfile; do
>>> +echo "Press Enter to retry, Ctrl-C to abort."
>>> +read
>>> +vi $tempfile
>>> +done
>>> +if doas -C $tempfile; then
>>> +cp -f $tempfile $doasconf
>>> +rm -f $tempfile
>>> +fi
>>> +else
>>> +echo "$doasconf is not writable by this user."
>>> +exit 1
>>> +fi
>>> diff -u /dev/null usr.bin/doas/vidoas.1
>>> --- /dev/null2018-02-22 08:14:04.607259461 +
>>> +++ usr.bin/doas/vidoas.12018-02-28 15:31:20.825930370 +
>>> @@ -0,0 +1,44 @@
>>> +.\" $OpenBSD$
>>> +.\"
>>> +.\"Copyright (c) 2018 Anthony Perkins 
>>> +.\"
>>> +.\"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 

Re: dhcp-options(5) diff

[Kenneth R Westerback]

On Wed, Feb 28, 2018 at 05:27:41PM +0100, Matthieu Herrb wrote:
> On Wed, Feb 28, 2018 at 05:24:20PM +0100, Matthieu Herrb wrote:
> > Hi,
> > 
> > I've started using the classless-static-route option in dhcpd(8). This
> > was not as painless as possible because I missed some important
> > information from the underlying RFC to understand how the option is
> > used by clients and how it should be configured on the server.
> > 
> > The patch below tries to add this information to dhcp-options(5),
> > without beeing too verbose.
> > 
> > While there, I also noted that the classful routes are obsolete. I was
> > wondering if we could just remove this option from the doc (and maybe
> > tedu the code ?) instead.
> > 
> > Ok, corrections, ... ?
> 
> Argh I managed to mangle the diff with a last minute edit. Correct
> version:

I agree with the intent of this diff and am happy to work on tweaks to
the actual verbiage in-tree. ok krw@

 Ken

> 
> Index: dhcp-options.5
> ===
> RCS file: /cvs/OpenBSD/src/usr.sbin/dhcpd/dhcp-options.5,v
> retrieving revision 1.22
> diff -u -p -u -r1.22 dhcp-options.5
> --- dhcp-options.514 Sep 2015 20:06:59 -  1.22
> +++ dhcp-options.528 Feb 2018 16:26:50 -
> @@ -171,6 +171,11 @@ RFC 1122.
>  .It Ic option classless-static-routes Ar ip/prefix ip Oo , Ar ip/prefix ip 
> ... Oc ;
>  This option specifies a list of static routes in CDIR notation, which
>  should be sent to the client.
> +This option is specified in RFC3442.
> +Note that, since the RFC says that clients supporting this option must 
> ignore the
> +.Ic Routers
> +option when both are present, the default route
> +needs to be included in the list of routes specified here.
>  .It Ic option classless-ms-static-routes Ar ip/prefix ip Oo , Ar ip/prefix 
> ip ... Oc ;
>  This option does the same as
>  .Ic classless-static-routes ,
> @@ -517,6 +522,8 @@ The default route (0.0.0.0) is an illega
>  To specify the default route, use the
>  .Ic routers
>  option.
> +Note that this option is obsolete and should be replaced by the
> +.Ic classless-static-routes option.
>  .It Ic option streettalk-directory-assistance-server Ar ip-address Oo , Ar 
> ip-address ... Oc ;
>  The StreetTalk Directory Assistance (STDA) server option specifies a
>  list of STDA servers available to the client.
> 
> -- 
> Matthieu Herrb

Marvel Yukon Ultra II NIC badly supported by msk driver

[Damien Boureille]

Hi,

I'm trying to install OpenBSD 6.2 on a Netgear RNDU2000 NAS.
The Marvel Yukon Ultra II NIC is supposedly supported by the msk driver,
but this particular NIC has troubles receiving packets.

Log from the serial console (install initrd):

===
OpenBSD 6.2 (RAMDISK_CD) #132: Tue Oct  3 21:26:51 MDT 2017
   dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 1046020096 (997MB)
avail mem = 1010618368 (963MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xfbe40 (17 entries)
bios0: vendor American Megatrends Inc. version "080016" date 09/08/2010
bios0: NETGEAR ReadyNAS
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI SSDT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compatnails
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU D425 @ 1.80GHz, 1800.25 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DSCPL,TM2,
SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, C-substates=0.1, IBE
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
to apid 2
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P4)
acpiprt2 at acpi0: bus 2 (P0P5)
acpiprt3 at acpi0: bus 3 (P0P6)
acpicpu at acpi0 not configured
"PNP0C0C" at acpi0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x00
vga1 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x00
wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
"Intel Pineview Video" rev 0x00 at pci0 dev 2 function 1 not configured
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
mskc0 at pci1 dev 0 function 0 "Marvell Yukon 88E8057" rev 0x10, Yukon-2
Ultra 2 (0x0):msi
msk0 at mskc0 port A: address 30:46:9a:f9:0e:9e
eephy0 at msk0 phy 0: 88E1149 Gigabit PHY, rev. 1
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: msi
pci2 at ppb1 bus 2
xhci0 at pci2 dev 0 function 0 "NEC xHCI" rev 0x03: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "NEC xHCI root hub" rev
3.00/1.00 addr 1
ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x02: msi
pci3 at ppb2 bus 3
mskc1 at pci3 dev 0 function 0 "Marvell Yukon 88E8057" rev 0x10, Yukon-2
Ultra 2 (0x0): msi
msk1 at mskc1 port A: address 30:46:9a:f9:0e:9f
eephy1 at msk1 phy 0: 88E1149 Gigabit PHY, rev. 1
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 2 int
23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 2 int
19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 2 int
18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 2 int
16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 2 int
23
usb1 at ehci0: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev
2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2
pci4 at ppb3 bus 4
"Intel NM10 LPC" rev 0x02 at pci0 dev 31 function 0 not configured
ahci0 at pci0 dev 31 function 2 "Intel 82801GR AHCI" rev 0x02: msi, AHCI
1.1
ahci0: port 1: 3.0Gb/s
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 1 lun 0:  SCSI3
0/direct fixed naa.50014ee602e55bb2
sd0: 953869MB, 512 bytes/sector, 1953525168 sectors
"Intel 82801GB SMBus" rev 0x02 at pci0 dev 31 function 3 not configured
usb2 at uhci0: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev
1.00/1.00 addr 1
usb3 at uhci1: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev
1.00/1.00 addr 1
usb4 at uhci2: USB revision 1.0
uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev
1.00/1.00 addr 1
usb5 at uhci3: USB revision 1.0
uhub5 at usb5 configuration 1 interface 0 "Intel UHCI root hub" rev
1.00/1.00 addr 1
isa0 at mainbus0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay1
umass0 at uhub0 port 3 configuration 1 interface 0 "Generic USB Mass
Storage Device" rev 2.00/1.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus1 at umass0: 2 targets, initiator 0
sd1 at scsibus1 targ 1 lun 0:  SCSI2
0/direct removable serial.048d11721EBC2A2586D4
sd1: 3841MB, 512 bytes/sector, 7866368 sectors
umass1 at uhub1 port 1 configuration 1 interface 0 "SMI Corporation USB
DISK" rev 2.00/11.00 addr 2
umass1: using SCSI over Bulk-Only
scsibus2 at umass1: 2 targets, initiator 0
sd2 at scsibus2 targ 1 lun 0:  SCSI0 0/direct
removable serial.090c112700022694
sd2: 119MB, 512 bytes/sector, 244736 sectors
softraid0 at root

Re: More useful: something like doasedit (was: Utility to safely edit doas.conf)

[Michael Price]

Perhaps I am just dense, but what problem does sudoedit solve that is not
easily solved with groups and chmod?

Michael

On Wed, Feb 28, 2018 at 12:57 PM Felix Maschek  wrote:

> Hi,
>
> to prevent privilege escalation by allowing 'sudo vi' (simple by
> invoking a shell from within vi) there is a special command 'sudoedit'.
> So far I can see this is missing currently if I use doas instead of
> sudo.
>
> So adding a similar command is more helpful to secure a system than
> special editors for every config file.
>
> Kind regards
> Felix
>
> On 28.02.2018 18:22, Frans Haarman wrote:
> > I've wondered about the usefulness of something like 'rcctl edit
> > bgpd'and a
> > bgpd_conf=/etc/bgpd.conf in rc.conf.
> >
> > Together with a 'rcctl clone' creating rc.d/bgpd symlink and
> > rc.conf.local
> > flags.
> >
> > Might make it easier running multiple of the same daemons?
> >
> > Add more cool stuff later like 'rcctl edit bgpd commit' and 'rcctl edit
> > bgpd confirm'.
> >
> > Just wondering out loud now :)
> >
> > Regards,
> > Frans
> >
> > Op woensdag 28 februari 2018 heeft Theo de Raadt 
> > het
> > volgende geschreven:
> >> Yeah.
> >>
> >> And I suppose we also need seperate programs for all the other files
> >> in /etc?
> >>
> >> Such as visysctl.conf, vivm.conf, vigroup, vishells, virc.conf.local,
> >> visshd, vissh, etc
> >>
> >> After all, someone could create unsafe configurations, and lots of
> > handholding
> >> is needed everywhere, yes?
> >>
> >> I'm sorry, but I disagree.  The tooling already exists to let you do
> >> this carefully.  It is up to people to use their brains. And your
> >> script doesn't have any locking, so it is still error prone.
> >>
> >> I really don't see the point of these wrappers.
> >>
> >>> The following is a shell script to safely edit /etc/doas.conf so that
> >>> you
> > avoid locking yourself out with a bad config. I managed to do this
> > myself,
> > so thought it might be useful to a wider audience.
> >>>
> >>> It is inspired by the 'visudo' tool: it copies doas.conf to a
> >>> temporary
> > directory then opens it in vi. When you exit vi it checks the format of
> > the
> > config file, and if it passes then it will overwrite the original one
> > then
> > delete the copy. If it fails a warning is shown, and the file is
> > re-opened
> > for editing.
> >>>
> >>> It will not create /etc/doas.conf if it does not already exist (I
> >>> could
> > add a separate warning for this if needed).
> >>>
> >>> diff -u /dev/null usr.bin/doas/vidoas
> >>> --- /dev/null2018-02-22 08:14:04.607259461 +
> >>> +++ usr.bin/doas/vidoas2018-02-28 15:50:35.358895700 +
> >>> @@ -0,0 +1,36 @@
> >>> +#!/bin/sh
> >>> +
> >>> +# $OpenBSD$
> >>> +#
> >>> +# Copyright (c) 2018 Anthony Perkins 
> >>> +#
> >>> +# 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.
> >>> +
> >>> +doasconf=/etc/doas.conf
> >>> +tempfile=$(mktemp -t doas. || exit 1)
> >>> +if [ -w $doasconf ]; then
> >>> +cp $doasconf $tempfile
> >>> +vi $tempfile
> >>> +while ! doas -C $tempfile; do
> >>> +echo "Press Enter to retry, Ctrl-C to abort."
> >>> +read
> >>> +vi $tempfile
> >>> +done
> >>> +if doas -C $tempfile; then
> >>> +cp -f $tempfile $doasconf
> >>> +rm -f $tempfile
> >>> +fi
> >>> +else
> >>> +echo "$doasconf is not writable by this user."
> >>> +exit 1
> >>> +fi
> >>> diff -u /dev/null usr.bin/doas/vidoas.1
> >>> --- /dev/null2018-02-22 08:14:04.607259461 +
> >>> +++ usr.bin/doas/vidoas.12018-02-28 15:31:20.825930370 +
> >>> @@ -0,0 +1,44 @@
> >>> +.\" $OpenBSD$
> >>> +.\"
> >>> +.\"Copyright (c) 2018 Anthony Perkins 
> >>> +.\"
> >>> +.\"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, 

Re: Utility to safely edit doas.conf

[Tom Davis]

In the line

> +tempfile=$(mktemp -t doas. || exit 1)

the "|| exit 1" doesn't actually do anything. In order to exit
the script the or bit must occur outside the subshell created by
the parenthesis. So

  tempfile=$(mktemp -t doas.) || exit 1

This will work with simple assignments though not with 'typeset'.

Additionally, as Martin Schröder pointed out, all editor calls
should use $EDITOR, but in case a user doesn't have that
defined, use

${EDITOR:-vi}

More useful: something like doasedit (was: Utility to safely edit doas.conf)

[Felix Maschek]

Hi,

to prevent privilege escalation by allowing 'sudo vi' (simple by 
invoking a shell from within vi) there is a special command 'sudoedit'. 
So far I can see this is missing currently if I use doas instead of 
sudo.


So adding a similar command is more helpful to secure a system than 
special editors for every config file.


Kind regards
Felix

On 28.02.2018 18:22, Frans Haarman wrote:
I've wondered about the usefulness of something like 'rcctl edit 
bgpd'and a

bgpd_conf=/etc/bgpd.conf in rc.conf.

Together with a 'rcctl clone' creating rc.d/bgpd symlink and 
rc.conf.local

flags.

Might make it easier running multiple of the same daemons?

Add more cool stuff later like 'rcctl edit bgpd commit' and 'rcctl edit
bgpd confirm'.

Just wondering out loud now :)

Regards,
Frans

Op woensdag 28 februari 2018 heeft Theo de Raadt  
het

volgende geschreven:

Yeah.

And I suppose we also need seperate programs for all the other files
in /etc?

Such as visysctl.conf, vivm.conf, vigroup, vishells, virc.conf.local,
visshd, vissh, etc

After all, someone could create unsafe configurations, and lots of

handholding

is needed everywhere, yes?

I'm sorry, but I disagree.  The tooling already exists to let you do
this carefully.  It is up to people to use their brains. And your
script doesn't have any locking, so it is still error prone.

I really don't see the point of these wrappers.

The following is a shell script to safely edit /etc/doas.conf so that 
you
avoid locking yourself out with a bad config. I managed to do this 
myself,

so thought it might be useful to a wider audience.


It is inspired by the 'visudo' tool: it copies doas.conf to a 
temporary
directory then opens it in vi. When you exit vi it checks the format of 
the
config file, and if it passes then it will overwrite the original one 
then
delete the copy. If it fails a warning is shown, and the file is 
re-opened

for editing.


It will not create /etc/doas.conf if it does not already exist (I 
could

add a separate warning for this if needed).


diff -u /dev/null usr.bin/doas/vidoas
--- /dev/null2018-02-22 08:14:04.607259461 +
+++ usr.bin/doas/vidoas2018-02-28 15:50:35.358895700 +
@@ -0,0 +1,36 @@
+#!/bin/sh
+
+# $OpenBSD$
+#
+# Copyright (c) 2018 Anthony Perkins 
+#
+# 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.
+
+doasconf=/etc/doas.conf
+tempfile=$(mktemp -t doas. || exit 1)
+if [ -w $doasconf ]; then
+cp $doasconf $tempfile
+vi $tempfile
+while ! doas -C $tempfile; do
+echo "Press Enter to retry, Ctrl-C to abort."
+read
+vi $tempfile
+done
+if doas -C $tempfile; then
+cp -f $tempfile $doasconf
+rm -f $tempfile
+fi
+else
+echo "$doasconf is not writable by this user."
+exit 1
+fi
diff -u /dev/null usr.bin/doas/vidoas.1
--- /dev/null2018-02-22 08:14:04.607259461 +
+++ usr.bin/doas/vidoas.12018-02-28 15:31:20.825930370 +
@@ -0,0 +1,44 @@
+.\" $OpenBSD$
+.\"
+.\"Copyright (c) 2018 Anthony Perkins 
+.\"
+.\"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.
+.Dd $Mdocdate: February 28 2018 $
+.Dt VIDOAS 1
+.Os
+.Sh NAME
+.Nm vidoas
+.Nd safely edit the doas config file
+.Sh SYNOPSIS
+.Nm vidoas
+.Sh DESCRIPTION
+The
+.Nm
+utility edits a copy of
+.Pa /etc/doas.conf .
+If the copy is valid the original file will be replaced.
+.Pp
+This helps to prevent you from accidentally
+locking yourself out from
+.Xr doas 1
+with a typo.
+It is inspired by the
+.Xr visudo 1
+utility.
+.Pp
+This utility takes no arguments.
+.Sh SEE ALSO
+.Xr doas 1 ,
+.Xr doas.conf 5
+.Sh AUTHORS
+.An Anthony Perkins 

Re: Utility to safely edit doas.conf

[Frans Haarman]

I've wondered about the usefulness of something like 'rcctl edit bgpd'and a
bgpd_conf=/etc/bgpd.conf in rc.conf.

Together with a 'rcctl clone' creating rc.d/bgpd symlink and rc.conf.local
flags.

Might make it easier running multiple of the same daemons?

Add more cool stuff later like 'rcctl edit bgpd commit' and 'rcctl edit
bgpd confirm'.

Just wondering out loud now :)

Regards,
Frans

Op woensdag 28 februari 2018 heeft Theo de Raadt  het
volgende geschreven:
> Yeah.
>
> And I suppose we also need seperate programs for all the other files
> in /etc?
>
> Such as visysctl.conf, vivm.conf, vigroup, vishells, virc.conf.local,
> visshd, vissh, etc
>
> After all, someone could create unsafe configurations, and lots of
handholding
> is needed everywhere, yes?
>
> I'm sorry, but I disagree.  The tooling already exists to let you do
> this carefully.  It is up to people to use their brains. And your
> script doesn't have any locking, so it is still error prone.
>
> I really don't see the point of these wrappers.
>
>>The following is a shell script to safely edit /etc/doas.conf so that you
avoid locking yourself out with a bad config. I managed to do this myself,
so thought it might be useful to a wider audience.
>>
>>It is inspired by the 'visudo' tool: it copies doas.conf to a temporary
directory then opens it in vi. When you exit vi it checks the format of the
config file, and if it passes then it will overwrite the original one then
delete the copy. If it fails a warning is shown, and the file is re-opened
for editing.
>>
>>It will not create /etc/doas.conf if it does not already exist (I could
add a separate warning for this if needed).
>>
>>diff -u /dev/null usr.bin/doas/vidoas
>>--- /dev/null2018-02-22 08:14:04.607259461 +
>>+++ usr.bin/doas/vidoas2018-02-28 15:50:35.358895700 +
>>@@ -0,0 +1,36 @@
>>+#!/bin/sh
>>+
>>+# $OpenBSD$
>>+#
>>+# Copyright (c) 2018 Anthony Perkins 
>>+#
>>+# 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.
>>+
>>+doasconf=/etc/doas.conf
>>+tempfile=$(mktemp -t doas. || exit 1)
>>+if [ -w $doasconf ]; then
>>+cp $doasconf $tempfile
>>+vi $tempfile
>>+while ! doas -C $tempfile; do
>>+echo "Press Enter to retry, Ctrl-C to abort."
>>+read
>>+vi $tempfile
>>+done
>>+if doas -C $tempfile; then
>>+cp -f $tempfile $doasconf
>>+rm -f $tempfile
>>+fi
>>+else
>>+echo "$doasconf is not writable by this user."
>>+exit 1
>>+fi
>>diff -u /dev/null usr.bin/doas/vidoas.1
>>--- /dev/null2018-02-22 08:14:04.607259461 +
>>+++ usr.bin/doas/vidoas.12018-02-28 15:31:20.825930370 +
>>@@ -0,0 +1,44 @@
>>+.\" $OpenBSD$
>>+.\"
>>+.\"Copyright (c) 2018 Anthony Perkins 
>>+.\"
>>+.\"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.
>>+.Dd $Mdocdate: February 28 2018 $
>>+.Dt VIDOAS 1
>>+.Os
>>+.Sh NAME
>>+.Nm vidoas
>>+.Nd safely edit the doas config file
>>+.Sh SYNOPSIS
>>+.Nm vidoas
>>+.Sh DESCRIPTION
>>+The
>>+.Nm
>>+utility edits a copy of
>>+.Pa /etc/doas.conf .
>>+If the copy is valid the original file will be replaced.
>>+.Pp
>>+This helps to prevent you from accidentally
>>+locking yourself out from
>>+.Xr doas 1
>>+with a typo.
>>+It is inspired by the
>>+.Xr visudo 1
>>+utility.
>>+.Pp
>>+This utility takes no arguments.
>>+.Sh SEE ALSO
>>+.Xr doas 1 ,
>>+.Xr doas.conf 5
>>+.Sh AUTHORS
>>+.An Anthony Perkins 
>>
>>This is only my second ever submission, so I would appreciate any
guidance. I've also not yet edited the Makefile to include this in the
build.
>>
>>All the best,
>>
>>Anthony
>>
>>--
>>Anthony Perkins

Re: Utility to safely edit doas.conf

[Stuart Henderson]

On 2018/02/28 16:16, Anthony Perkins wrote:
> The following is a shell script to safely edit /etc/doas.conf so that you 
> avoid locking yourself out with a bad config. I managed to do this myself, so 
> thought it might be useful to a wider audience.

You can still lock yourself out with a bad doas.conf (or sudoers) edit,
even with a syntactically valid config. A safer way is to keep a spare
root shell open.

Re: Utility to safely edit doas.conf

[Martin Schröder]

2018-02-28 17:16 GMT+01:00 Anthony Perkins :
> +vi $tempfile

Use $EDITOR, don't call vi directly.

Best
   Martin

Re: armv7 really isn't a strict-alignment architecture

[Brandon Bergren]

> > > > Date: Tue, 27 Feb 2018 22:30:43 +0100 (CET)
> > > > From: Mark Kettenis 
> > > > 
...
> > > > The stack needs 8-byte alignment, so .align 3.  In a "bad" kernel I
> > > > have lying around the stack is properly aligned though.  But esym
> > > > isn't because .data isn't aligned properly.
> > > > 
> > > > The diff below fixes both issues.  I'll go through the other assembly
> > > > files and make sure the alignment of the .data and .bss is correct
> > > > there as well and I'll send a new diff if I find any further issues.
> > > > 
> > > > ok?

OK, it was able to relink kernels and reboot in a loop (I modified my 
/usr/libexec/reorder_kernel script to start with sleep 60 and end with reboot) 
for about 9 hours, then it had a hang after "checking quotas: done."

Cycling power and booting again on the same kernel got past that point though, 
after fscking, so I'm going to mark that down as a fluke. Maybe the microsd 
card had a problem, maybe there was a power glitch.

In any case, it's a LOT better than it was before. I was not able to do this 
relinking loop for more than ~30 minutes without having a hang before.

> > > > Index: arch/arm/arm/locore.S
> > > > ===
> > > > RCS file: /cvs/src/sys/arch/arm/arm/locore.S,v
> > > > retrieving revision 1.13
> > > > diff -u -p -r1.13 locore.S
> > > > --- arch/arm/arm/locore.S   6 Jan 2017 00:06:02 -   1.13
> > > > +++ arch/arm/arm/locore.S   27 Feb 2018 21:27:10 -
> > > > @@ -101,6 +101,7 @@ ASENTRY_NP(start)
> > > > .align  2
> > > >  
> > > > .bss
> > > > +   .align  3
> > > >  svcstk:
> > > > .space  INIT_ARM_STACK_SIZE
> > > >  
> > > > @@ -179,6 +180,7 @@ ENTRY(longjmp)
> > > > mov pc, lr
> > > >  
> > > > .data
> > > > +   .align  2
> > > > .global _C_LABEL(esym)
> > > >  _C_LABEL(esym):.word   _C_LABEL(end)
> > > >  
> > > > 
> > > > 

-- 
  Brandon Bergren
  Technical Generalist

Re: times(3): return monotonically increasing values

[Todd C. Miller]

On Wed, 28 Feb 2018 10:23:24 -0600, Scott Cheloha wrote:

> I know it's not customary to put extra details in RETURN VALUES, but
> times(3) is a bit unwieldy.  How does the attached read?

OK by me.

 - todd

Re: dhcp-options(5) diff

[Matthieu Herrb]

On Wed, Feb 28, 2018 at 05:24:20PM +0100, Matthieu Herrb wrote:
> Hi,
> 
> I've started using the classless-static-route option in dhcpd(8). This
> was not as painless as possible because I missed some important
> information from the underlying RFC to understand how the option is
> used by clients and how it should be configured on the server.
> 
> The patch below tries to add this information to dhcp-options(5),
> without beeing too verbose.
> 
> While there, I also noted that the classful routes are obsolete. I was
> wondering if we could just remove this option from the doc (and maybe
> tedu the code ?) instead.
> 
> Ok, corrections, ... ?

Argh I managed to mangle the diff with a last minute edit. Correct
version:

Index: dhcp-options.5
===
RCS file: /cvs/OpenBSD/src/usr.sbin/dhcpd/dhcp-options.5,v
retrieving revision 1.22
diff -u -p -u -r1.22 dhcp-options.5
--- dhcp-options.5  14 Sep 2015 20:06:59 -  1.22
+++ dhcp-options.5  28 Feb 2018 16:26:50 -
@@ -171,6 +171,11 @@ RFC 1122.
 .It Ic option classless-static-routes Ar ip/prefix ip Oo , Ar ip/prefix ip ... 
Oc ;
 This option specifies a list of static routes in CDIR notation, which
 should be sent to the client.
+This option is specified in RFC3442.
+Note that, since the RFC says that clients supporting this option must ignore 
the
+.Ic Routers
+option when both are present, the default route
+needs to be included in the list of routes specified here.
 .It Ic option classless-ms-static-routes Ar ip/prefix ip Oo , Ar ip/prefix ip 
... Oc ;
 This option does the same as
 .Ic classless-static-routes ,
@@ -517,6 +522,8 @@ The default route (0.0.0.0) is an illega
 To specify the default route, use the
 .Ic routers
 option.
+Note that this option is obsolete and should be replaced by the
+.Ic classless-static-routes option.
 .It Ic option streettalk-directory-assistance-server Ar ip-address Oo , Ar 
ip-address ... Oc ;
 The StreetTalk Directory Assistance (STDA) server option specifies a
 list of STDA servers available to the client.

-- 
Matthieu Herrb

dhcp-options(5) diff

[Matthieu Herrb]

Hi,

I've started using the classless-static-route option in dhcpd(8). This
was not as painless as possible because I missed some important
information from the underlying RFC to understand how the option is
used by clients and how it should be configured on the server.

The patch below tries to add this information to dhcp-options(5),
without beeing too verbose.

While there, I also noted that the classful routes are obsolete. I was
wondering if we could just remove this option from the doc (and maybe
tedu the code ?) instead.

Ok, corrections, ... ?

Index: dhcp-options.5
===
RCS file: /cvs/OpenBSD/src/usr.sbin/dhcpd/dhcp-options.5,v
retrieving revision 1.22
diff -u -p -u -r1.22 dhcp-options.5
--- dhcp-options.5  14 Sep 2015 20:06:59 -  1.22
+++ dhcp-options.5  28 Feb 2018 16:16:34 -
@@ -171,6 +171,10 @@ RFC 1122.
 .It Ic option classless-static-routes Ar ip/prefix ip Oo , Ar ip/prefix ip ... 
Oc ;
 This option specifies a list of static routes in CDIR notation, which
 should be sent to the client.
+This option is specified in RFC3442.
+Note that, since the RFC says that clients supporting this option must ignore 
the
+.Ic Routers option when both are present, the default route
+needs to be included in the list of routes specified here.
 .It Ic option classless-ms-static-routes Ar ip/prefix ip Oo , Ar ip/prefix ip 
... Oc ;
 This option does the same as
 .Ic classless-static-routes ,
@@ -517,6 +521,8 @@ The default route (0.0.0.0) is an illega
 To specify the default route, use the
 .Ic routers
 option.
+Note that this option is obsolete and should be replaced by the
+.Ic classless-static-routes option.
 .It Ic option streettalk-directory-assistance-server Ar ip-address Oo , Ar 
ip-address ... Oc ;
 The StreetTalk Directory Assistance (STDA) server option specifies a
 list of STDA servers available to the client.

-- 
Matthieu Herrb

Re: times(3): return monotonically increasing values

[Scott Cheloha]

On Wed, Feb 28, 2018 at 08:58:41AM -0700, Todd C. Miller wrote:
> On Wed, 28 Feb 2018 09:46:30 -0600, Scott Cheloha wrote:
> 
> > I want to avoid giving the reader even the slightest impression that
> > the return value from times(3) can be used for anything but real-time
> > interval measurement.  Mentioning that the value is relative to the
> > system start time seems to lean in that direction.  What did you want
> > to impart by documenting that?
> 
> That's reasonable.  My only concern is that by using the word
> "arbitrary" it becomes unclear whether the returned time is consistent
> between calls.  I'm not sure how best to get that across.  Maybe
> it is not really important since this is a deprecated interface.

I know it's not customary to put extra details in RETURN VALUES, but
times(3) is a bit unwieldy.  How does the attached read?

I have some unrelated tweaks I want to make in a subsequent patch, so
maybe introducing an example then will put a nail in this coffin.

Index: lib/libc/gen/times.3
===
RCS file: /cvs/src/lib/libc/gen/times.3,v
retrieving revision 1.14
diff -u -p -r1.14 times.3
--- lib/libc/gen/times.317 Jul 2013 05:42:11 -  1.14
+++ lib/libc/gen/times.328 Feb 2018 16:21:43 -
@@ -40,20 +40,14 @@
 .Sh DESCRIPTION
 .Bf -symbolic
 This interface is obsoleted by
-.Xr getrusage 2
+.Xr clock_gettime 2
 and
-.Xr gettimeofday 2 .
+.Xr getrusage 2 .
 .Ef
 .Pp
 The
 .Fn times
-function returns the value of time in
-.Dv CLK_TCK Ns s
-of a second since
-0 hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated Universal
-Time (UTC).
-.Pp
-It also fills in the structure pointed to by
+function fills in the structure pointed to by
 .Fa tp
 with time-accounting information.
 .Pp
@@ -105,27 +99,38 @@ and
 elements of the parent when one of the
 .Xr wait 2
 functions returns the process ID of the terminated child to the parent.
-If an error occurs,
+.Sh RETURN VALUES
+Upon successful completion,
+.Fn times
+returns the value of real time,
+in
+.Dv CLK_TCK Ns s
+of a second,
+elapsed since an arbitrary point in the past.
+This point does not change between invocations of
+.Fn times
+so two such return values constitute a real time interval.
+.Pp
+On failure,
 .Fn times
-returns the value
-.Li "(clock_t)-1" ,
-and sets
+returns
+.Li "(clock_t)-1"
+and the global variable
 .Va errno
-to indicate the error.
+is set to indicate the error.
 .Sh ERRORS
 The
 .Fn times
-function may fail and set the global variable
+function may fail and set
 .Va errno
-for any of the errors specified for the library
-routines
-.Xr getrusage 2
+for any of the errors specified for
+.Xr clock_gettime 2
 and
-.Xr gettimeofday 2 .
+.Xr getrusage 2 .
 .Sh SEE ALSO
 .Xr time 1 ,
+.Xr clock_gettime 2 ,
 .Xr getrusage 2 ,
-.Xr gettimeofday 2 ,
 .Xr wait 2
 .Sh STANDARDS
 The

Re: Utility to safely edit doas.conf

[Theo de Raadt]

Yeah.

And I suppose we also need seperate programs for all the other files
in /etc?

Such as visysctl.conf, vivm.conf, vigroup, vishells, virc.conf.local,
visshd, vissh, etc

After all, someone could create unsafe configurations, and lots of handholding
is needed everywhere, yes?

I'm sorry, but I disagree.  The tooling already exists to let you do
this carefully.  It is up to people to use their brains. And your
script doesn't have any locking, so it is still error prone.

I really don't see the point of these wrappers.

>The following is a shell script to safely edit /etc/doas.conf so that you 
>avoid locking yourself out with a bad config. I managed to do this myself, so 
>thought it might be useful to a wider audience.
>
>It is inspired by the 'visudo' tool: it copies doas.conf to a temporary 
>directory then opens it in vi. When you exit vi it checks the format of the 
>config file, and if it passes then it will overwrite the original one then 
>delete the copy. If it fails a warning is shown, and the file is re-opened for 
>editing.
>
>It will not create /etc/doas.conf if it does not already exist (I could add a 
>separate warning for this if needed).
>
>diff -u /dev/null usr.bin/doas/vidoas
>--- /dev/null2018-02-22 08:14:04.607259461 +
>+++ usr.bin/doas/vidoas2018-02-28 15:50:35.358895700 +
>@@ -0,0 +1,36 @@
>+#!/bin/sh
>+
>+# $OpenBSD$
>+#
>+# Copyright (c) 2018 Anthony Perkins 
>+#
>+# 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.
>+
>+doasconf=/etc/doas.conf
>+tempfile=$(mktemp -t doas. || exit 1)
>+if [ -w $doasconf ]; then
>+cp $doasconf $tempfile
>+vi $tempfile
>+while ! doas -C $tempfile; do
>+echo "Press Enter to retry, Ctrl-C to abort."
>+read
>+vi $tempfile
>+done
>+if doas -C $tempfile; then
>+cp -f $tempfile $doasconf
>+rm -f $tempfile
>+fi
>+else
>+echo "$doasconf is not writable by this user."
>+exit 1
>+fi
>diff -u /dev/null usr.bin/doas/vidoas.1
>--- /dev/null2018-02-22 08:14:04.607259461 +
>+++ usr.bin/doas/vidoas.12018-02-28 15:31:20.825930370 +
>@@ -0,0 +1,44 @@
>+.\" $OpenBSD$
>+.\"
>+.\"Copyright (c) 2018 Anthony Perkins 
>+.\"
>+.\"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.
>+.Dd $Mdocdate: February 28 2018 $
>+.Dt VIDOAS 1
>+.Os
>+.Sh NAME
>+.Nm vidoas
>+.Nd safely edit the doas config file
>+.Sh SYNOPSIS
>+.Nm vidoas
>+.Sh DESCRIPTION
>+The
>+.Nm
>+utility edits a copy of
>+.Pa /etc/doas.conf .
>+If the copy is valid the original file will be replaced.
>+.Pp
>+This helps to prevent you from accidentally
>+locking yourself out from
>+.Xr doas 1
>+with a typo.
>+It is inspired by the
>+.Xr visudo 1
>+utility.
>+.Pp
>+This utility takes no arguments.
>+.Sh SEE ALSO
>+.Xr doas 1 ,
>+.Xr doas.conf 5
>+.Sh AUTHORS
>+.An Anthony Perkins 
>
>This is only my second ever submission, so I would appreciate any guidance. 
>I've also not yet edited the Makefile to include this in the build.
>
>All the best,
>
>Anthony
>
>--
>Anthony Perkins
>Email: anth...@acperkins.com
>OpenPGP: https://acperkins.com/openpgp
>
>

Utility to safely edit doas.conf

[Anthony Perkins]

The following is a shell script to safely edit /etc/doas.conf so that you avoid 
locking yourself out with a bad config. I managed to do this myself, so thought 
it might be useful to a wider audience.

It is inspired by the 'visudo' tool: it copies doas.conf to a temporary 
directory then opens it in vi. When you exit vi it checks the format of the 
config file, and if it passes then it will overwrite the original one then 
delete the copy. If it fails a warning is shown, and the file is re-opened for 
editing.

It will not create /etc/doas.conf if it does not already exist (I could add a 
separate warning for this if needed).

diff -u /dev/null usr.bin/doas/vidoas
--- /dev/null2018-02-22 08:14:04.607259461 +
+++ usr.bin/doas/vidoas2018-02-28 15:50:35.358895700 +
@@ -0,0 +1,36 @@
+#!/bin/sh
+
+# $OpenBSD$
+#
+# Copyright (c) 2018 Anthony Perkins 
+#
+# 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.
+
+doasconf=/etc/doas.conf
+tempfile=$(mktemp -t doas. || exit 1)
+if [ -w $doasconf ]; then
+cp $doasconf $tempfile
+vi $tempfile
+while ! doas -C $tempfile; do
+echo "Press Enter to retry, Ctrl-C to abort."
+read
+vi $tempfile
+done
+if doas -C $tempfile; then
+cp -f $tempfile $doasconf
+rm -f $tempfile
+fi
+else
+echo "$doasconf is not writable by this user."
+exit 1
+fi
diff -u /dev/null usr.bin/doas/vidoas.1
--- /dev/null2018-02-22 08:14:04.607259461 +
+++ usr.bin/doas/vidoas.12018-02-28 15:31:20.825930370 +
@@ -0,0 +1,44 @@
+.\" $OpenBSD$
+.\"
+.\"Copyright (c) 2018 Anthony Perkins 
+.\"
+.\"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.
+.Dd $Mdocdate: February 28 2018 $
+.Dt VIDOAS 1
+.Os
+.Sh NAME
+.Nm vidoas
+.Nd safely edit the doas config file
+.Sh SYNOPSIS
+.Nm vidoas
+.Sh DESCRIPTION
+The
+.Nm
+utility edits a copy of
+.Pa /etc/doas.conf .
+If the copy is valid the original file will be replaced.
+.Pp
+This helps to prevent you from accidentally
+locking yourself out from
+.Xr doas 1
+with a typo.
+It is inspired by the
+.Xr visudo 1
+utility.
+.Pp
+This utility takes no arguments.
+.Sh SEE ALSO
+.Xr doas 1 ,
+.Xr doas.conf 5
+.Sh AUTHORS
+.An Anthony Perkins 

This is only my second ever submission, so I would appreciate any guidance. 
I've also not yet edited the Makefile to include this in the build.

All the best,

Anthony

--
Anthony Perkins
Email: anth...@acperkins.com
OpenPGP: https://acperkins.com/openpgp

Re: times(3): return monotonically increasing values

[Jason McIntyre]

On Wed, Feb 28, 2018 at 09:56:14AM -0600, Scott Cheloha wrote:
> 
> One last thing: in ERRORS, the phrasing varies when we do a cross
> reference.  It's usually something like
> 
> [...] may fail and set errno for any of the errors specified for [...]
> 
> but then you have a mix of "library routines," "routines," and nothing
> qualifying the cross reference(s).  The cross references here are system
> calls, so can I just omit "library routines," or "routines," entirely?
> 

yes.

> ^ This and the fixes attached.
> 

ok by me.

jmc

> --
> Scott Cheloha
> 
> Index: lib/libc/gen/times.c
> ===
> RCS file: /cvs/src/lib/libc/gen/times.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 times.c
> --- lib/libc/gen/times.c  2 Nov 2015 17:02:37 -   1.7
> +++ lib/libc/gen/times.c  28 Feb 2018 15:53:00 -
> @@ -28,9 +28,9 @@
>   * SUCH DAMAGE.
>   */
>  
> -#include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * Convert usec to clock ticks; could do (usec * CLK_TCK) / 100,
> @@ -42,7 +42,7 @@ clock_t
>  times(struct tms *tp)
>  {
>   struct rusage ru;
> - struct timeval t;
> + struct timespec ts;
>  
>   if (getrusage(RUSAGE_SELF, ) < 0)
>   return ((clock_t)-1);
> @@ -52,7 +52,7 @@ times(struct tms *tp)
>   return ((clock_t)-1);
>   tp->tms_cutime = CONVTCK(ru.ru_utime);
>   tp->tms_cstime = CONVTCK(ru.ru_stime);
> - if (gettimeofday(, NULL))
> + if (clock_gettime(CLOCK_MONOTONIC, ) == -1)
>   return ((clock_t)-1);
> - return ((clock_t)(CONVTCK(t)));
> + return (ts.tv_sec * CLK_TCK + ts.tv_nsec / (10 / CLK_TCK));
>  }
> Index: lib/libc/gen/times.3
> ===
> RCS file: /cvs/src/lib/libc/gen/times.3,v
> retrieving revision 1.14
> diff -u -p -r1.14 times.3
> --- lib/libc/gen/times.3  17 Jul 2013 05:42:11 -  1.14
> +++ lib/libc/gen/times.3  28 Feb 2018 15:53:00 -
> @@ -40,20 +40,14 @@
>  .Sh DESCRIPTION
>  .Bf -symbolic
>  This interface is obsoleted by
> -.Xr getrusage 2
> +.Xr clock_gettime 2
>  and
> -.Xr gettimeofday 2 .
> +.Xr getrusage 2 .
>  .Ef
>  .Pp
>  The
>  .Fn times
> -function returns the value of time in
> -.Dv CLK_TCK Ns s
> -of a second since
> -0 hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated Universal
> -Time (UTC).
> -.Pp
> -It also fills in the structure pointed to by
> +function fills in the structure pointed to by
>  .Fa tp
>  with time-accounting information.
>  .Pp
> @@ -105,27 +99,32 @@ and
>  elements of the parent when one of the
>  .Xr wait 2
>  functions returns the process ID of the terminated child to the parent.
> -If an error occurs,
> +.Sh RETURN VALUES
> +Upon successful completion,
>  .Fn times
> -returns the value
> -.Li "(clock_t)-1" ,
> -and sets
> +returns the value of real time,
> +in
> +.Dv CLK_TCK Ns s
> +of a second,
> +elapsed since an arbitrary point in the past.
> +Otherwise a value of
> +.Li "(clock_t)-1"
> +is returned and the global variable
>  .Va errno
> -to indicate the error.
> +is set to indicate the error.
>  .Sh ERRORS
>  The
>  .Fn times
> -function may fail and set the global variable
> +function may fail and set
>  .Va errno
> -for any of the errors specified for the library
> -routines
> -.Xr getrusage 2
> +for any of the errors specified for
> +.Xr clock_gettime 2
>  and
> -.Xr gettimeofday 2 .
> +.Xr getrusage 2 .
>  .Sh SEE ALSO
>  .Xr time 1 ,
> +.Xr clock_gettime 2 ,
>  .Xr getrusage 2 ,
> -.Xr gettimeofday 2 ,
>  .Xr wait 2
>  .Sh STANDARDS
>  The

Re: times(3): return monotonically increasing values

[Todd C. Miller]

On Wed, 28 Feb 2018 09:46:30 -0600, Scott Cheloha wrote:

> I want to avoid giving the reader even the slightest impression that
> the return value from times(3) can be used for anything but real-time
> interval measurement.  Mentioning that the value is relative to the
> system start time seems to lean in that direction.  What did you want
> to impart by documenting that?

That's reasonable.  My only concern is that by using the word
"arbitrary" it becomes unclear whether the returned time is consistent
between calls.  I'm not sure how best to get that across.  Maybe
it is not really important since this is a deprecated interface.

 - todd

Re: times(3): return monotonically increasing values

[Scott Cheloha]

On Tue, Feb 27, 2018 at 07:15:03AM +, Jason McIntyre wrote:
> On Mon, Feb 26, 2018 at 07:12:20PM -0600, Scott Cheloha wrote:
> 
> [...]
> 
> > [...]
> > 
> > I don't have access to 1003.1-1988 [1] (the most recent standard
> > cited in times.3).  Has the description changed much?
> > 
> 
> it could be that the reference is out of date. but i don;t know
> personally which revision we expect this to conform to.
> 
> you can access (and download) various versions of posix spec online.

I'll look further.

> > [...]
> > @@ -105,27 +99,33 @@ and
> >  elements of the parent when one of the
> >  .Xr wait 2
> >  functions returns the process ID of the terminated child to the parent.
> > -If an error occurs,
> > +.Sh RETURN VALUES
> > +Upon successful completion,
> >  .Fn times
> > -returns the value
> > +returns the value of real time,
> > +in
> > +.Dv CLK_TCK Ns s
> > +of a second,
> > +elapsed since an arbitrary point in the past.
> > +Otherwise a value of 
> 
> you have trailing whitespace at eol above. run man changes through
> mandoc -Tlint...

Didn't know about -Tlint, sure thing in the future.

> >  .Li "(clock_t)-1" ,
> 
> you don;t want the comma
> 
> otherwise the changes read fine.

Cool.

One last thing: in ERRORS, the phrasing varies when we do a cross
reference.  It's usually something like

[...] may fail and set errno for any of the errors specified for [...]

but then you have a mix of "library routines," "routines," and nothing
qualifying the cross reference(s).  The cross references here are system
calls, so can I just omit "library routines," or "routines," entirely?

^ This and the fixes attached.

--
Scott Cheloha

Index: lib/libc/gen/times.c
===
RCS file: /cvs/src/lib/libc/gen/times.c,v
retrieving revision 1.7
diff -u -p -r1.7 times.c
--- lib/libc/gen/times.c2 Nov 2015 17:02:37 -   1.7
+++ lib/libc/gen/times.c28 Feb 2018 15:53:00 -
@@ -28,9 +28,9 @@
  * SUCH DAMAGE.
  */
 
-#include 
 #include 
 #include 
+#include 
 
 /*
  * Convert usec to clock ticks; could do (usec * CLK_TCK) / 100,
@@ -42,7 +42,7 @@ clock_t
 times(struct tms *tp)
 {
struct rusage ru;
-   struct timeval t;
+   struct timespec ts;
 
if (getrusage(RUSAGE_SELF, ) < 0)
return ((clock_t)-1);
@@ -52,7 +52,7 @@ times(struct tms *tp)
return ((clock_t)-1);
tp->tms_cutime = CONVTCK(ru.ru_utime);
tp->tms_cstime = CONVTCK(ru.ru_stime);
-   if (gettimeofday(, NULL))
+   if (clock_gettime(CLOCK_MONOTONIC, ) == -1)
return ((clock_t)-1);
-   return ((clock_t)(CONVTCK(t)));
+   return (ts.tv_sec * CLK_TCK + ts.tv_nsec / (10 / CLK_TCK));
 }
Index: lib/libc/gen/times.3
===
RCS file: /cvs/src/lib/libc/gen/times.3,v
retrieving revision 1.14
diff -u -p -r1.14 times.3
--- lib/libc/gen/times.317 Jul 2013 05:42:11 -  1.14
+++ lib/libc/gen/times.328 Feb 2018 15:53:00 -
@@ -40,20 +40,14 @@
 .Sh DESCRIPTION
 .Bf -symbolic
 This interface is obsoleted by
-.Xr getrusage 2
+.Xr clock_gettime 2
 and
-.Xr gettimeofday 2 .
+.Xr getrusage 2 .
 .Ef
 .Pp
 The
 .Fn times
-function returns the value of time in
-.Dv CLK_TCK Ns s
-of a second since
-0 hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated Universal
-Time (UTC).
-.Pp
-It also fills in the structure pointed to by
+function fills in the structure pointed to by
 .Fa tp
 with time-accounting information.
 .Pp
@@ -105,27 +99,32 @@ and
 elements of the parent when one of the
 .Xr wait 2
 functions returns the process ID of the terminated child to the parent.
-If an error occurs,
+.Sh RETURN VALUES
+Upon successful completion,
 .Fn times
-returns the value
-.Li "(clock_t)-1" ,
-and sets
+returns the value of real time,
+in
+.Dv CLK_TCK Ns s
+of a second,
+elapsed since an arbitrary point in the past.
+Otherwise a value of
+.Li "(clock_t)-1"
+is returned and the global variable
 .Va errno
-to indicate the error.
+is set to indicate the error.
 .Sh ERRORS
 The
 .Fn times
-function may fail and set the global variable
+function may fail and set
 .Va errno
-for any of the errors specified for the library
-routines
-.Xr getrusage 2
+for any of the errors specified for
+.Xr clock_gettime 2
 and
-.Xr gettimeofday 2 .
+.Xr getrusage 2 .
 .Sh SEE ALSO
 .Xr time 1 ,
+.Xr clock_gettime 2 ,
 .Xr getrusage 2 ,
-.Xr gettimeofday 2 ,
 .Xr wait 2
 .Sh STANDARDS
 The

Re: times(3): return monotonically increasing values

[Scott Cheloha]

On Tue, Feb 27, 2018 at 11:38:07AM -0700, Todd C. Miller wrote:
> On Mon, 26 Feb 2018 19:12:20 -0600, Scott Cheloha wrote:
> 
> > Reading the latest POSIX description for times(3):
> >
> > > Upon successful completion, times() shall return the elapsed
> > > real time, in clock ticks, since an arbitrary point in the past
> > > (for example, system start-up time). This point does not change
> > > from one invocation of times() within the process to another.
> >
> > it seems to me that times(3) is meant to return a monotonically
> > increasing value.
> >
> > All other uses I've ever seen don't suggest a different understanding
> > by other application developers.  There aren't many left in base, but
> > gnu/usr.bin/gcc/gcc/timevar.c seems to support this.
> >
> > I don't have access to 1003.1-1988 [1] (the most recent standard
> > cited in times.3).  Has the description changed much?
> >
> > But, so, with this patch we use CLOCK_MONOTONIC to derive the return
> > value and update the manpage to reflect that.  While here, add a
> > RETURN VALUES section like every other library function page and reword
> > things to look like other library function pages (did my best).
> 
> This is fine with me.  I'd be tempted to mention that on OpenBSD
> the return value is relative to system start time but I don't think
> it makes much difference since it is an implementation detail.

I want to avoid giving the reader even the slightest impression that
the return value from times(3) can be used for anything but real-time
interval measurement.  Mentioning that the value is relative to the
system start time seems to lean in that direction.  What did you want
to impart by documenting that?

-Scott

Re: unhandled firmware response in iwm

[Jan Schreiber]

On 02/28/18 15:35, Stefan Sperling wrote:
> On Tue, Feb 27, 2018 at 10:55:05AM +0100, Jan Schreiber wrote:
>> On 02/27/18 09:06, Stefan Sperling wrote:
>>> On Mon, Feb 26, 2018 at 11:55:34PM +0100, j...@posteo.de wrote:
 When connecting to a wifi network messages like "iwm0: unhandled firmware
 response 0xff/0xb810 rx ring" appear.
 After looking at https://patchwork.kernel.org/patch/9869017/ I came up with
 following patch.
 The link also explains what is happening.
>>>
>>> Thanks for this!
>>>
 I'm not sure if it makes sense to log the firmware responses like the linux
 kernel does.
 They don't appear to have any negative effect so I decided against it.
>>>
>>> Agreed. There is no point in logging this.
>>>
>>> There are two problems with your diff:
>>>
>>> The first is that somehow it got corrupted (whitespace got mangled, lines
>>> got wrapped which shouldn't have been). Please check your mailer settings.
>>> Tip: You can mail a diff to yourself and then try to apply it until you've
>>> figured out how to make your mail client work right. I've quoted the diff
>>> I received below as-is, so if you save this mail body and feed it into
>>> patch(1) you will see what problems I saw.
>>> In this particular instance it's not a huge burden because the diff adds
>>> just 3 lines, but I basically had to rewrite your patch from scratch to
>>> apply it, which is no fun, especially for larger diffs.
>>
>> Sorry for that. Seems my config was eaten. Again.
> 
> This new diff is still broken (looks like tabs got converted to spaces)?
> You obviously didn't try to send a diff to yourself first :(

Sorry for the inconvenience. Thank you for the extra work!

> 
> I am just going to apply it manually now. But please invest time into
> fixing this properly before submitting any more diffs.
> For every diff you send out there is a potential amount of N people who will
> try to test it. Problems like this are just distracting and a waste of time
> for anyone volunteering some of their own time to try to help you.
> 
> Regardless, I am very grateful for the work you did in tracking this down.
> This has been a long-standing problem and you've provided the missing link
> to information which allowed us to understand why it happened.
> 
> |diff --git sys/dev/pci/if_iwm.c sys/dev/pci/if_iwm.c
> |index 476c61f0b3d..af3eeb76978 100644
> |--- sys/dev/pci/if_iwm.c
> |+++ sys/dev/pci/if_iwm.c
> --
> Patching file if_iwm.c using Plan A...
> Hunk #1 failed at 7316.
> 1 out of 1 hunks failed--saving rejects to if_iwm.c.rej
> Hmm...  The next patch looks like a unified diff to me...
> The text leading up to this was:
> --
> |diff --git sys/dev/pci/if_iwmreg.h sys/dev/pci/if_iwmreg.h
> |index 3c5cfea7b23..06eef017015 100644
> |--- sys/dev/pci/if_iwmreg.h
> |+++ sys/dev/pci/if_iwmreg.h
> --
> Patching file if_iwmreg.h using Plan A...
> Hunk #1 failed at 1813.
> Hunk #2 failed at 5823.
> 2 out of 2 hunks failed--saving rejects to if_iwmreg.h.rej
> Hmm...  Ignoring the trailing garbage.
> done
> 
> 
>>> The next problem: You're catching this notification in a case block which
>>> handles commands we expect to get a response for, but we don't even want
>>> to parse the data contained in this notification.
>>> I think it would be better to move it to a different case: block which just
>>> does a 'break;'. There should be some of those already so you could add it
>>> there, or you could introduce a new case: block, whichever you prefer.
>>
>> I moved the catch which is marked as ignored. Thanks for the review!
>>
>> diff --git sys/dev/pci/if_iwm.c sys/dev/pci/if_iwm.c
>> index 476c61f0b3d..af3eeb76978 100644
>> --- sys/dev/pci/if_iwm.c
>> +++ sys/dev/pci/if_iwm.c
>> @@ -7316,6 +7316,10 @@ iwm_notif_intr(struct iwm_softc *sc)
>> break;
>> }
>>  
>> +   case IWM_WIDE_ID(IWM_SYSTEM_GROUP,
>> +   IWM_FSEQ_VER_MISMATCH_NOTIFICATION):
>> +   break;
>> +
>> /*
>>  * Firmware versions 21 and 22 generate some DEBUG_LOG_MSG
>>  * messages. Just ignore them for now.
>> diff --git sys/dev/pci/if_iwmreg.h sys/dev/pci/if_iwmreg.h
>> index 3c5cfea7b23..06eef017015 100644
>> --- sys/dev/pci/if_iwmreg.h
>> +++ sys/dev/pci/if_iwmreg.h
>> @@ -1813,6 +1813,9 @@ struct iwm_agn_scd_bc_tbl {
>>  #define IWM_NET_DETECT_HOTSPOTS_CMD0x58
>>  #define IWM_NET_DETECT_HOTSPOTS_QUERY_CMD  0x59
>>  
>> +/* system group command IDs */
>> +#define IWM_FSEQ_VER_MISMATCH_NOTIFICATION 0xff
>> +
>>  #define IWM_REPLY_MAX  0xff
>>  
>>  /**
>> @@ -5820,6 +5823,7 @@ iwm_cmd_id(uint8_t opcode, uint8_t groupid, uint8_t 
>> version)
>>  
>>  /* due to the conversion, this group is special */
>>  #define IWM_ALWAYS_LONG_GROUP  1
>> +#define IWM_SYSTEM_GROUP   4
>>  
>>  struct iwm_cmd_header {
>> uint8_t code;
>>

Re: unhandled firmware response in iwm

[Stefan Sperling]

On Tue, Feb 27, 2018 at 10:55:05AM +0100, Jan Schreiber wrote:
> On 02/27/18 09:06, Stefan Sperling wrote:
> > On Mon, Feb 26, 2018 at 11:55:34PM +0100, j...@posteo.de wrote:
> >> When connecting to a wifi network messages like "iwm0: unhandled firmware
> >> response 0xff/0xb810 rx ring" appear.
> >> After looking at https://patchwork.kernel.org/patch/9869017/ I came up with
> >> following patch.
> >> The link also explains what is happening.
> > 
> > Thanks for this!
> > 
> >> I'm not sure if it makes sense to log the firmware responses like the linux
> >> kernel does.
> >> They don't appear to have any negative effect so I decided against it.
> > 
> > Agreed. There is no point in logging this.
> > 
> > There are two problems with your diff:
> > 
> > The first is that somehow it got corrupted (whitespace got mangled, lines
> > got wrapped which shouldn't have been). Please check your mailer settings.
> > Tip: You can mail a diff to yourself and then try to apply it until you've
> > figured out how to make your mail client work right. I've quoted the diff
> > I received below as-is, so if you save this mail body and feed it into
> > patch(1) you will see what problems I saw.
> > In this particular instance it's not a huge burden because the diff adds
> > just 3 lines, but I basically had to rewrite your patch from scratch to
> > apply it, which is no fun, especially for larger diffs.
> 
> Sorry for that. Seems my config was eaten. Again.

This new diff is still broken (looks like tabs got converted to spaces)?
You obviously didn't try to send a diff to yourself first :(

I am just going to apply it manually now. But please invest time into
fixing this properly before submitting any more diffs.
For every diff you send out there is a potential amount of N people who will
try to test it. Problems like this are just distracting and a waste of time
for anyone volunteering some of their own time to try to help you.

Regardless, I am very grateful for the work you did in tracking this down.
This has been a long-standing problem and you've provided the missing link
to information which allowed us to understand why it happened.

|diff --git sys/dev/pci/if_iwm.c sys/dev/pci/if_iwm.c
|index 476c61f0b3d..af3eeb76978 100644
|--- sys/dev/pci/if_iwm.c
|+++ sys/dev/pci/if_iwm.c
--
Patching file if_iwm.c using Plan A...
Hunk #1 failed at 7316.
1 out of 1 hunks failed--saving rejects to if_iwm.c.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|diff --git sys/dev/pci/if_iwmreg.h sys/dev/pci/if_iwmreg.h
|index 3c5cfea7b23..06eef017015 100644
|--- sys/dev/pci/if_iwmreg.h
|+++ sys/dev/pci/if_iwmreg.h
--
Patching file if_iwmreg.h using Plan A...
Hunk #1 failed at 1813.
Hunk #2 failed at 5823.
2 out of 2 hunks failed--saving rejects to if_iwmreg.h.rej
Hmm...  Ignoring the trailing garbage.
done


> > The next problem: You're catching this notification in a case block which
> > handles commands we expect to get a response for, but we don't even want
> > to parse the data contained in this notification.
> > I think it would be better to move it to a different case: block which just
> > does a 'break;'. There should be some of those already so you could add it
> > there, or you could introduce a new case: block, whichever you prefer.
> 
> I moved the catch which is marked as ignored. Thanks for the review!
> 
> diff --git sys/dev/pci/if_iwm.c sys/dev/pci/if_iwm.c
> index 476c61f0b3d..af3eeb76978 100644
> --- sys/dev/pci/if_iwm.c
> +++ sys/dev/pci/if_iwm.c
> @@ -7316,6 +7316,10 @@ iwm_notif_intr(struct iwm_softc *sc)
> break;
> }
>  
> +   case IWM_WIDE_ID(IWM_SYSTEM_GROUP,
> +   IWM_FSEQ_VER_MISMATCH_NOTIFICATION):
> +   break;
> +
> /*
>  * Firmware versions 21 and 22 generate some DEBUG_LOG_MSG
>  * messages. Just ignore them for now.
> diff --git sys/dev/pci/if_iwmreg.h sys/dev/pci/if_iwmreg.h
> index 3c5cfea7b23..06eef017015 100644
> --- sys/dev/pci/if_iwmreg.h
> +++ sys/dev/pci/if_iwmreg.h
> @@ -1813,6 +1813,9 @@ struct iwm_agn_scd_bc_tbl {
>  #define IWM_NET_DETECT_HOTSPOTS_CMD0x58
>  #define IWM_NET_DETECT_HOTSPOTS_QUERY_CMD  0x59
>  
> +/* system group command IDs */
> +#define IWM_FSEQ_VER_MISMATCH_NOTIFICATION 0xff
> +
>  #define IWM_REPLY_MAX  0xff
>  
>  /**
> @@ -5820,6 +5823,7 @@ iwm_cmd_id(uint8_t opcode, uint8_t groupid, uint8_t 
> version)
>  
>  /* due to the conversion, this group is special */
>  #define IWM_ALWAYS_LONG_GROUP  1
> +#define IWM_SYSTEM_GROUP   4
>  
>  struct iwm_cmd_header {
> uint8_t code;
>