Re: speaker(4): unhook driver and manpage from build

2022-04-29 Thread Jeremie Courreges-Anglas
On Thu, Apr 28 2022, Scott Cheloha  wrote:
> speaker(4) is a whimsical thing, but I don't think we should have a
> dedicated chiptune interpreter in the kernel.

> This patch unhooks the driver and the manpage from the build.  The
> driver is built for alpha, amd64, and i386.
>
> A subsequent patch will move all relevant files to the attic and clean
> up manpage cross references.
>
> Nothing in base or xenocara includes .
>
> I see a couple SPKRTONE and SPKRTUNE symbols in ports, but I imagine
> those ports don't use the symbols if they are missing.
>
> ok?

People seem to find this useful, for real world use cases.  Is there
a technical reason to delete it besides "this doesn't belong here"?

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: ddb: simplify "machine" command handling

2022-04-11 Thread Jeremie Courreges-Anglas
On Mon, Apr 11 2022, Christian Weisgerber  wrote:
> Christian Weisgerber:
>
>> This will allow constifying the ddb command tables in a subsequent
>> step.
>
> And here's that boring follow-up diff.

sparc64 and riscv64 GENERIC and GENERIC.MP build successfully with this
diff and the previous one, "machine" behaves as expected in ddb(4).

ok jca@

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: gpio: Add missing device_unref()

2022-04-10 Thread Jeremie Courreges-Anglas
On Sun, Apr 10 2022, Visa Hankala  wrote:
> Make gpio(4) release the device reference that device_lookup() takes.
>
> OK?

ok jca@

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: [PATCH] [src] usr.bin/sendbug/sendbug.c - update categories

2022-04-10 Thread Jeremie Courreges-Anglas
On Tue, Mar 29 2022, Theo Buehler  wrote:
> On Tue, Mar 29, 2022 at 08:51:25PM +0200, Jeremie Courreges-Anglas wrote:
>> On Tue, Mar 29 2022, Raf Czlonka  wrote:
>> > Hello,
>> >
>> > sparc and vax ports have been retired a while back; add riscv64
>> > while there.
>> 
>> Committed, thanks.
>> 
>> There are more missing entries I think.  If I follow the existing
>> pattern, naming the cpu architectures and not the platforms:
>> - aarch64 is missing
>> - powerpc64 is missing
>> - mips64el is missing
>
> Perhaps we can ditch the architectures list that seems to have been out
> of sync more often than not

For now I have synced the architectures list.

> and reduce categories to something like
> these?
>
>   documentation userland kernel
>
> If somebody is smart enough to narrow a bug down to something
> arch-specific, they're hopefully smart enough to mention that in their
> bug report.

I think such a move would make sense but I'm unsure about the details.
Removing "library" may not be a problem.  But removing "system" means
that users have to think hard whether the problem lies in kernel or
userland, when the problem may lie between both, or generally be hard to
classify.

Thoughts?

>> and after folding the line because of line wrapping:
>> 
>> ok?
>> 
>> 
>> Index: sendbug.c
>> ===
>> RCS file: /cvs/src/usr.bin/sendbug/sendbug.c,v
>> retrieving revision 1.79
>> diff -u -p -r1.79 sendbug.c
>> --- sendbug.c29 Mar 2022 18:44:12 -  1.79
>> +++ sendbug.c29 Mar 2022 18:49:41 -
>> @@ -44,7 +44,8 @@ void   template(FILE *);
>>  voidusbdevs(FILE *);
>>  
>>  const char *categories = "system user library documentation kernel "
>> -"alpha amd64 arm hppa i386 m88k mips64 powerpc riscv64 sh sparc64";
>> +"alpha aarch64 amd64 arm hppa i386 m88k mips64 mips64el powerpc 
>> powerpc64 "
>> +"riscv64 sh sparc64";
>>  const char *comment[] = {
>>  "",
>>  "",
>> 
>> -- 
>> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
>> 
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: [diff] gzip verbose message

2022-04-10 Thread Jeremie Courreges-Anglas
On Wed, Apr 06 2022, prx  wrote:
> Since gzip has -k flag to keep original file, the output when used with -v 
> flag is wrong.
>
> Find below a stupid diff almost shorter than this message.
>
> Regards
>
> Index: main.c
> ===
> RCS file: /cvs/src/usr.bin/compress/main.c,v
> retrieving revision 1.99
> diff -u -r1.99 main.c
> --- main.c14 Mar 2022 21:52:08 -  1.99
> +++ main.c6 Apr 2022 12:49:51 -
> @@ -932,7 +932,7 @@
>   return;
>   }
>   if (!pipin) {
> - fprintf(stderr, "\t%4.1f%% -- replaced with %s\n",
> + fprintf(stderr, "\t%4.1f%% -- compressed to %s\n",
>   (uncompressed - compressed) * 100.0 / uncompressed, file);
>   }
>   compressed += hlen;
>

The diff below keeps the same output by default and outputs the same as
GNU gzip(1) is -k is given.

ok?


Index: main.c
===
RCS file: /home/cvs/src/usr.bin/compress/main.c,v
retrieving revision 1.99
diff -u -p -p -u -r1.99 main.c
--- main.c  14 Mar 2022 21:52:08 -  1.99
+++ main.c  10 Apr 2022 11:10:43 -
@@ -53,6 +53,7 @@
 enum program_mode pmode;
 
 int cat, decomp, pipin, force, verbose, testmode, list, recurse, storename;
+int kflag;
 extern char *__progname;
 
 const struct compressor {
@@ -167,12 +168,12 @@ main(int argc, char *argv[])
const char *optstr, *s;
char *p, *infile;
char outfile[PATH_MAX], _infile[PATH_MAX], suffix[16];
-   int bits, ch, error, rc, cflag, kflag, oflag;
+   int bits, ch, error, rc, cflag, oflag;
 
if (pledge("stdio rpath wpath cpath fattr chown", NULL) == -1)
err(1, "pledge");
 
-   bits = cflag = kflag = oflag = 0;
+   bits = cflag = oflag = 0;
storename = -1;
p = __progname;
if (p[0] == 'g') {
@@ -932,8 +933,9 @@ verbose_info(const char *file, off_t com
return;
}
if (!pipin) {
-   fprintf(stderr, "\t%4.1f%% -- replaced with %s\n",
-   (uncompressed - compressed) * 100.0 / uncompressed, file);
+   fprintf(stderr, "\t%4.1f%% -- %s %s\n",
+   (uncompressed - compressed) * 100.0 / uncompressed,
+   kflag ? "created" : "replaced with", file);
}
compressed += hlen;
fprintf(stderr, "%lld bytes in, %lld bytes out\n",

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: [PATCH] [src] usr.bin/sendbug/sendbug.c - update categories

2022-03-29 Thread Jeremie Courreges-Anglas
On Tue, Mar 29 2022, Raf Czlonka  wrote:
> Hello,
>
> sparc and vax ports have been retired a while back; add riscv64
> while there.

Committed, thanks.

There are more missing entries I think.  If I follow the existing
pattern, naming the cpu architectures and not the platforms:
- aarch64 is missing
- powerpc64 is missing
- mips64el is missing

and after folding the line because of line wrapping:

ok?


Index: sendbug.c
===
RCS file: /cvs/src/usr.bin/sendbug/sendbug.c,v
retrieving revision 1.79
diff -u -p -r1.79 sendbug.c
--- sendbug.c   29 Mar 2022 18:44:12 -  1.79
+++ sendbug.c   29 Mar 2022 18:49:41 -
@@ -44,7 +44,8 @@ void  template(FILE *);
 void   usbdevs(FILE *);
 
 const char *categories = "system user library documentation kernel "
-"alpha amd64 arm hppa i386 m88k mips64 powerpc riscv64 sh sparc64";
+"alpha aarch64 amd64 arm hppa i386 m88k mips64 mips64el powerpc powerpc64 "
+"riscv64 sh sparc64";
 const char *comment[] = {
"",
"",

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



riscv64: chatty SIGILL printf

2022-03-22 Thread Jeremie Courreges-Anglas


Just like breakpoints, SIGILL shouldn't print anything.  FWIW this seems
to only happen once in a ports bulk build.

ok?


Index: trap.c
===
RCS file: /home/cvs/src/sys/arch/riscv64/riscv64/trap.c,v
retrieving revision 1.17
diff -u -p -p -u -r1.17 trap.c
--- trap.c  3 Sep 2021 14:58:25 -   1.17
+++ trap.c  22 Mar 2022 21:42:23 -
@@ -153,8 +153,6 @@ do_trap_user(struct trapframe *frame)
fpu_load(p);
break;
}
-   printf("ILL at %lx scause %lx stval %lx\n", frame->tf_sepc,
-   frame->tf_scause, frame->tf_stval);
sv.sival_ptr = (void *)frame->tf_stval;
trapsignal(p, SIGILL, 0, ILL_ILLTRP, sv);
break;


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: fix multiple iwm/iwx interfaces

2022-03-16 Thread Jeremie Courreges-Anglas
On Mon, Mar 14 2022, Stefan Sperling  wrote:
> It is currently impossible to use more than one iwm or iwx interface
> in a system because I don't understand C.
>
> Trying to bring up an uninitialized interface anyway results in a
> kernel panic ("bogus channel pointer" from net80211), so prevent
> the device from being used in case we never managed to initialize it.
>
> ok?

I only tested iwm(4) 8265 but the change makes sense, ok jca@

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: add -k / --keep for gzip(1)

2022-03-13 Thread Jeremie Courreges-Anglas
On Sat, Mar 12 2022, Solene Rapenne  wrote:
> On Sat, 12 Mar 2022 15:49:40 +0100
> Solene Rapenne :
>
>> On Sat, 05 Mar 2022 19:15:02 -0700
>> "Todd C. Miller" :
>> 
>> > On Sun, 06 Mar 2022 02:58:30 +0100, Jeremie Courreges-Anglas wrote:
>> >   
>> > > I'm not sure what you mean here.  Solene's diff added -k to both
>> > > compress(1) and gzip(1) (and their uncompressor counterparts).
>> > > Adding -k to gzip/gunzip only would indeed make the usage() slightly
>> > > more complicated.
>> > >
>> > > So do we want to add -k to compress(1) or not?  (No strong opinion.)
>> > >
>> > > I like the general idea and the diff seems to work as intended.
>> > 
>> > I don't really care whether or not we add -k to compress(1).  However,
>> > since other versions of compress do not have a -k option it is
>> > probably best to avoiding adding it.
>> > 
>> >  - todd  
>> 
>> here is a new version that doesn't add -k to compress and uncompress
>> 
>> gzip -k and gunzip -k works as expected
>> compress -k and uncompress -k will display unknown option -- k and
>> show the usage that doesn't show k flag
>
> as millert@ told me, I forgot to update the usage, new diff

Works fine.  Here's an updated diff with suggestions:
- "k" was not completely removed from compress's struct compressor opt
  string, and was not needed in null_method
- try to keep the *flag variables ordered
- rework the condition that decides whether we unlink and print
  a warning message.  I found the existing code not much readable with
  a chain of flags check, a syscall and another flag check.
  Also the new line was over 80 chars.
- adding "k" to usage can be made shorter since "L" is next to "k"

If you like those changes, ok jca@


Index: gzip.1
===
RCS file: /home/cvs/src/usr.bin/compress/gzip.1,v
retrieving revision 1.14
diff -u -p -r1.14 gzip.1
--- gzip.1  7 Oct 2014 21:06:30 -   1.14
+++ gzip.1  13 Mar 2022 11:47:00 -
@@ -43,13 +43,13 @@
 .Nd compress and expand data (deflate mode)
 .Sh SYNOPSIS
 .Nm gzip
-.Op Fl 123456789cdfhLlNnOqrtVv
+.Op Fl 123456789cdfhkLlNnOqrtVv
 .Op Fl b Ar bits
 .Op Fl o Ar filename
 .Op Fl S Ar suffix
 .Op Ar
 .Nm gunzip
-.Op Fl cfhLlNnqrtVv
+.Op Fl cfhkLlNnqrtVv
 .Op Fl o Ar filename
 .Op Ar
 .Nm gzcat
@@ -183,6 +183,8 @@ behave as
 .Xr cat 1 .
 .It Fl h
 Print a short help message.
+.It Fl k
+Keep input files after compression or decompression.
 .It Fl L
 A no-op which exists for compatibility only.
 On GNU gzip, it displays the program's license.
Index: main.c
===
RCS file: /home/cvs/src/usr.bin/compress/main.c,v
retrieving revision 1.98
diff -u -p -r1.98 main.c
--- main.c  18 Jan 2021 00:46:58 -  1.98
+++ main.c  13 Mar 2022 12:04:05 -
@@ -75,8 +75,8 @@ const struct compressor {
"deflate",
".gz",
"\037\213",
-   "123456789ab:cdfhLlNnOo:qrS:tVv",
-   "cfhLlNno:qrtVv",
+   "123456789ab:cdfhkLlNnOo:qrS:tVv",
+   "cfhkLlNno:qrtVv",
"fhqr",
gz_ropen,
gz_read,
@@ -141,6 +141,7 @@ const struct option longopts[] = {
{ "uncompress", no_argument,0, 'd' },
{ "force",  no_argument,0, 'f' },
{ "help",   no_argument,0, 'h' },
+   { "keep",   no_argument,0, 'k' },
{ "list",   no_argument,0, 'l' },
{ "license",no_argument,0, 'L' },
{ "no-name",no_argument,0, 'n' },
@@ -166,12 +167,12 @@ main(int argc, char *argv[])
const char *optstr, *s;
char *p, *infile;
char outfile[PATH_MAX], _infile[PATH_MAX], suffix[16];
-   int bits, ch, error, rc, cflag, oflag;
+   int bits, ch, error, rc, cflag, kflag, oflag;
 
if (pledge("stdio rpath wpath cpath fattr chown", NULL) == -1)
err(1, "pledge");
 
-   bits = cflag = oflag = 0;
+   bits = cflag = kflag = oflag = 0;
storename = -1;
p = __progname;
if (p[0] == 'g') {
@@ -276,6 +277,9 @@ main(int argc, char *argv[])
strlcpy(suffix, method->suffix, sizeof(suffix));
bits = 6;
break;
+   case 'k':
+   kflag = 1;
+   break;
ca

Re: riscv64: ld.lld is too picky on ABI mismatch

2022-03-09 Thread Jeremie Courreges-Anglas
On Mon, Oct 25 2021, Jeremie Courreges-Anglas  wrote:
> On Mon, Oct 25 2021, Patrick Wildt  wrote:
>> Am Mon, Oct 25, 2021 at 11:43:55AM +0200 schrieb Mark Kettenis:
>>> > From: Jeremie Courreges-Anglas 
>>> > Date: Sun, 24 Oct 2021 17:30:46 +0100
>>> > 
>>> > clang(1) defaults to FP ABI but ld(1) -melf64lriscv doesn't.  This is
>>> > a problem as soon as a port tries to use raw ld(1) -b binary to embed
>>> > data in a .o file.
>>> > 
>>> > Downgrading this hard error to a warning seems more useful as far as the
>>> > ports tree is concerned.  The diff below fixes
>>> > databases/postgresql-pllua and should also fix textproc/mupdf and 
>>> > net/utox.
>>> > 
>>> > There's another diff here: https://reviews.llvm.org/D106378
>>> > but it's slightly more complicated and it received seemingly negative
>>> > feedback.  So I'm just using a minimal change to fit our needs.
>>> > 
>>> > ok?
>>> 
>>> I think we should try to avoid deviating from upstream as much as
>>> possible.  And I agree with the folks who argue that the mismatching
>>> objects are created with the wrong tools.
>
> Well the only alternative they suggest is using assembly and .incbin.
> Maybe that works for the FreeBSD folks working on low-level stuff, but
> not so much as a general purpose tool to include binary data in builds.
>
>>> But if mortimer@ and
>>> patrick@ can deal with carrying this local modification I won't
>>> object.
>
> I can't speak for them but given the local changes we have in clang and
> lld land this two lines diff doesn't seem daunting. ;)
>
>> Well, I was about to send an LLVM 13 diff... so can we revisit this diff
>> when we're updated to LLVM 13?

I have added comments on https://reviews.llvm.org/D106378#3219454 but
the discussion has stalled again (I'll try to revive it).

I'm still using the diff below on the riscv64 ports build machines, and
I'd like to get rid of the burden of keeping it in my tree.

ok?


Index: ELF/Arch/RISCV.cpp
===
RCS file: /cvs/src/gnu/llvm/lld/ELF/Arch/RISCV.cpp,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 RISCV.cpp
--- ELF/Arch/RISCV.cpp  17 Dec 2021 12:25:02 -  1.1.1.3
+++ ELF/Arch/RISCV.cpp  28 Jan 2022 09:11:18 -
@@ -124,8 +124,8 @@ uint32_t RISCV::calcEFlags() const {
   target |= EF_RISCV_RVC;
 
 if ((eflags & EF_RISCV_FLOAT_ABI) != (target & EF_RISCV_FLOAT_ABI))
-  error(toString(f) +
-": cannot link object files with different floating-point ABI");
+  warn(toString(f) +
+": linking object files with different floating-point ABI");
 
 if ((eflags & EF_RISCV_RVE) != (target & EF_RISCV_RVE))
   error(toString(f) +


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: Add kernel stack trace saving for riscv64

2022-03-08 Thread Jeremie Courreges-Anglas
On Tue, Mar 08 2022, Visa Hankala  wrote:
> This patch adds kernel stack trace saving for riscv64, for the benefit
> of dt(4) and witness(4).

Nice!

> The unwinder is slow because of the symbol
> lookup, but this can be tweaked later.

A dumb approach that appears to work: add
cpu_exception_handler_supervisor_end and cpu_exception_handler_user_end
symbols, and perform a range check.

> The limit variable prevents the unwinder from using user-controllable
> register values. The limit has to reflect the kernel stack setup in
> cpu_fork(). To ensure consistency, the stack start address is stored
> in a variable in struct pcb.
>
> OK?

Works for me on the Unmatched with dt(4), thanks.  ok jca@ fwiw

> Index: arch/riscv64/include/pcb.h
> ===
> RCS file: src/sys/arch/riscv64/include/pcb.h,v
> retrieving revision 1.3
> diff -u -p -r1.3 pcb.h
> --- arch/riscv64/include/pcb.h30 Jun 2021 22:20:56 -  1.3
> +++ arch/riscv64/include/pcb.h8 Mar 2022 16:54:58 -
> @@ -39,5 +39,6 @@ struct pcb {
>  
>   caddr_t pcb_onfault;// On fault handler
>   struct fpregpcb_fpstate;// Floating Point state */
> + register_t  pcb_kstack; /* kernel stack address */
>  };
>  #endif   /* _MACHINE_PCB_H_ */
> Index: arch/riscv64/riscv64/db_trace.c
> ===
> RCS file: src/sys/arch/riscv64/riscv64/db_trace.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 db_trace.c
> --- arch/riscv64/riscv64/db_trace.c   22 Feb 2022 07:46:04 -  1.5
> +++ arch/riscv64/riscv64/db_trace.c   8 Mar 2022 16:54:58 -
> @@ -141,3 +141,56 @@ db_stack_trace_print(db_expr_t addr, int
>   }
>   (*pr)("end trace frame: 0x%lx, count: %d\n", frame, count);
>  }
> +
> +void
> +stacktrace_save_at(struct stacktrace *st, unsigned int skip)
> +{
> + struct callframe *frame, *lastframe, *limit;
> + struct pcb *pcb = curpcb;
> + Elf_Sym *sym;
> + db_expr_t diff;
> + vaddr_t ra, subr;
> +
> + st->st_count = 0;
> +
> + if (pcb == NULL)
> + return;
> +
> + ra = (vaddr_t)__builtin_return_address(0);
> + frame = (struct callframe *)__builtin_frame_address(0);
> + KASSERT(INKERNEL(frame));
> + limit = (struct callframe *)((struct trapframe *)pcb->pcb_kstack - 1);
> +
> + while (st->st_count < STACKTRACE_MAX) {
> + if (skip == 0)
> + st->st_pc[st->st_count++] = ra;
> + else
> + skip--;
> +
> + sym = db_search_symbol(ra, DB_STGY_PROC, );
> + if (sym == NULL)
> + break;
> + subr = ra - (vaddr_t)diff;
> +
> + lastframe = frame;
> + if (subr == (vaddr_t)cpu_exception_handler_supervisor ||
> + subr == (vaddr_t)cpu_exception_handler_user) {
> + struct trapframe *tf = (struct trapframe *)frame;
> +
> + frame = (struct callframe *)tf->tf_s[0];
> + ra = tf->tf_ra;
> + } else {
> + frame = frame[-1].f_frame;
> + if (frame == NULL)
> + break;
> + ra = frame[-1].f_ra;
> + }
> +
> + if (frame <= lastframe)
> + break;
> + if (frame >= limit)
> + break;
> + if (!INKERNEL(ra))
> + break;
> + }
> +}
> Index: arch/riscv64/riscv64/vm_machdep.c
> ===
> RCS file: src/sys/arch/riscv64/riscv64/vm_machdep.c,v
> retrieving revision 1.10
> diff -u -p -r1.10 vm_machdep.c
> --- arch/riscv64/riscv64/vm_machdep.c 24 Feb 2022 14:19:10 -  1.10
> +++ arch/riscv64/riscv64/vm_machdep.c 8 Mar 2022 16:54:58 -
> @@ -75,13 +75,12 @@ cpu_fork(struct proc *p1, struct proc *p
>  
>   pmap_activate(p2);
>  
> - tf = (struct trapframe *)((u_long)p2->p_addr
> + pcb->pcb_kstack = STACKALIGN((u_long)p2->p_addr
>   + USPACE
> - - sizeof(struct trapframe)
>   - sizeof(register_t)/* for holding curcpu */
>   - 0x10);
>  
> - tf = (struct trapframe *)STACKALIGN(tf);
> + tf = (struct trapframe *)pcb->pcb_kstack - 1;
>   pcb->pcb_tf = tf;
>   *tf = *p1->p_addr->u_pcb.pcb_tf;
>  
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: add -k / --keep for gzip(1)

2022-03-05 Thread Jeremie Courreges-Anglas
On Thu, Mar 03 2022, Todd C. Miller  wrote:
> On Thu, 03 Mar 2022 15:11:13 +, Miod Vallat wrote:
>
>> > I think this makes sense if only for better GNU gzip compatibility.
>> > OK millert@
>>
>> But does the `-k' flag needs to be added to compress(1) too?
>
> No, it just makes usage() slightly more complicated.
> But that diff was missing an update to usage() anyway.

I'm not sure what you mean here.  Solene's diff added -k to both
compress(1) and gzip(1) (and their uncompressor counterparts).
Adding -k to gzip/gunzip only would indeed make the usage() slightly
more complicated.

So do we want to add -k to compress(1) or not?  (No strong opinion.)

I like the general idea and the diff seems to work as intended.


> Index: compress.1
> ===
> RCS file: /home/reposync/src/usr.bin/compress/compress.1,v
> retrieving revision 1.48
> diff -u -p -r1.48 compress.1
> --- compress.117 Mar 2014 14:23:50 -  1.48
> +++ compress.13 Mar 2022 12:08:01 -
> @@ -44,13 +44,13 @@
>  .Nd compress and expand data (compress mode)
>  .Sh SYNOPSIS
>  .Nm compress
> -.Op Fl 123456789cdfghlNnOqrtv
> +.Op Fl 123456789cdfghklNnOqrtv
>  .Op Fl b Ar bits
>  .Op Fl o Ar filename
>  .Op Fl S Ar suffix
>  .Op Ar
>  .Nm uncompress
> -.Op Fl cfhlNnqrtv
> +.Op Fl cfhklNnqrtv
>  .Op Fl o Ar filename
>  .Op Ar
>  .Nm zcat
> @@ -192,6 +192,8 @@ Use the deflate scheme, which reportedly
>  mode).
>  .It Fl h
>  Print a short help message.
> +.It Fl k
> +Keep input files after compression or decompression.
>  .It Fl l
>  List information for the specified compressed files.
>  The following information is listed:
> Index: gzip.1
> ===
> RCS file: /home/reposync/src/usr.bin/compress/gzip.1,v
> retrieving revision 1.14
> diff -u -p -r1.14 gzip.1
> --- gzip.17 Oct 2014 21:06:30 -   1.14
> +++ gzip.13 Mar 2022 12:08:21 -
> @@ -43,13 +43,13 @@
>  .Nd compress and expand data (deflate mode)
>  .Sh SYNOPSIS
>  .Nm gzip
> -.Op Fl 123456789cdfhLlNnOqrtVv
> +.Op Fl 123456789cdfhkLlNnOqrtVv
>  .Op Fl b Ar bits
>  .Op Fl o Ar filename
>  .Op Fl S Ar suffix
>  .Op Ar
>  .Nm gunzip
> -.Op Fl cfhLlNnqrtVv
> +.Op Fl cfhkLlNnqrtVv
>  .Op Fl o Ar filename
>  .Op Ar
>  .Nm gzcat
> @@ -183,6 +183,8 @@ behave as
>  .Xr cat 1 .
>  .It Fl h
>  Print a short help message.
> +.It Fl k
> +Keep input files after compression or decompression.
>  .It Fl L
>  A no-op which exists for compatibility only.
>  On GNU gzip, it displays the program's license.
> Index: main.c
> ===
> RCS file: /home/reposync/src/usr.bin/compress/main.c,v
> retrieving revision 1.98
> diff -u -p -r1.98 main.c
> --- main.c18 Jan 2021 00:46:58 -  1.98
> +++ main.c3 Mar 2022 12:00:28 -
> @@ -75,8 +75,8 @@ const struct compressor {
>   "deflate",
>   ".gz",
>   "\037\213",
> - "123456789ab:cdfhLlNnOo:qrS:tVv",
> - "cfhLlNno:qrtVv",
> + "123456789ab:cdfhkLlNnOo:qrS:tVv",
> + "cfhkLlNno:qrtVv",
>   "fhqr",
>   gz_ropen,
>   gz_read,
> @@ -92,8 +92,8 @@ const struct compressor {
>   "compress",
>   ".Z",
>   "\037\235",
> - "123456789ab:cdfghlNnOo:qrS:tv",
> - "cfhlNno:qrtv",
> + "123456789ab:cdfghklNnOo:qrS:tv",
> + "cfhklNno:qrtv",
>   "fghqr",
>   z_ropen,
>   zread,
> @@ -110,8 +110,8 @@ const struct compressor null_method = {
>   "null",
>   ".nul",
>   "XX",
> - "123456789ab:cdfghlNnOo:qrS:tv",
> - "cfhlNno:qrtv",
> + "123456789ab:cdfghklNnOo:qrS:tv",
> + "cfhklNno:qrtv",
>   "fghqr",
>   null_ropen,
>   null_read,
> @@ -141,6 +141,7 @@ const struct option longopts[] = {
>   { "uncompress", no_argument,0, 'd' },
>   { "force",  no_argument,0, 'f' },
>   { "help",   no_argument,0, 'h' },
> + { "keep",   no_argument,0, 'k' },
>   { "list",   no_argument,0, 'l' },
>   { "license",no_argument,0, 'L' },
>   { "no-name",no_argument,0, 'n' },
> @@ -166,12 +167,12 @@ main(int argc, char *argv[])
>   const char *optstr, *s;
>   char *p, *infile;
>   char outfile[PATH_MAX], _infile[PATH_MAX], suffix[16];
> - int bits, ch, error, rc, cflag, oflag;
> + int bits, ch, error, rc, cflag, oflag, kflag;
>  
>   if (pledge("stdio rpath wpath cpath fattr chown", NULL) == -1)
>   err(1, "pledge");
>  
> - bits = cflag = oflag = 0;
> + bits = cflag = oflag = kflag = 0;
>   storename = -1;
>   p = __progname;
>   if (p[0] == 'g') {
> @@ -276,6 +277,9 @@ main(int argc, char *argv[])
>   

Re: add openvpn 1194/udp/tcp port to /etc/services

2022-03-01 Thread Jeremie Courreges-Anglas
On Tue, Mar 01 2022, Landry Breuil  wrote:
> Hi,
>
> while looking at other things i noticed OpenVPN wasnt in /etc/services.
>
> apparently its listed/registered by IANA since 2004 (i know, not a reason), 
> and
> i have it on a debian 11 box and on a FreeBSD 12.2 server.
>
> i see two reasons:
> - making sure another service doesnt squat the port for outgoing cnx, since
>   in some configs openvpn is started manually after boot
> - write nicer pf rules :)
>
> oks ?

yup (net/openvpn maintainer here)

> Index: services
> ===
> RCS file: /cvs/src/etc/services,v
> retrieving revision 1.103
> diff -u -r1.103 services
> --- services  2 Sep 2021 10:46:22 -   1.103
> +++ services  1 Mar 2022 10:18:08 -
> @@ -173,6 +173,8 @@
>  pop3s995/tcp spop3   # pop3 protocol over 
> TLS/SSL
>  socks1080/tcp# Socks
>  kpop 1109/tcp# Pop with Kerberos
> +openvpn  1194/tcp# OpenVPN
> +openvpn  1194/udp# OpenVPN
>  ms-sql-s 1433/tcpMicrosoft-SQL-Server
>  ms-sql-s 1433/udpMicrosoft-SQL-Server
>  ms-sql-m 1434/tcpMicrosoft-SQL-Monitor
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: lldb(1) libedit support

2022-02-24 Thread Jeremie Courreges-Anglas
On Tue, Feb 15 2022, Greg Steuck  wrote:
> Andrei  writes:
>
>> The lldb(1) debugger was recently added in base and as I was playing around 
>> with it I noticed the lack of line editing functionality.
>>
>> This is because currently lldb is built without support for
>> libedit. It would be nice to have libedit in base such to be able to
>> link lldb against it, as the lack of line editing functionality makes
>> it difficult to use.
>
> libedit is in base and gnu/usr.bin/clang/lldb/Makefile even links
> lldb against libedit:
> : LDADD+= -lcurses -ledit -lpanel
>
> Curiously, trying to enable libedit support in lldb with the following
> patch didn't seem to help (arrow keys still show ^[[A and such).
>
> modified   gnu/usr.bin/clang/include/lldb/Host/Config.h
> @@ -41,7 +41,7 @@
>  
>  #define CURSES_HAVE_NCURSES_CURSES_H 0
>  
> -#define LLDB_ENABLE_LIBEDIT 0
> +#define LLDB_ENABLE_LIBEDIT 1
>  
>  #define LLDB_ENABLE_LIBXML2 0

Here's what the devel/llvm cmake build system defines.  Editing in emacs
mode (default) seems to work but I have tested very lightly so far.

Works for you?  ok?


diff --git gnu/usr.bin/clang/include/lldb/Host/Config.h 
gnu/usr.bin/clang/include/lldb/Host/Config.h
index 184c61330a6..3a07fd60667 100644
--- gnu/usr.bin/clang/include/lldb/Host/Config.h
+++ gnu/usr.bin/clang/include/lldb/Host/Config.h
@@ -9,9 +9,9 @@
 #ifndef LLDB_HOST_CONFIG_H
 #define LLDB_HOST_CONFIG_H
 
-#define LLDB_EDITLINE_USE_WCHAR 0
+#define LLDB_EDITLINE_USE_WCHAR 1
 
-#define LLDB_HAVE_EL_RFUNC_T 0
+#define LLDB_HAVE_EL_RFUNC_T 1
 
 #define HAVE_SYS_TYPES_H 1
 
@@ -37,11 +37,11 @@
 
 #define LLDB_ENABLE_LZMA 0
 
-#define LLDB_ENABLE_CURSES 0
+#define LLDB_ENABLE_CURSES 1
 
 #define CURSES_HAVE_NCURSES_CURSES_H 0
 
-#define LLDB_ENABLE_LIBEDIT 0
+#define LLDB_ENABLE_LIBEDIT 1
 
 #define LLDB_ENABLE_LIBXML2 0
 

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



ubsan_minimal documentation hint (was: Re: Ship ubsan_minimal library in base?)

2022-02-16 Thread Jeremie Courreges-Anglas
On Tue, Feb 15 2022, Jeremie Courreges-Anglas  wrote:

[...]

>>> Index: clang-local.1
>>> ===
>>> RCS file: /home/cvs/src/share/man/man1/clang-local.1,v
>>> retrieving revision 1.22
>>> diff -u -p -p -u -r1.22 clang-local.1
>>> --- clang-local.1   7 Sep 2021 17:39:49 -   1.22
>>> +++ clang-local.1   5 Feb 2022 17:11:48 -
>>> @@ -93,6 +93,13 @@ option to treat signed integer overflows
>>>  prevent dangerous optimizations which could remove security critical 
>>> overflow
>>>  checks.
>>>  .It
>>> +Only ubsan_minimal support is shipped by the base system.
>>> +To make use of it, pass
>>> +.Nm clang
>>> +the following options:
>>> +.Fl fsanitize=undefined
>>> +.Fl fsanitize-minimal-runtime .
>
> I'm not 100% happy with this wording, I'll try to rework it.

Maybe something like this?  The idea is to point people to ubsan_minimal
instead of assuming that ubsan isn't supported at all.  I can't see
a better place to document this.

For more context: UBSan is supposed to catch undefined behavior at
runtime and to react by printing an error message and/or aborting, etc.
https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

Greg, still ok with this version?  Thoughts?


Index: clang-local.1
===
RCS file: /home/cvs/src/share/man/man1/clang-local.1,v
retrieving revision 1.22
diff -u -p -p -u -r1.22 clang-local.1
--- clang-local.1   7 Sep 2021 17:39:49 -   1.22
+++ clang-local.1   16 Feb 2022 22:37:05 -
@@ -93,6 +93,12 @@ option to treat signed integer overflows
 prevent dangerous optimizations which could remove security critical overflow
 checks.
 .It
+The base system ships support for the ubsan_minimal sanitizer runtime
+but not for the default ubsan runtime.
+See the documentation for the
+.Fl fsanitize-minimal-runtime
+flag.
+.It
 The
 .Xr malloc 3 ,
 .Xr calloc 3 ,


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: Ship ubsan_minimal library in base?

2022-02-15 Thread Jeremie Courreges-Anglas
On Sat, Feb 05 2022, Greg Steuck  wrote:
> Sweet, let's look at the two patches below. No sets yet.
>
> I tested on amd64 with the UBSan sample program and also with
> games/battlestar. If somebody could repeat the steps I listed in the
> previous email on a non-amd64 platform, that would be useful.
>
> Jeremie Courreges-Anglas  writes:
>
>> On Sat, Feb 05 2022, Jeremie Courreges-Anglas  wrote:
>>> On Fri, Feb 04 2022, Greg Steuck  wrote:
>>>> How do people feel about shipping the minimal UBSan runtime library[1]
>>>> in the base system? It takes very little to build (Makefile + a few
>>>> ifdefs that both jca@ and I hacked together). The library is tiny
>>
>> In case people wonder, the implementation is in
>> gnu/llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp
>>
>> I suspect we should to ship a PIC/shared version of the library, along
>> with /usr/lib/clang/13.0.0/lib/libclang_rt.ubsan_minimal.a but ENOTIME
>> to look further right now.
>
> If you see enough value in that, by all means we can add this. I don't
> know if clang has the necessary plumbing for easy choice between the .a
> and .so here.

I didn't find such plumbing, even though ubsan_minimal/CMakeLists.txt
mentions a shared version, maybe a red herring.  Your Makefile proposal
specifies -fPIC and that seems to work well in practice for static and
static-no-pie code.

>> Tentative proposal, maybe a bit premature
>>
>> Index: clang-local.1
>> ===
>> RCS file: /home/cvs/src/share/man/man1/clang-local.1,v
>> retrieving revision 1.22
>> diff -u -p -p -u -r1.22 clang-local.1
>> --- clang-local.17 Sep 2021 17:39:49 -   1.22
>> +++ clang-local.15 Feb 2022 17:11:48 -
>> @@ -93,6 +93,13 @@ option to treat signed integer overflows
>>  prevent dangerous optimizations which could remove security critical 
>> overflow
>>  checks.
>>  .It
>> +Only ubsan_minimal support is shipped by the base system.
>> +To make use of it, pass
>> +.Nm clang
>> +the following options:
>> +.Fl fsanitize=undefined
>> +.Fl fsanitize-minimal-runtime .

I'm not 100% happy with this wording, I'll try to rework it.  In the
meantime...

>> +.It
>>  The
>>  .Xr malloc 3 ,
>>  .Xr calloc 3 ,
>
> Excellent, I was looking for the right place to put this.
> OK gnezdo@ once it works :)

... this seems to work pretty well here on amd64 and riscv64 (base-clang
only archs) and sparc64 (base-gcc, but base-clang is available).

I still think that this can and should be added to base.  ok jca@

Minor spacing issue below,

> From 46e3165e67b4e5b45e4a379abe4be2656fc8f81c Mon Sep 17 00:00:00 2001
> From: Greg Steuck 
> Date: Sat, 5 Feb 2022 14:15:25 -0800
> Subject: [PATCH 1/2] Add ifdefs to build ubsan_minimal on OpenBSD
>
> ---
>  gnu/llvm/compiler-rt/lib/interception/interception.h | 4 ++--
>  .../compiler-rt/lib/interception/interception_linux.h| 2 +-
>  .../compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp | 2 +-
>  .../compiler-rt/lib/sanitizer_common/sanitizer_linux.h   | 2 +-
>  .../lib/sanitizer_common/sanitizer_platform.h| 9 -
>  gnu/llvm/compiler-rt/lib/ubsan/ubsan_platform.h  | 2 +-
>  6 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/gnu/llvm/compiler-rt/lib/interception/interception.h 
> b/gnu/llvm/compiler-rt/lib/interception/interception.h
> index d8dc092c45f..fb91a4cc32b 100644
> --- a/gnu/llvm/compiler-rt/lib/interception/interception.h
> +++ b/gnu/llvm/compiler-rt/lib/interception/interception.h
> @@ -18,7 +18,7 @@
>  
>  #if !SANITIZER_LINUX && !SANITIZER_FREEBSD && !SANITIZER_MAC &&  \
>  !SANITIZER_NETBSD && !SANITIZER_WINDOWS && !SANITIZER_FUCHSIA && \
> -!SANITIZER_SOLARIS
> +!SANITIZER_OPENBSD && !SANITIZER_SOLARIS
>  #  error "Interception doesn't work on this operating system."
>  #endif
>  
> @@ -272,7 +272,7 @@ typedef unsigned long uptr;
>  #define INCLUDED_FROM_INTERCEPTION_LIB
>  
>  #if SANITIZER_LINUX || SANITIZER_FREEBSD || SANITIZER_NETBSD || \
> -SANITIZER_SOLARIS
> +SANITIZER_OPENBSD || SANITIZER_SOLARIS
>  
>  # include "interception_linux.h"
>  # define INTERCEPT_FUNCTION(func) INTERCEPT_FUNCTION_LINUX_OR_FREEBSD(func)
> diff --git a/gnu/llvm/compiler-rt/lib/interception/interception_linux.h 
> b/gnu/llvm/compiler-rt/lib/interception/interception_linux.h
> index a08f8cb98c4..b554b53d1dc 100644
> --- a/gnu/llvm/compiler-rt/lib/interception/interception_linux.h
> +++ b/gnu/llvm/compiler-rt/lib/interception/int

Re: Ship ubsan_minimal library in base?

2022-02-05 Thread Jeremie Courreges-Anglas
On Sat, Feb 05 2022, Jeremie Courreges-Anglas  wrote:
> On Fri, Feb 04 2022, Greg Steuck  wrote:
>> How do people feel about shipping the minimal UBSan runtime library[1]
>> in the base system? It takes very little to build (Makefile + a few
>> ifdefs that both jca@ and I hacked together). The library is tiny

In case people wonder, the implementation is in
gnu/llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp

I suspect we should to ship a PIC/shared version of the library, along
with /usr/lib/clang/13.0.0/lib/libclang_rt.ubsan_minimal.a but ENOTIME
to look further right now.

>> and
>> useful enough for finding UB in base.
>
> As already discussed I agree with that this should be shipped in base.
> To make it easier for users to find it, I would suggest documenting that
> only ubsan_minimal is supported for now (as far as I'm concerned I did
> not look at non-minimal-ubsan and I don't plan to do so).

Tentative proposal, maybe a bit premature

Index: clang-local.1
===
RCS file: /home/cvs/src/share/man/man1/clang-local.1,v
retrieving revision 1.22
diff -u -p -p -u -r1.22 clang-local.1
--- clang-local.1   7 Sep 2021 17:39:49 -   1.22
+++ clang-local.1   5 Feb 2022 17:11:48 -
@@ -93,6 +93,13 @@ option to treat signed integer overflows
 prevent dangerous optimizations which could remove security critical overflow
 checks.
 .It
+Only ubsan_minimal support is shipped by the base system.
+To make use of it, pass
+.Nm clang
+the following options:
+.Fl fsanitize=undefined
+.Fl fsanitize-minimal-runtime .
+.It
 The
 .Xr malloc 3 ,
 .Xr calloc 3 ,


>> % ls -l /usr/lib/clang/13.0.0/lib/libclang_rt.ubsan_minimal*
>> -r--r--r--  1 root  bin  51516 Feb  4 20:02 
>> /usr/lib/clang/13.0.0/lib/libclang_rt.ubsan_minimal.a
>>
>> % cd /usr/src/games/battlestar
>> % make obj && make clean; make LDFLAGS='-fsanitize=undefined 
>> -fsanitize-minimal-runtime' COPTS='-g -fsanitize=undefined 
>> -fsanitize-minimal-runtime -fno-wrapv'
>> % ./obj/battlestar
>> Version 4.2, fall 1984.
>> First Adventure game written by His Lordship, the honorable
>> Admiral D.W. Riggle
>>
>> ubsan: shift-out-of-bounds
>
> FWIW I can't get ubsan_minimal to kick in with the wip Makefile/diff
> I shared earlier.  I'd love to have your latest diffs to do some
> testing.

Stoopid me had already fixed extern.h, no wonder why I could not
reproduce this with my wip diff (seems to kick in properly now).

>> % egdb ./obj/battlestar 
>> (gdb) b __ubsan_handle_shift_out_of_bounds_minimal
>> Breakpoint 1 at 0x23630: file 
>> /usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp,
>>  line 104.
>> (gdb) bt
>> No stack.
>> (gdb) r
>> Starting program: /usr/obj/games/battlestar/battlestar 
>> Version 4.2, fall 1984.
>> First Adventure game written by His Lordship, the honorable
>> Admiral D.W. Riggle
>>
>>
>> Breakpoint 1, __ubsan_handle_shift_out_of_bounds_minimal ()
>> at 
>> /usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:104
>> 104 HANDLER(shift_out_of_bounds, "shift-out-of-bounds")
>> (gdb) bt
>> #0  __ubsan_handle_shift_out_of_bounds_minimal ()
>> at 
>> /usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:104
>> #1  0x07434ee9f654 in initialize (filename=) at 
>> /usr/src/games/battlestar/init.c:67
>> #2  0x07434ee8af06 in main (argc=1, argv=) at 
>> /usr/src/games/battlestar/battlestar.c:58
>>
>> (gdb) up
>> #1  0x0b1eddd2a654 in initialize (filename=) at 
>> /usr/src/games/battlestar/init.c:67
>> 67  SetBit(location[p->room].objects, p->obj);
>>
>> (gdb) !grep SetBit extern.h
>> #define SetBit(array, index)(array[index/BITS] |= (1 << (index % BITS)))
>>
>> Yup, the usual, shifting too far without 1U. Hence the patch:
>
> The diff below does not apply (tabs vs spaces) but makes sense.  ok jca@
>
>> --- a/games/battlestar/extern.h
>> +++ b/games/battlestar/extern.h
>> @@ -39,9 +39,9 @@
>>  #define OUTSIDE(position > 68 && position < 246 && position 
>> != 218)
>>  #define rnd(x) arc4random_uniform(x)
>>  #define max(a,b)   ((a) < (b) ? (b) : (a))
>> -#define TestBit(array, index)  (array[index/BITS] & (1 << (index % BITS)))
>> -#define SetBit(array, index)   (array[index/BITS] |= (1 << (index % BITS)))
>> -

Re: Ship ubsan_minimal library in base?

2022-02-05 Thread Jeremie Courreges-Anglas
On Fri, Feb 04 2022, Greg Steuck  wrote:
> How do people feel about shipping the minimal UBSan runtime library[1]
> in the base system? It takes very little to build (Makefile + a few
> ifdefs that both jca@ and I hacked together). The library is tiny and
> useful enough for finding UB in base.

As already discussed I agree with that this should be shipped in base.
To make it easier for users to find it, I would suggest documenting that
only ubsan_minimal is supported for now (as far as I'm concerned I did
not look at non-minimal-ubsan and I don't plan to do so).

> % ls -l /usr/lib/clang/13.0.0/lib/libclang_rt.ubsan_minimal*
> -r--r--r--  1 root  bin  51516 Feb  4 20:02 
> /usr/lib/clang/13.0.0/lib/libclang_rt.ubsan_minimal.a
>
> % cd /usr/src/games/battlestar
> % make obj && make clean; make LDFLAGS='-fsanitize=undefined 
> -fsanitize-minimal-runtime' COPTS='-g -fsanitize=undefined 
> -fsanitize-minimal-runtime -fno-wrapv'
> % ./obj/battlestar
> Version 4.2, fall 1984.
> First Adventure game written by His Lordship, the honorable
> Admiral D.W. Riggle
>
> ubsan: shift-out-of-bounds

FWIW I can't get ubsan_minimal to kick in with the wip Makefile/diff
I shared earlier.  I'd love to have your latest diffs to do some
testing.

> % egdb ./obj/battlestar 
> (gdb) b __ubsan_handle_shift_out_of_bounds_minimal
> Breakpoint 1 at 0x23630: file 
> /usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp,
>  line 104.
> (gdb) bt
> No stack.
> (gdb) r
> Starting program: /usr/obj/games/battlestar/battlestar 
> Version 4.2, fall 1984.
> First Adventure game written by His Lordship, the honorable
> Admiral D.W. Riggle
>
>
> Breakpoint 1, __ubsan_handle_shift_out_of_bounds_minimal ()
> at 
> /usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:104
> 104 HANDLER(shift_out_of_bounds, "shift-out-of-bounds")
> (gdb) bt
> #0  __ubsan_handle_shift_out_of_bounds_minimal ()
> at 
> /usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:104
> #1  0x07434ee9f654 in initialize (filename=) at 
> /usr/src/games/battlestar/init.c:67
> #2  0x07434ee8af06 in main (argc=1, argv=) at 
> /usr/src/games/battlestar/battlestar.c:58
>
> (gdb) up
> #1  0x0b1eddd2a654 in initialize (filename=) at 
> /usr/src/games/battlestar/init.c:67
> 67  SetBit(location[p->room].objects, p->obj);
>
> (gdb) !grep SetBit extern.h
> #define SetBit(array, index)(array[index/BITS] |= (1 << (index % BITS)))
>
> Yup, the usual, shifting too far without 1U. Hence the patch:

The diff below does not apply (tabs vs spaces) but makes sense.  ok jca@

> --- a/games/battlestar/extern.h
> +++ b/games/battlestar/extern.h
> @@ -39,9 +39,9 @@
>  #define OUTSIDE(position > 68 && position < 246 && position 
> != 218)
>  #define rnd(x) arc4random_uniform(x)
>  #define max(a,b)   ((a) < (b) ? (b) : (a))
> -#define TestBit(array, index)  (array[index/BITS] & (1 << (index % BITS)))
> -#define SetBit(array, index)   (array[index/BITS] |= (1 << (index % BITS)))
> -#define ClearBit(array, index) (array[index/BITS] &= ~(1 << (index % BITS)))
> +#define TestBit(array, index)  (array[index/BITS] & (1U << (index % BITS)))
> +#define SetBit(array, index)   (array[index/BITS] |= (1U << (index % BITS)))
> +#define ClearBit(array, index) (array[index/BITS] &= ~(1U << (index % BITS)))
>  /*
>   * These macros yield words to use with objects (followed but not preceded
>   * by spaces, or with no spaces if the expansion is the empty string).
>
> OK to fix battlestar while we are at it?
>
> [1] 
> https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#minimal-runtime
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: Missing UBSan libs

2022-02-02 Thread Jeremie Courreges-Anglas
On Mon, Jan 31 2022, Greg Steuck  wrote:
> Patrick Wildt  writes:
>
>> regarding the missing userpace support:  Since a few clang updates ago
>> we import more than just the builtins of compiler-rt.  This means we
>> should have at least some related code in our tree, even if it is not
>> built/complete.

In base this seems to be gnu/llvm/compiler-rt and its subdirs.
Something not present right now in the devel/llvm port.

>> From the recent static analyzer mail thread it looks
>> like people prefer to have such stuff in ports-clang, so, whatever.

I only glanced at this thread but there is probably pushback
against making clang even bigger and slower to build, which is a thing
that I can understand.  I'm not sure it would be a problem to build
a few more llvm support libraries like ubsan.  libclang_rt.profile.a
comes to mind as an existing library that is built as part of the make
build/release process.

> This may or may not be analogous. How hard is it to build a base/ports
> program with clang from ports? If it's a simple matter of
> make CC=/usr/local/bin/cc CFLAGS=-fsanitize=undefined
> then it makes little difference whether the base compiler includes
> the libraries for UBSan reporting.
>
> jca@ WDYT, should I first target devel/llvm to have UBSan working or go
> straight to /usr/src?

Hard to tell without diving in further. :)

My gut feeling is that in the end this should be provided by the base
system, just like the rest of the compiler-rt / clang_rt.profile stuff*.
And since we seem to already have the code in base but not in ports,
I guess the answer is "base".  Obviously in that case you have to
replace the cmake setup with Makefiles.

Those are broad hints, let me know if I can help further.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: fix active scan on iwm and iwx

2022-01-21 Thread Jeremie Courreges-Anglas
On Thu, Jan 13 2022, Stefan Sperling  wrote:
> At present active scans (which send probe requests, as opposed to
> just listening for beacons) are disabled on iwm 9k and iwx. This
> was done because firmware misbehaved after association.
>
> zxystd from the OpenIntelWireless project has debugged the issue
> and has sent me a patch against OpenBSD which fixes this problem. 
> The patch is below, with some small tweaks by me which have already
> been reviewed by zxystd.
>
> It seems that firmware misbehaves if the driver sets the DTIM period
> to zero. This value is read from TIM information elements (IE) in beacons.
> Passive scans worked because we picked up the DTIM period from a beacon,
> while probe responses received during active scans lack the TIM IE, which
> resulted in a zero DTIM period being configured in firmware. We then never
> updated TIM information when a beacon was recieved, letting firmware run
> with a zero DTIM period until it eventually stopped working.
>
> I have tested this patch on iwm 8265 and iwx ax200.

fwiw no regression on a 8265 too.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: DNS in acme-client

2021-12-12 Thread Jeremie Courreges-Anglas
On Sun, Dec 12 2021, Florian Obser  wrote:
> On 12 December 2021 21:19:21 CET, Jeremie Courreges-Anglas  
> wrote:
>>
>>dnsproc.c only returns a single address even if the code pretends to
>>support multiple addresses.  This leads to weird behavior in edge cases,
>>as experienced by a user on IRC.
>>
>>Take a machine with both IPv4 and IPv6 addresses configured, but no
>>IPv4 default route (on purpose).  Since there is at least one IPv4
>>address different from 127.0.0.1, AI_ADDRCONFIG doesn't filter out
>>A records.  Let's encrypt ACME service is dual stacked but the first and
>>only address returned by dnsproc.c is always IPv4 with our "family inet
>>inet6".  In this situation acme-client can't connect over IPv4 and errors
>>out even though there's a working IPv6 default route.
>>
>
> Doctor, Doctor! When I do this, it hurts!

Ah well, the user wasn't complaining, really. :)
I just got curious because the behavior and the code seemed strange.

>>I don't know much about ACME and its requirements / good practices for
>
> I can't think of a reason to not try all address families.

Also I can't think of a reason not to try multiple addresses in the same
address family.

>>clients, but clearly acme-client doesn't behave like most of our
>>programs which try to connect to all available addresses.  This break
>>statement has been there since import, but was it added on purpose?
>>Input welcome.
>>
>>
>
> I probably won't be able to look at this for a week. I am very surprised that 
> this is the correct fix though.

Well I was puzzled too, I stared perhaps 30 seconds trying to understand
what this statement was doing there.  Its presence defeats the point of
the loop, variables, etc around it.  To me this looks like a leftover
from initial experiments.  The initial copy in ntpd/config.c doesn't
have this break statement.

> I trust you checked that multiple IP addresses can be passed between 
> processes?

I added some extra debug statements and could see that 2 adresses (v4
and v6) were passed to netproc.c.  I was able to reproduce the problem
of the original reporter, and see that the diff fixed renewing
a certificate.

>>diff --git a/usr.sbin/acme-client/dnsproc.c b/usr.sbin/acme-client/dnsproc.c
>>index 664ef8d9b8b..c4c612e521a 100644
>>--- a/usr.sbin/acme-client/dnsproc.c
>>+++ b/usr.sbin/acme-client/dnsproc.c
>>@@ -102,7 +102,6 @@ host_dns(const char *s, struct addr *vec)
>> 
>>  dodbg("%s: DNS: %s", s, vec[vecsz].ip);
>>  vecsz++;
>>- break;
>>  }
>> 
>>  freeaddrinfo(res0);
>>
>>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



DNS in acme-client

2021-12-12 Thread Jeremie Courreges-Anglas


dnsproc.c only returns a single address even if the code pretends to
support multiple addresses.  This leads to weird behavior in edge cases,
as experienced by a user on IRC.

Take a machine with both IPv4 and IPv6 addresses configured, but no
IPv4 default route (on purpose).  Since there is at least one IPv4
address different from 127.0.0.1, AI_ADDRCONFIG doesn't filter out
A records.  Let's encrypt ACME service is dual stacked but the first and
only address returned by dnsproc.c is always IPv4 with our "family inet
inet6".  In this situation acme-client can't connect over IPv4 and errors
out even though there's a working IPv6 default route.

I don't know much about ACME and its requirements / good practices for
clients, but clearly acme-client doesn't behave like most of our
programs which try to connect to all available addresses.  This break
statement has been there since import, but was it added on purpose?
Input welcome.


diff --git a/usr.sbin/acme-client/dnsproc.c b/usr.sbin/acme-client/dnsproc.c
index 664ef8d9b8b..c4c612e521a 100644
--- a/usr.sbin/acme-client/dnsproc.c
+++ b/usr.sbin/acme-client/dnsproc.c
@@ -102,7 +102,6 @@ host_dns(const char *s, struct addr *vec)
 
dodbg("%s: DNS: %s", s, vec[vecsz].ip);
vecsz++;
-   break;
}
 
freeaddrinfo(res0);


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: asr(3): strip AD flag in responses

2021-11-23 Thread Jeremie Courreges-Anglas
On Mon, Nov 22 2021, Florian Obser  wrote:
> On 2021-11-21 22:21 +01, Jeremie Courreges-Anglas  wrote:
>> On Sun, Nov 21 2021, Jeremie Courreges-Anglas  wrote:
>>> On Sat, Nov 20 2021, Florian Obser  wrote:
>>
>> [...]
>>
>>>>> Index: lib/libc/asr/res_mkquery.c
>>>>> ===
>>>>> RCS file: /home/cvs/src/lib/libc/asr/res_mkquery.c,v
>>>>> retrieving revision 1.13
>>>>> diff -u -p -r1.13 res_mkquery.c
>>>>> --- lib/libc/asr/res_mkquery.c14 Jan 2019 06:49:42 -  1.13
>>>>> +++ lib/libc/asr/res_mkquery.c20 Nov 2021 14:24:08 -
>>>>> @@ -62,6 +62,9 @@ res_mkquery(int op, const char *dname, i
>>>>>   h.flags |= RD_MASK;
>>>>>   if (ac->ac_options & RES_USE_CD)
>>>>>   h.flags |= CD_MASK;
>>>>> + if ((ac->ac_options & RES_TRUSTAD) &&
>>>>> + !(ac->ac_options & RES_USE_DNSSEC))
>>>>> + h.flags |= AD_MASK;
>>>>
>>>> do you remember why you check for !RES_USE_DNSSEC?
>>>> I'd like to leave it out.
>>>
>>> First, here's my understanding of RES_USE_DNSSEC: it's supposed to
>>> activate EDNS and set the DO bit.  The server is then supposed to reply
>>> with AD set only if the data has been validated (with or without
>>> DNSSEC), and possibly append add DNSSEC data if available.
>>>
>>> Since I didn't know the semantics of both setting AD and DO in a query
>>> (I would expect such semantics to be sane) I wrote those more
>>> conservative checks instead.  Does this make sense?  If so, maybe
>>> a comment would help?
>>>
>>> /* Set the AD flag unless we already plan to set the DNSSEC DO bit. */
>>> if ((ac->ac_options & RES_TRUSTAD) &&
>>> !(ac->ac_options & RES_USE_DNSSEC))
>>>
>>>> In fact I don't think RES_USE_DNSSEC is useful
>>>> at all.
>>>> If you want to set the DO flag and start DNSSEC from first principles
>>>> you are better of talking to the network directly, i.e. rewrite unwind.
>>>
>>> RES_USE_DNSSEC has been there since some time already and it's used by
>>> software in the ports tree, precisely to detect AD=1 - and not so much
>>> for the key records I think.
>>
>> BTW clearing AD might break software that depends on it for stuff like
>> DANE.  postfix uses RES_USE_DNSSEC for this, but also force-enables
>> RES_TRUSTAD if available so it shouldn't be affected (upstream's stance
>> is that you should only use a trusted resolver when running postfix).
>
> Ambitious...
>
> I actually had considerd to only do automatic trust-ad without any way
> for users and programs to change it / expand it to non-localhost.

> But then I thought it might be nice in a datacenter setting where you
> might trust the path to the resolver.

I also think that'trust-ad" is good thing to support.

> And then postfix comes along :(

If we don't want uptreams to use RES_TRUSTAD and thus force the admin to
do a conscious choice, we could hide it as an implementation detail in
asr/ or make it a noop (decoupling it from "options trust-ad" and your
automatic detection).  It would require careful thinking about how
people use the API.  Personnally I don't feel too strongly about giving
people rope...

>> On the other hand mail/exim knowlingly doesn't force RES_TRUSTAD.
>
> I don't think we'll brake anything, at leat it should not stop
> progress. DANE verification has to be oportunistic, no? Good luck
> sending/receiving mail while requiring that certificates are either
> signed by a known CA or TLSA records are published. That will probably
> lose you a whole lot of the internet...

Some people in the corporate world actually start to require the use of
certificates signed by a known CA.  I only spotted this twice so far.
Regarding DANE and TLSA, one of the goals is to be able to use strong
authentication without deferring to commercial CAs. So I'm pretty sure
some nerdy admins have started enforcing it where they can, just because
they can.

>> I don't know of other ports using RES_USE_DNSSEC and caring about the AD
>> flag.
>>
>> The effect of RES_TRUSTAD/trust-ad on RES_USE_DNSSEC ought to be
>> documented, but let's do that in another diff: the documentation of the
>> latter option is already lacking.

Proposal below.  Feedback / oks?


Index: res_init.3
===
RCS file: /home/cv

Re: asr(3): strip AD flag in responses

2021-11-22 Thread Jeremie Courreges-Anglas
On Mon, Nov 22 2021, Florian Obser  wrote:
> On 2021-11-21 21:34 +01, Jeremie Courreges-Anglas  wrote:
>> On Sat, Nov 20 2021, Florian Obser  wrote:
>>> On 2021-11-20 17:05 +01, Jeremie Courreges-Anglas  wrote:
>
>>> do you remember why you check for !RES_USE_DNSSEC?
>>> I'd like to leave it out.
>>
>> First, here's my understanding of RES_USE_DNSSEC: it's supposed to
>> activate EDNS and set the DO bit.  The server is then supposed to reply
>> with AD set only if the data has been validated (with or without
>> DNSSEC), and possibly append add DNSSEC data if available.
>
> I didn't go throught the 3000+ pages of DNS RFC but I don't see a way
> an RFC says AD MUST be set withouth performing DNSSEC validation. That
> just doesn't make sense.

Reading 4035 I think there's provision for setting the AD bit on replies
if the client asked with AD=1 and the server considers the data
authentic for reasons other than DNSSEC (the server being also
authoritative for the zone, or trusting the authoritative servers and
the network path between them).

https://datatracker.ietf.org/doc/html/rfc4035#section-3.1.6

Anyway, this is a detail that is not very relevant for the current
discussion.

> So DO requests that the resolver performes DNSSEC validation **AND**
> informs us about the outcome by setting the AD flag and giving us DNSSEC
> data (i.e. RRSIGs most of the time). Now, that data is not actually
> helping the stub (asr) because it can't build a chain of trust without
> querying for a bunch of more data, and well, having a trust anchor configured.
>
> So this is why setting AD in queries was introduced in 6840, I want to
> know that DNSSEC validation was performed, but I don't want all the
> (for me) useless junk.

That's https://datatracker.ietf.org/doc/html/rfc6840#section-5.7

>> Since I didn't know the semantics of both setting AD and DO in a query
>> (I would expect such semantics to be sane) I wrote those more
>> conservative checks instead.  Does this make sense?  If so, maybe
>> a comment would help?

https://datatracker.ietf.org/doc/html/rfc6840#section-5.8 says

  [...] validating resolvers SHOULD only set the AD bit when a response
  both meets the conditions listed in Section 3.2.3 of [RFC4035], and
  the request contained either a set DO bit or a set AD bit.

"Either".  This kinda points to a conservative approach, but...

> Everything half way decent handles AD + DO set at the same time
> correctly. All the quad-x public resolvers do, as well as bind, knot,
> powerdns-recursor and unbound.
>
> The result is the same as if only DO was set, you get AD set in the
> answer and the junk DNSSEC data. Btw. dig(1) sets AD per default on
> queries and does so when running with +dnssec, too.

... thanks for checking.

> RFC 8906 says that there are servers out there that choke on AD=1 in
> queries. We shouldn't care:
> 1) we enable trust-ad per default for localhost. If someone runs
> something this broken on localhost they need to fix their system
> 2) If the operator of the system sets options trust-ad in resolv.conf
> they hopefully know what they are doing. If their nameserver(s) are this
> broken they shouldn't (and wouldn't) set trust-ad in the first place.
> So this is a non-issue and just complicates the code.
>
>>
>>  /* Set the AD flag unless we already plan to set the DNSSEC DO bit. */
>>  if ((ac->ac_options & RES_TRUSTAD) &&
>>  !(ac->ac_options & RES_USE_DNSSEC))
>>
>
> With that said, I'd really prefer to leave !RES_USE_DNSSEC out, it is
> only a complication. But if you insist, I'll accept it.

You convinced me, I will simplify the checks.

> [...]
>
>>> +Authentic Data (AD) flag in the answer can only be trusted if the
>>> +nameserver itself is trusted and the network path is trusted.
>>> +Generally this is not the case and the AD flag is cleared in the answer.
>>> +The
>>> +.Cm trust-ad
>>> +flag lets the system administrator indicate that the nameserver and the
>>> +network path are trusted.
>>> +Nameservers on localhost can be trusted and
>>> +.Cm trust-ad is enabled per default.
>>
>> Already mentioned above, this last sentence doesn't really describe the
>> precise behavior you proposa.  We *could* have a mix of localhost and
>> non-localhost servers in resolv.conf, and use/trust AD=1 only for
>> localhost servers. But the automatic detection code you wrote enables
>
> [For the archives, in case someone wants to implement this:
>
> yeah, you kinda can't. On the one hand we don't have per-nameserver
> options, they are global. So if you do options trust-ad this applies to
> all nameservers list

Re: asr(3): strip AD flag in responses

2021-11-21 Thread Jeremie Courreges-Anglas
On Sun, Nov 21 2021, Jeremie Courreges-Anglas  wrote:
> On Sat, Nov 20 2021, Florian Obser  wrote:

[...]

>>> Index: lib/libc/asr/res_mkquery.c
>>> ===
>>> RCS file: /home/cvs/src/lib/libc/asr/res_mkquery.c,v
>>> retrieving revision 1.13
>>> diff -u -p -r1.13 res_mkquery.c
>>> --- lib/libc/asr/res_mkquery.c  14 Jan 2019 06:49:42 -  1.13
>>> +++ lib/libc/asr/res_mkquery.c  20 Nov 2021 14:24:08 -
>>> @@ -62,6 +62,9 @@ res_mkquery(int op, const char *dname, i
>>> h.flags |= RD_MASK;
>>> if (ac->ac_options & RES_USE_CD)
>>> h.flags |= CD_MASK;
>>> +   if ((ac->ac_options & RES_TRUSTAD) &&
>>> +   !(ac->ac_options & RES_USE_DNSSEC))
>>> +   h.flags |= AD_MASK;
>>
>> do you remember why you check for !RES_USE_DNSSEC?
>> I'd like to leave it out.
>
> First, here's my understanding of RES_USE_DNSSEC: it's supposed to
> activate EDNS and set the DO bit.  The server is then supposed to reply
> with AD set only if the data has been validated (with or without
> DNSSEC), and possibly append add DNSSEC data if available.
>
> Since I didn't know the semantics of both setting AD and DO in a query
> (I would expect such semantics to be sane) I wrote those more
> conservative checks instead.  Does this make sense?  If so, maybe
> a comment would help?
>
>   /* Set the AD flag unless we already plan to set the DNSSEC DO bit. */
>   if ((ac->ac_options & RES_TRUSTAD) &&
>   !(ac->ac_options & RES_USE_DNSSEC))
>
>> In fact I don't think RES_USE_DNSSEC is useful
>> at all.
>> If you want to set the DO flag and start DNSSEC from first principles
>> you are better of talking to the network directly, i.e. rewrite unwind.
>
> RES_USE_DNSSEC has been there since some time already and it's used by
> software in the ports tree, precisely to detect AD=1 - and not so much
> for the key records I think.

BTW clearing AD might break software that depends on it for stuff like
DANE.  postfix uses RES_USE_DNSSEC for this, but also force-enables
RES_TRUSTAD if available so it shouldn't be affected (upstream's stance
is that you should only use a trusted resolver when running postfix).
On the other hand mail/exim knowlingly doesn't force RES_TRUSTAD.
I don't know of other ports using RES_USE_DNSSEC and caring about the AD
flag.

The effect of RES_TRUSTAD/trust-ad on RES_USE_DNSSEC ought to be
documented, but let's do that in another diff: the documentation of the
latter option is already lacking.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: asr(3): strip AD flag in responses

2021-11-21 Thread Jeremie Courreges-Anglas
On Sat, Nov 20 2021, Florian Obser  wrote:
> On 2021-11-20 17:05 +01, Jeremie Courreges-Anglas  wrote:

[...]

>> Index: lib/libc/asr/getrrsetbyname_async.c
>> ===
>> RCS file: /home/cvs/src/lib/libc/asr/getrrsetbyname_async.c,v
>> retrieving revision 1.11
>> diff -u -p -r1.11 getrrsetbyname_async.c
>> --- lib/libc/asr/getrrsetbyname_async.c  23 Feb 2017 17:04:02 -  
>> 1.11
>> +++ lib/libc/asr/getrrsetbyname_async.c  20 Nov 2021 14:24:08 -
>> @@ -32,7 +32,8 @@
>>  #include "asr_private.h"
>>  
>>  static int getrrsetbyname_async_run(struct asr_query *, struct asr_result 
>> *);
>> -static void get_response(struct asr_result *, const char *, int);
>> +static void get_response(struct asr_query *, struct asr_result *, const 
>> char *,
>> +int);
>>  
>>  struct asr_query *
>>  getrrsetbyname_async(const char *hostname, unsigned int rdclass,
>> @@ -150,7 +151,7 @@ getrrsetbyname_async_run(struct asr_quer
>>  break;
>>  }
>>  
>> -get_response(ar, ar->ar_data, ar->ar_datalen);
>> +get_response(as, ar, ar->ar_data, ar->ar_datalen);
>>  free(ar->ar_data);
>>  async_set_state(as, ASR_STATE_HALT);
>>  break;
>> @@ -255,7 +256,8 @@ static void free_dns_response(struct dns
>>  static int count_dns_rr(struct dns_rr *, u_int16_t, u_int16_t);
>>  
>>  static void
>> -get_response(struct asr_result *ar, const char *pkt, int pktlen)
>> +get_response(struct asr_query *as, struct asr_result *ar, const char *pkt,
>> +int pktlen)
>>  {
>>  struct rrsetinfo *rrset = NULL;
>>  struct dns_response *response = NULL;
>> @@ -287,7 +289,7 @@ get_response(struct asr_result *ar, cons
>>  rrset->rri_nrdatas = response->header.ancount;
>>  
>>  /* check for authenticated data */
>> -if (response->header.ad == 1)
>> +if (as->as_ctx->ac_options & RES_TRUSTAD && response->header.ad == 1)
>>  rrset->rri_flags |= RRSET_VALIDATED;
>
> we can skip all this if we mask AD correctly in the header

That's much nicer indeed!

>>  /* copy name from answer section */
>> Index: lib/libc/asr/res_mkquery.c
>> ===
>> RCS file: /home/cvs/src/lib/libc/asr/res_mkquery.c,v
>> retrieving revision 1.13
>> diff -u -p -r1.13 res_mkquery.c
>> --- lib/libc/asr/res_mkquery.c   14 Jan 2019 06:49:42 -  1.13
>> +++ lib/libc/asr/res_mkquery.c   20 Nov 2021 14:24:08 -
>> @@ -62,6 +62,9 @@ res_mkquery(int op, const char *dname, i
>>  h.flags |= RD_MASK;
>>  if (ac->ac_options & RES_USE_CD)
>>  h.flags |= CD_MASK;
>> +if ((ac->ac_options & RES_TRUSTAD) &&
>> +!(ac->ac_options & RES_USE_DNSSEC))
>> +h.flags |= AD_MASK;
>
> do you remember why you check for !RES_USE_DNSSEC?
> I'd like to leave it out.

First, here's my understanding of RES_USE_DNSSEC: it's supposed to
activate EDNS and set the DO bit.  The server is then supposed to reply
with AD set only if the data has been validated (with or without
DNSSEC), and possibly append add DNSSEC data if available.

Since I didn't know the semantics of both setting AD and DO in a query
(I would expect such semantics to be sane) I wrote those more
conservative checks instead.  Does this make sense?  If so, maybe
a comment would help?

/* Set the AD flag unless we already plan to set the DNSSEC DO bit. */
if ((ac->ac_options & RES_TRUSTAD) &&
!(ac->ac_options & RES_USE_DNSSEC))

> In fact I don't think RES_USE_DNSSEC is useful
> at all.
> If you want to set the DO flag and start DNSSEC from first principles
> you are better of talking to the network directly, i.e. rewrite unwind.

RES_USE_DNSSEC has been there since some time already and it's used by
software in the ports tree, precisely to detect AD=1 - and not so much
for the key records I think.

>>  h.qdcount = 1;
>>  if (ac->ac_options & (RES_USE_EDNS0 | RES_USE_DNSSEC))
>>  h.arcount = 1;
>> Index: lib/libc/asr/res_send_async.c
>> ===
>> RCS file: /home/cvs/src/lib/libc/asr/res_send_async.c,v
>> retrieving revision 1.39
>> diff -u -p -r1.39 res_send_async.c
>> --- lib/libc/asr/res_send_async.c28 Sep 2019 11:21:07 -  1.39
>> +++

Re: asr(3): strip AD flag in responses

2021-11-20 Thread Jeremie Courreges-Anglas


First, I'm happy to this subject considered again, even if I don't use
DNSSEC these days I think it makes sense to provide this support in libc.

On Sat, Nov 20 2021, Florian Obser  wrote:
> On 2021-11-20 14:40 +01, Otto Moerbeek  wrote:
>> On Sat, Nov 20, 2021 at 12:20:32PM +0100, Florian Obser wrote:
>>> diff --git share/man/man5/resolv.conf.5 share/man/man5/resolv.conf.5
>>> index 8d3b91c0832..ac64d3e6fd6 100644
>>> --- share/man/man5/resolv.conf.5
>>> +++ share/man/man5/resolv.conf.5
>>> @@ -259,6 +259,12 @@ first as an absolute name before any search list 
>>> elements are appended to it.
>>>  .It Cm tcp
>>>  Forces the use of TCP for queries.
>>>  Normal behaviour is to query via UDP but fall back to TCP on failure.
>>> +.It Cm trust-ad
>>> +Request DNSSEC validated data from the nameservers and preserve the
>>> +Authentic Data (AD) flag in responses.
>>
>>> +Otherwise the Authentic Data (AD) flag is removed from responses.
>>
>> This is not what happens (though the DNS header itself is not exposed
>> in the API). Maybe describe it as:
>>
>
> That is a very good point. And hints at that the diff is not complete.
> I think we should fiddle with the header. I think res_send_async_run()
> should unset the AD flag in ASR_STATE_PACKET. The api exposes the raw
> packet in the res_query(3) family of functions. And this is actually
> what glibc does.

Indeed, my previous proposal used to do this (I don't remember if
I tested the invalidation though).

>> Request DNSSEC validated data from the nameservers and evaluate the AD
>> flag in responses.
>>
>>> +The nameservers and the network path to them must be trusted.
>>
>> Maybe:
>>
>> Only set this flag if the nameservers and the network paths to them are
>> trusted.
>>
>
> I wanted to focus less on the technical details (AD flag) and more on
> what this means. Of course I failed at that ;)
> I think we should mention the AD flag so that people who know how DNSSEC
> works can find it, but we need to better explain when random user should
> set the flag (never!).
>
> I'll rework the diff.
>
>>> +This is the default for nameservers on localhost.
>>>  .El
>>>  .El
>>>  .Pp


Here's a refreshed version of the diff initially sent in this thread:

  https://marc.info/?l=openbsd-tech=159567881530990=2

It's quite similar to Florian's diff so I'd like to re-submit it.


I like a lot the "automatic localhost trust" from Florian so
I incorporated his improvement here, but I can leave it out from at
commit time.  In the proposal below resolv.conf(5) says:

  +This option should be used only if the transport between the
  +.Ic nameserver
  +and the resolver is secure.
  +It is enabled by default if
  +.Nm resolv.conf
  +only lists nameservers on localhost.

which I think is more accurate regarding nameservers on localhost.
The wording in res_init(3) is unchanged from my first proposal, it
should also be updated if localhost is to be automatically trusted.

The diff also adds trust-ad support in asr_debug.c.

How do you folks like this?


Index: include/resolv.h
===
RCS file: /home/cvs/src/include/resolv.h,v
retrieving revision 1.22
diff -u -p -r1.22 resolv.h
--- include/resolv.h14 Jan 2019 06:23:06 -  1.22
+++ include/resolv.h20 Nov 2021 14:24:08 -
@@ -186,6 +186,8 @@ struct __res_state_ext {
 #defineRES_INSECURE2   0x0800  /* type 2 security disabled */
 #defineRES_NOALIASES   0x1000  /* shuts off HOSTALIASES 
feature */
 #defineRES_USE_INET6   0x2000  /* use/map IPv6 in 
gethostbyname() */
+/* GNU extension: use higher bit to avoid conflict with ISC use */
+#defineRES_TRUSTAD 0x8000  /* query with AD, trust AD in 
reply */
 /* KAME extensions: use higher bit to avoid conflict with ISC use */
 #defineRES_USE_EDNS0   0x4000  /* use EDNS0 */
 /* DNSSEC extensions: use higher bit to avoid conflict with ISC use */
Index: share/man/man5/resolv.conf.5
===
RCS file: /home/cvs/src/share/man/man5/resolv.conf.5,v
retrieving revision 1.62
diff -u -p -r1.62 resolv.conf.5
--- share/man/man5/resolv.conf.524 Aug 2021 07:30:32 -  1.62
+++ share/man/man5/resolv.conf.520 Nov 2021 15:58:39 -
@@ -259,6 +259,18 @@ first as an absolute name before any sea
 .It Cm tcp
 Forces the use of TCP for queries.
 Normal behaviour is to query via UDP but fall back to TCP on failure.
+.It Cm trust-ad
+Sets the AD flag in DNS queries, and preserve the value of the AD flag
+in DNS replies (this flag is stripped by default).
+Useful when applications want to ensure that the DNS resources they
+look up have been signed with DNSSEC and validated by the
+.Ic nameserver .
+This option should be used only if the transport between the
+.Ic nameserver
+and the resolver is secure.
+It is enabled by default if
+.Nm resolv.conf
+only lists nameservers on 

Re: some warnings in prep for LLVM 13

2021-10-25 Thread Jeremie Courreges-Anglas
On Mon, Oct 25 2021, Mark Kettenis  wrote:
>> From: Jeremie Courreges-Anglas 
>> Date: Mon, 25 Oct 2021 14:55:16 +0100
>> 
>> On Mon, Oct 25 2021, Mark Kettenis  wrote:
>> >> Date: Mon, 25 Oct 2021 12:37:41 +0200 (CEST)
>> >> From: Mark Kettenis 
>> >> 
>> >> > Date: Mon, 25 Oct 2021 12:01:11 +0200
>> >> > From: Patrick Wildt 
>> >> > 
>> >> > Hi,
>> >> > 
>> >> > mortimer@ has this diff in his tree for LLVM 13.  I actually haven't
>> >> > tried to see if it works fine with LLVM 11, but I feel it needs to be
>> >> > sent out and not just be blindly committed.
>> >> > 
>> >> > If someone wants to take care of this, it would be nice, so I can take
>> >> > care of the remaining parts of sending out the LLVM 13 diff.
>> >> 
>> >> > diff --git a/lib/libc/arch/amd64/sys/brk.S 
>> >> > b/lib/libc/arch/amd64/sys/brk.S
>> >> > index ce69679e389..ee1c11f7643 100644
>> >> > --- a/lib/libc/arch/amd64/sys/brk.S
>> >> > +++ b/lib/libc/arch/amd64/sys/brk.S
>> >> > @@ -48,7 +48,6 @@ __minbrk:
>> >> > END(__minbrk)
>> >> > .type   __minbrk,@object
>> >> >  
>> >> > -   .weak   brk
>> >> >  ENTRY(brk)
>> >> > cmpq%rdi,__minbrk(%rip)
>> >> > jb  1f
>> >> > diff --git a/lib/libc/arch/amd64/sys/sbrk.S 
>> >> > b/lib/libc/arch/amd64/sys/sbrk.S
>> >> > index 8d7d68909b2..db53a6bb643 100644
>> >> > --- a/lib/libc/arch/amd64/sys/sbrk.S
>> >> > +++ b/lib/libc/arch/amd64/sys/sbrk.S
>> >> > @@ -53,7 +53,6 @@ __curbrk:
>> >> > END(__curbrk)
>> >> > .type   __curbrk,@object
>> >> >  
>> >> > -   .weak   sbrk
>> >> >  ENTRY(sbrk)
>> >> > movq__curbrk(%rip),%rax
>> >> > movslq  %edi,%rsi
>> >> 
>> >> These functions are supposed to be weak, like they are on
>> >> architectures that use a C implementation.  I suppose the .weak
>> >> directive needs to come *after* the .global emitted by ENTRY().
>> >> Putting it after the END() works.
>> >
>> > So I think the diff below is what we want here.
>> 
>> There are others left:
>> 
>> russell /usr/src/lib/libc$ grep -B 1 -R ^ENTRY | grep -A 1 weak
>> arch/i386/sys/brk.S-.weak   brk
>> arch/i386/sys/brk.S:ENTRY(brk)
>> arch/i386/sys/sbrk.S-   .weak   sbrk
>> arch/i386/sys/sbrk.S:ENTRY(sbrk)
>> arch/riscv64/sys/sbrk.S-.weak   sbrk
>> arch/riscv64/sys/sbrk.S:ENTRY(sbrk)
>> arch/riscv64/sys/brk.S- .weak   brk
>> arch/riscv64/sys/brk.S:ENTRY(brk)
>> 
>> (and a few others where grep -B 1 isn't enough)
>> 
>> > ok?
>> 
>> I checked that the resulting .*o files are the same on amd64, sparc64
>> and riscv64.

Actually I have messed up my tests on amd64 and riscv64, where these
changes *do* fix a problem and re-add the weak attribute to the affected
symbol in the object files.

>> ok jca@
>> 
>> Here's the diff for the other architectures.  I didn't touch m88k, which
>> won't use clang anytime soon.  Also ok?
>
> ok kettenis@

Committed, thanks.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: some warnings in prep for LLVM 13

2021-10-25 Thread Jeremie Courreges-Anglas
On Mon, Oct 25 2021, Mark Kettenis  wrote:
>> Date: Mon, 25 Oct 2021 12:37:41 +0200 (CEST)
>> From: Mark Kettenis 
>> 
>> > Date: Mon, 25 Oct 2021 12:01:11 +0200
>> > From: Patrick Wildt 
>> > 
>> > Hi,
>> > 
>> > mortimer@ has this diff in his tree for LLVM 13.  I actually haven't
>> > tried to see if it works fine with LLVM 11, but I feel it needs to be
>> > sent out and not just be blindly committed.
>> > 
>> > If someone wants to take care of this, it would be nice, so I can take
>> > care of the remaining parts of sending out the LLVM 13 diff.
>> 
>> > diff --git a/lib/libc/arch/amd64/sys/brk.S b/lib/libc/arch/amd64/sys/brk.S
>> > index ce69679e389..ee1c11f7643 100644
>> > --- a/lib/libc/arch/amd64/sys/brk.S
>> > +++ b/lib/libc/arch/amd64/sys/brk.S
>> > @@ -48,7 +48,6 @@ __minbrk:
>> >END(__minbrk)
>> >.type   __minbrk,@object
>> >  
>> > -  .weak   brk
>> >  ENTRY(brk)
>> >cmpq%rdi,__minbrk(%rip)
>> >jb  1f
>> > diff --git a/lib/libc/arch/amd64/sys/sbrk.S 
>> > b/lib/libc/arch/amd64/sys/sbrk.S
>> > index 8d7d68909b2..db53a6bb643 100644
>> > --- a/lib/libc/arch/amd64/sys/sbrk.S
>> > +++ b/lib/libc/arch/amd64/sys/sbrk.S
>> > @@ -53,7 +53,6 @@ __curbrk:
>> >END(__curbrk)
>> >.type   __curbrk,@object
>> >  
>> > -  .weak   sbrk
>> >  ENTRY(sbrk)
>> >movq__curbrk(%rip),%rax
>> >movslq  %edi,%rsi
>> 
>> These functions are supposed to be weak, like they are on
>> architectures that use a C implementation.  I suppose the .weak
>> directive needs to come *after* the .global emitted by ENTRY().
>> Putting it after the END() works.
>
> So I think the diff below is what we want here.

There are others left:

russell /usr/src/lib/libc$ grep -B 1 -R ^ENTRY | grep -A 1 weak
arch/i386/sys/brk.S-.weak   brk
arch/i386/sys/brk.S:ENTRY(brk)
arch/i386/sys/sbrk.S-   .weak   sbrk
arch/i386/sys/sbrk.S:ENTRY(sbrk)
arch/riscv64/sys/sbrk.S-.weak   sbrk
arch/riscv64/sys/sbrk.S:ENTRY(sbrk)
arch/riscv64/sys/brk.S- .weak   brk
arch/riscv64/sys/brk.S:ENTRY(brk)

(and a few others where grep -B 1 isn't enough)

> ok?

I checked that the resulting .*o files are the same on amd64, sparc64
and riscv64.  ok jca@

Here's the diff for the other architectures.  I didn't touch m88k, which
won't use clang anytime soon.  Also ok?


Index: arch/arm/sys/brk.S
===
RCS file: /cvs/src/lib/libc/arch/arm/sys/brk.S,v
retrieving revision 1.10
diff -u -p -r1.10 brk.S
--- arch/arm/sys/brk.S  21 Nov 2017 19:08:36 -  1.10
+++ arch/arm/sys/brk.S  25 Oct 2021 13:48:05 -
@@ -44,8 +44,6 @@ __minbrk:
.word   _C_LABEL(_end)
END(__minbrk)
 
-   .weak   brk
-
 /*
  * Change the data segment size
  */
@@ -96,3 +94,4 @@ ENTRY(brk)
 .Lcurbrk:
.word   PIC_SYM(__curbrk, GOT)
 END(brk)
+   .weak   brk
Index: arch/arm/sys/sbrk.S
===
RCS file: /cvs/src/lib/libc/arch/arm/sys/sbrk.S,v
retrieving revision 1.10
diff -u -p -r1.10 sbrk.S
--- arch/arm/sys/sbrk.S 21 Nov 2017 19:08:36 -  1.10
+++ arch/arm/sys/sbrk.S 25 Oct 2021 13:48:05 -
@@ -45,7 +45,6 @@ __curbrk:
.word   _C_LABEL(_end)
END(__curbrk)
 
-   .weak   sbrk
 /*
  * Change the data segment size
  */
@@ -85,3 +84,4 @@ ENTRY(sbrk)
 .Lcurbrk:
.word   PIC_SYM(__curbrk, GOT)
 END(sbrk)
+   .weak   sbrk
Index: arch/i386/sys/brk.S
===
RCS file: /cvs/src/lib/libc/arch/i386/sys/brk.S,v
retrieving revision 1.13
diff -u -p -r1.13 brk.S
--- arch/i386/sys/brk.S 19 Aug 2017 18:24:06 -  1.13
+++ arch/i386/sys/brk.S 25 Oct 2021 13:48:05 -
@@ -42,7 +42,6 @@ __minbrk:
END(__minbrk)
.type   __minbrk,@object
 
-   .weak   brk
 ENTRY(brk)
 #ifdef __PIC__
movl4(%esp),%ecx
@@ -82,3 +81,4 @@ ENTRY(brk)
SET_ERRNO()
ret
 END(brk)
+   .weak   brk
Index: arch/i386/sys/sbrk.S
===
RCS file: /cvs/src/lib/libc/arch/i386/sys/sbrk.S,v
retrieving revision 1.13
diff -u -p -r1.13 sbrk.S
--- arch/i386/sys/sbrk.S19 Aug 2017 18:24:06 -  1.13
+++ arch/i386/sys/sbrk.S25 Oct 2021 13:48:05 -
@@ -42,7 +42,6 @@ __curbrk: .long   _end
END(__curbrk)
.type   __curbrk,@object
 
-   .weak   sbrk
 ENTRY(sbrk)
 #ifdef __PIC__
movl4(%esp),%ecx
@@ -76,3 +75,4 @@ ENTRY(sbrk)
SET_ERRNO()
ret
 END(sbrk)
+   .weak   sbrk
Index: arch/powerpc/sys/brk.S
===
RCS file: /cvs/src/lib/libc/arch/powerpc/sys/brk.S,v
retrieving revision 1.15
diff -u -p -r1.15 brk.S
--- arch/powerpc/sys/brk.S  26 Oct 2020 22:07:05 -  1.15
+++ arch/powerpc/sys/brk.S  25 Oct 2021 13:48:05 -
@@ -30,8 +30,6 @@
.extern __curbrk
.extern _C_LABEL(_end)
 
-   .weak   

Re: some warnings in prep for LLVM 13

2021-10-25 Thread Jeremie Courreges-Anglas
On Mon, Oct 25 2021, Theo Buehler  wrote:
>> index 664a5200037..e33763e7420 100644
>> --- a/usr.bin/openssl/Makefile
>> +++ b/usr.bin/openssl/Makefile
>> @@ -17,6 +17,7 @@ CFLAGS+= -Wuninitialized
>>  CFLAGS+= -Wunused
>>  .if ${COMPILER_VERSION:L} == "clang"
>>  CFLAGS+= -Werror
>> +CFLAGS+= -Wno-unused-but-set-variable
>
> This will break the build with LLVM 11 because of -Werror:
>
> error: unknown warning option '-Wno-unused-but-set-variable'; did you mean 
> '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-option]
> *** Error 1 in /usr/src/usr.bin/openssl (:87 'apps.o')
>
> Also, it would be nice to know what triggered this addition.

You can use egcc to spot why clang 13 errors out, but they may not warn
exactly about the same problems.  This works for easy stuff, not so much
for the kernel.  We really need the clang 13 errors.

Here's an attempt to use egcc over openssl and libcrypto.  The s_client
diff probably fixes what clang 13 complains about.

The two latter diffs for libcrypto remove unneeded includes.  This looks
unrelated to the addition of -Wno-unused-but-set-variable by mortimer@,
but I thought maybe you would be interested.
egcc -Wno-unused-but-set-variable doesn't seem to find anything else in
libcrypto.

In file included from /usr/src/lib/libcrypto/x509/x509_asid.c:28:
/usr/src/lib/libcrypto/x509/ext_dat.h:81:33: error: 'standard_exts' defined but 
not used [-Werror=unused-variable]
 static const X509V3_EXT_METHOD *standard_exts[] = {

ok for the s_client diff?

Your call regarding the 2nd & 3rd. If that structure really can be used
in multiple files then "static" is probably not appropriate.  Or maybe
the structure should just be moved to x509/x509_lib.c.


Index: usr.bin/openssl/s_client.c
===
RCS file: /home/cvs/src/usr.bin/openssl/s_client.c,v
retrieving revision 1.55
diff -u -p -r1.55 s_client.c
--- usr.bin/openssl/s_client.c  22 Oct 2021 09:44:58 -  1.55
+++ usr.bin/openssl/s_client.c  25 Oct 2021 10:53:06 -
@@ -894,7 +894,6 @@ s_client_main(int argc, char **argv)
char *cbuf = NULL, *sbuf = NULL, *mbuf = NULL, *pbuf = NULL;
int cbuf_len, cbuf_off;
int sbuf_len, sbuf_off;
-   int pbuf_len;
int full_log = 1;
char *pass = NULL;
X509 *cert = NULL;
@@ -1195,7 +1194,6 @@ s_client_main(int argc, char **argv)
cbuf_off = 0;
sbuf_len = 0;
sbuf_off = 0;
-   pbuf_len = 0;
 
/* This is an ugly hack that does a lot of assumptions */
/*
@@ -1502,7 +1500,6 @@ s_client_main(int argc, char **argv)
if (SSL_get_error(con, p) == SSL_ERROR_NONE) {
if (p <= 0)
goto end;
-   pbuf_len = p;
 
k = SSL_read(con, sbuf, p);
}
Index: lib/libcrypto/x509/x509_addr.c
===
RCS file: /home/cvs/src/lib/libcrypto/x509/x509_addr.c,v
retrieving revision 1.16
diff -u -p -r1.16 x509_addr.c
--- lib/libcrypto/x509/x509_addr.c  8 Sep 2021 10:49:34 -   1.16
+++ lib/libcrypto/x509/x509_addr.c  25 Oct 2021 11:09:00 -
@@ -23,8 +23,6 @@
 #include 
 #include 
 
-#include "ext_dat.h"
-
 #ifndef OPENSSL_NO_RFC3779
 
 /*
Index: lib/libcrypto/x509/x509_asid.c
===
RCS file: /home/cvs/src/lib/libcrypto/x509/x509_asid.c,v
retrieving revision 1.16
diff -u -p -r1.16 x509_asid.c
--- lib/libcrypto/x509/x509_asid.c  8 Sep 2021 09:49:24 -   1.16
+++ lib/libcrypto/x509/x509_asid.c  25 Oct 2021 11:09:17 -
@@ -25,8 +25,6 @@
 #include 
 #include 
 
-#include "ext_dat.h"
-
 #ifndef OPENSSL_NO_RFC3779
 
 static const ASN1_TEMPLATE ASRange_seq_tt[] = {

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: riscv64: ld.lld is too picky on ABI mismatch

2021-10-25 Thread Jeremie Courreges-Anglas
On Mon, Oct 25 2021, Patrick Wildt  wrote:
> Am Mon, Oct 25, 2021 at 11:43:55AM +0200 schrieb Mark Kettenis:
>> > From: Jeremie Courreges-Anglas 
>> > Date: Sun, 24 Oct 2021 17:30:46 +0100
>> > 
>> > clang(1) defaults to FP ABI but ld(1) -melf64lriscv doesn't.  This is
>> > a problem as soon as a port tries to use raw ld(1) -b binary to embed
>> > data in a .o file.
>> > 
>> > Downgrading this hard error to a warning seems more useful as far as the
>> > ports tree is concerned.  The diff below fixes
>> > databases/postgresql-pllua and should also fix textproc/mupdf and net/utox.
>> > 
>> > There's another diff here: https://reviews.llvm.org/D106378
>> > but it's slightly more complicated and it received seemingly negative
>> > feedback.  So I'm just using a minimal change to fit our needs.
>> > 
>> > ok?
>> 
>> I think we should try to avoid deviating from upstream as much as
>> possible.  And I agree with the folks who argue that the mismatching
>> objects are created with the wrong tools.

Well the only alternative they suggest is using assembly and .incbin.
Maybe that works for the FreeBSD folks working on low-level stuff, but
not so much as a general purpose tool to include binary data in builds.

>> But if mortimer@ and
>> patrick@ can deal with carrying this local modification I won't
>> object.

I can't speak for them but given the local changes we have in clang and
lld land this two lines diff doesn't seem daunting. ;)

> Well, I was about to send an LLVM 13 diff... so can we revisit this diff
> when we're updated to LLVM 13?

Sure!

>> > Index: ELF/Arch/RISCV.cpp
>> > ===
>> > RCS file: /cvs/src/gnu/llvm/lld/ELF/Arch/RISCV.cpp,v
>> > retrieving revision 1.1.1.2
>> > diff -u -p -r1.1.1.2 RISCV.cpp
>> > --- ELF/Arch/RISCV.cpp 28 Apr 2021 12:29:31 -  1.1.1.2
>> > +++ ELF/Arch/RISCV.cpp 24 Oct 2021 15:55:49 -
>> > @@ -122,8 +122,8 @@ uint32_t RISCV::calcEFlags() const {
>> >target |= EF_RISCV_RVC;
>> >  
>> >  if ((eflags & EF_RISCV_FLOAT_ABI) != (target & EF_RISCV_FLOAT_ABI))
>> > -  error(toString(f) +
>> > -": cannot link object files with different floating-point 
>> > ABI");
>> > +  warn(toString(f) +
>> > +": linking object files with different floating-point ABI");
>> >  
>> >  if ((eflags & EF_RISCV_RVE) != (target & EF_RISCV_RVE))
>> >error(toString(f) +
>> > 
>> > 
>> > -- 
>> > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
>> > 
>> > 
>> 
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



riscv64: ld.lld is too picky on ABI mismatch

2021-10-24 Thread Jeremie Courreges-Anglas


clang(1) defaults to FP ABI but ld(1) -melf64lriscv doesn't.  This is
a problem as soon as a port tries to use raw ld(1) -b binary to embed
data in a .o file.

Downgrading this hard error to a warning seems more useful as far as the
ports tree is concerned.  The diff below fixes
databases/postgresql-pllua and should also fix textproc/mupdf and net/utox.

There's another diff here: https://reviews.llvm.org/D106378
but it's slightly more complicated and it received seemingly negative
feedback.  So I'm just using a minimal change to fit our needs.

ok?


Index: ELF/Arch/RISCV.cpp
===
RCS file: /cvs/src/gnu/llvm/lld/ELF/Arch/RISCV.cpp,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 RISCV.cpp
--- ELF/Arch/RISCV.cpp  28 Apr 2021 12:29:31 -  1.1.1.2
+++ ELF/Arch/RISCV.cpp  24 Oct 2021 15:55:49 -
@@ -122,8 +122,8 @@ uint32_t RISCV::calcEFlags() const {
   target |= EF_RISCV_RVC;
 
 if ((eflags & EF_RISCV_FLOAT_ABI) != (target & EF_RISCV_FLOAT_ABI))
-  error(toString(f) +
-": cannot link object files with different floating-point ABI");
+  warn(toString(f) +
+": linking object files with different floating-point ABI");
 
 if ((eflags & EF_RISCV_RVE) != (target & EF_RISCV_RVE))
   error(toString(f) +


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: riscv64: icache flush using sysarch(2)

2021-09-13 Thread Jeremie Courreges-Anglas
On Thu, Sep 09 2021, Mark Kettenis  wrote:
>> From: Jeremie Courreges-Anglas 
>> Date: Sun, 05 Sep 2021 21:41:35 +0200
>> 
>> On Sat, Sep 04 2021, Jeremie Courreges-Anglas  wrote:
>> > The first problem I was able to diagnose using egdb on riscv was
>> > lang/python/2.7 using libffi and aborting in libcompiler-rt (the
>> > compilerrt_abort() call below).
>> >
>> > --8<--
>> > #elif defined(__riscv) && defined(__linux__)
>> > #define __NR_riscv_flush_icache (244 + 15)
>> >   register void *start_reg __asm("a0") = start;
>> >   const register void *end_reg __asm("a1") = end;
>> >   const register long flags __asm("a2") = 0;
>> >   const register long syscall_nr __asm("a7") = __NR_riscv_flush_icache;
>> >   __asm __volatile("ecall"
>> >: "=r"(start_reg)
>> >: "r"(start_reg), "r"(end_reg), "r"(flags), 
>> > "r"(syscall_nr));
>> >   assert(start_reg == 0 && "Cache flush syscall failed.");
>> > #else
>> > #if __APPLE__
>> >   // On Darwin, sys_icache_invalidate() provides this functionality
>> >   sys_icache_invalidate(start, end - start);
>> > #else
>> >   compilerrt_abort();
>> > #endif
>> > #endif
>> > }
>> > -->8--
>> >
>> > The ususal way we provide this functionality is through sysarch(2).
>> > Since the RISC-V ISA only provides fence.i as an extension, and that
>> > fence.i doesn't support parameters to only act on a specific range,
>> > I figured I would reflect that in the API for the sake of clarity.
>> >
>> > If people expect the spec to evolve and new CPUs to ship with
>> > support for finer-grained invalidation, a more forward-looking approach
>> > would be to mimic ARM_SYNC_ICACHE and struct arm_sync_icache_args, and
>> > let the kernel ignore the parameters if appropriate.
>
> I think people expect the spec to evolve, and that's why fence.i is
> considered to be an extention.  The Linux syscal for this does specify
> and address range to flush, so I think it makes sense for us to do the
> same.

100% fine with this.

> Modelling this on ARM_SYNC_ICACHE makes sense to me.  Don't
> think we need to do the UVM dance that arm32_sync_icache() does
> though.  Keep it simple for now.

At least arm32_sync_icache() does some kind of validation:

revision 1.4
date: 2017/03/21 21:43:11;  author: kettenis;  state: Exp;  lines: +36 -2;  
commitid: nGOn4iYognC4A9wJ;
Avoid panic in arm_sync_icache() by only flushing the parts of the address
space for which we have a userland mapping.


>> > In the diff below I'm moving the core of the code to cpu.c since it
>> > doesn't look pmap-specific, but I don't feel strongly about it.
>> > I haven't even built this since I'm still on the way back from k2k21 but
>> > I figured I'd ask for feedback early.  Input welcome.
>
> While you're not wrong, pmap.c is the traditional place where we deal
> with dcache to icache incoherency.  So I think keeping the code there
> makes sense.

okay.  That results in much less churn.

> In fact, we already have a standardized pmap interface
> for this, which is pmap_proc_iflush().  This is the code that gets
> called by ptrace(2) to make sure an inserted breakpoint is visible to
> all CPUs.  My suggestion would be to make RISCV64_SYNC_ICACHE call
> this function and keep the code in pmap.c

In sys_process.c:process_domem() the various checks probably prevent
userland from calling pmap_proc_iflush() with a bogus addresse/length.
I fear that we could hit the same kind of panic as on arm if people
later modify riscv64 icache_flush() and pmap_proc_iflush() to actually
implement finer-grained icache invalidation and sysarch() isn't updated
to perform argument validation.

Wouldn't it be clearer to stop marking icache_flush() as inline and
reuse it directly for sysarch() support?  (Not implemented in the diff
below.)


Index: gnu/llvm/compiler-rt/lib/builtins/clear_cache.c
===
RCS file: /cvs/src/gnu/llvm/compiler-rt/lib/builtins/clear_cache.c,v
retrieving revision 1.3
diff -u -p -r1.3 clear_cache.c
--- gnu/llvm/compiler-rt/lib/builtins/clear_cache.c 2 Jan 2021 17:14:13 
-   1.3
+++ gnu/llvm/compiler-rt/lib/builtins/clear_cache.c 13 Sep 2021 19:33:22 
-
@@ -33,7 +33,7 @@ uintptr_t GetCurrentProcess(void);
 #include 
 #endif
 
-#if defined(__OpenBSD__) && (defined(__arm__) || defined(__mips__))
+#if defined(__OpenBSD__) && (defined(__arm__) || define

Re: riscv64: icache flush using sysarch(2)

2021-09-05 Thread Jeremie Courreges-Anglas
On Sat, Sep 04 2021, Jeremie Courreges-Anglas  wrote:
> The first problem I was able to diagnose using egdb on riscv was
> lang/python/2.7 using libffi and aborting in libcompiler-rt (the
> compilerrt_abort() call below).
>
> --8<--
> #elif defined(__riscv) && defined(__linux__)
> #define __NR_riscv_flush_icache (244 + 15)
>   register void *start_reg __asm("a0") = start;
>   const register void *end_reg __asm("a1") = end;
>   const register long flags __asm("a2") = 0;
>   const register long syscall_nr __asm("a7") = __NR_riscv_flush_icache;
>   __asm __volatile("ecall"
>: "=r"(start_reg)
>: "r"(start_reg), "r"(end_reg), "r"(flags), 
> "r"(syscall_nr));
>   assert(start_reg == 0 && "Cache flush syscall failed.");
> #else
> #if __APPLE__
>   // On Darwin, sys_icache_invalidate() provides this functionality
>   sys_icache_invalidate(start, end - start);
> #else
>   compilerrt_abort();
> #endif
> #endif
> }
> -->8--
>
> The ususal way we provide this functionality is through sysarch(2).
> Since the RISC-V ISA only provides fence.i as an extension, and that
> fence.i doesn't support parameters to only act on a specific range,
> I figured I would reflect that in the API for the sake of clarity.
>
> If people expect the spec to evolve and new CPUs to ship with
> support for finer-grained invalidation, a more forward-looking approach
> would be to mimic ARM_SYNC_ICACHE and struct arm_sync_icache_args, and
> let the kernel ignore the parameters if appropriate.
>
> In the diff below I'm moving the core of the code to cpu.c since it
> doesn't look pmap-specific, but I don't feel strongly about it.
> I haven't even built this since I'm still on the way back from k2k21 but
> I figured I'd ask for feedback early.  Input welcome.

Updated diff that builds (one #include was missing) and that appears to
do the right thing.  The diff also includes the compiler-rt change.


Index: gnu/llvm/compiler-rt/lib/builtins/clear_cache.c
===
RCS file: /cvs/src/gnu/llvm/compiler-rt/lib/builtins/clear_cache.c,v
retrieving revision 1.3
diff -u -p -r1.3 clear_cache.c
--- gnu/llvm/compiler-rt/lib/builtins/clear_cache.c 2 Jan 2021 17:14:13 
-   1.3
+++ gnu/llvm/compiler-rt/lib/builtins/clear_cache.c 19 Aug 2021 17:28:40 
-
@@ -33,7 +33,7 @@ uintptr_t GetCurrentProcess(void);
 #include 
 #endif
 
-#if defined(__OpenBSD__) && (defined(__arm__) || defined(__mips__))
+#if defined(__OpenBSD__) && (defined(__arm__) || defined(__mips__) || 
defined(__riscv))
 // clang-format off
 #include 
 #include 
@@ -157,6 +157,8 @@ void __clear_cache(void *start, void *en
: "=r"(start_reg)
: "r"(start_reg), "r"(end_reg), "r"(flags), 
"r"(syscall_nr));
   assert(start_reg == 0 && "Cache flush syscall failed.");
+#elif defined(__riscv) && defined(__OpenBSD__)
+   sysarch(RISCV_SYNC_ICACHE_ALL, NULL);
 #else
 #if __APPLE__
   // On Darwin, sys_icache_invalidate() provides this functionality
Index: sys/arch/riscv64/include/cpufunc.h
===
RCS file: /cvs/src/sys/arch/riscv64/include/cpufunc.h,v
retrieving revision 1.4
diff -u -p -r1.4 cpufunc.h
--- sys/arch/riscv64/include/cpufunc.h  18 May 2021 09:14:49 -  1.4
+++ sys/arch/riscv64/include/cpufunc.h  18 Aug 2021 23:24:59 -
@@ -92,6 +92,7 @@ extern int64_t icache_line_size;
 extern void (*cpu_dcache_wbinv_range)(paddr_t, psize_t);
 extern void (*cpu_dcache_inv_range)(paddr_t, psize_t);
 extern void (*cpu_dcache_wb_range)(paddr_t, psize_t);
+extern void icache_flush(void);
 
 static __inline void
 load_satp(uint64_t val)
Index: sys/arch/riscv64/include/sysarch.h
===
RCS file: sys/arch/riscv64/include/sysarch.h
diff -N sys/arch/riscv64/include/sysarch.h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/arch/riscv64/include/sysarch.h  18 Aug 2021 23:24:59 -
@@ -0,0 +1,38 @@
+/* $OpenBSD$   */
+
+/*
+ * Copyright (c) 2021 Jeremie Courreges-Anglas 
+ *
+ * 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 

riscv64: icache flush using sysarch(2)

2021-09-04 Thread Jeremie Courreges-Anglas


The first problem I was able to diagnose using egdb on riscv was
lang/python/2.7 using libffi and aborting in libcompiler-rt (the
compilerrt_abort() call below).

--8<--
#elif defined(__riscv) && defined(__linux__)
#define __NR_riscv_flush_icache (244 + 15)
  register void *start_reg __asm("a0") = start;
  const register void *end_reg __asm("a1") = end;
  const register long flags __asm("a2") = 0;
  const register long syscall_nr __asm("a7") = __NR_riscv_flush_icache;
  __asm __volatile("ecall"
   : "=r"(start_reg)
   : "r"(start_reg), "r"(end_reg), "r"(flags), "r"(syscall_nr));
  assert(start_reg == 0 && "Cache flush syscall failed.");
#else
#if __APPLE__
  // On Darwin, sys_icache_invalidate() provides this functionality
  sys_icache_invalidate(start, end - start);
#else
  compilerrt_abort();
#endif
#endif
}
-->8--

The ususal way we provide this functionality is through sysarch(2).
Since the RISC-V ISA only provides fence.i as an extension, and that
fence.i doesn't support parameters to only act on a specific range,
I figured I would reflect that in the API for the sake of clarity.

If people expect the spec to evolve and new CPUs to ship with
support for finer-grained invalidation, a more forward-looking approach
would be to mimic ARM_SYNC_ICACHE and struct arm_sync_icache_args, and
let the kernel ignore the parameters if appropriate.

In the diff below I'm moving the core of the code to cpu.c since it
doesn't look pmap-specific, but I don't feel strongly about it.
I haven't even built this since I'm still on the way back from k2k21 but
I figured I'd ask for feedback early.  Input welcome.


Index: include/cpufunc.h
===
RCS file: /d/cvs/src/sys/arch/riscv64/include/cpufunc.h,v
retrieving revision 1.4
diff -u -p -r1.4 cpufunc.h
--- include/cpufunc.h   18 May 2021 09:14:49 -  1.4
+++ include/cpufunc.h   4 Sep 2021 08:58:38 -
@@ -92,6 +92,7 @@ extern int64_t icache_line_size;
 extern void (*cpu_dcache_wbinv_range)(paddr_t, psize_t);
 extern void (*cpu_dcache_inv_range)(paddr_t, psize_t);
 extern void (*cpu_dcache_wb_range)(paddr_t, psize_t);
+extern void icache_flush(void);
 
 static __inline void
 load_satp(uint64_t val)
Index: include/sysarch.h
===
RCS file: include/sysarch.h
diff -N include/sysarch.h
--- /dev/null   1 Jan 1970 00:00:00 -0000
+++ include/sysarch.h   4 Sep 2021 09:12:53 -
@@ -0,0 +1,38 @@
+/* $OpenBSD$   */
+
+/*
+ * Copyright (c) 2021 Jeremie Courreges-Anglas 
+ *
+ * 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.
+ */
+
+#ifndef_RISCV64_SYSARCH_H_
+#define_RISCV64_SYSARCH_H_
+
+/*
+ * Architecture specific syscalls (riscv64)
+ */
+
+#defineRISCV_SYNC_ICACHE_ALL   0
+
+#ifndef _KERNEL
+
+#include 
+
+__BEGIN_DECLS
+intsysarch(int, void *);
+__END_DECLS
+
+#endif /* _KERNEL */
+
+#endif /* _RISCV64_SYSARCH_H_ */
Index: riscv64/cpu.c
===
RCS file: /d/cvs/src/sys/arch/riscv64/riscv64/cpu.c,v
retrieving revision 1.11
diff -u -p -r1.11 cpu.c
--- riscv64/cpu.c   24 Jul 2021 18:15:13 -  1.11
+++ riscv64/cpu.c   4 Sep 2021 09:02:09 -
@@ -26,6 +26,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -300,6 +301,38 @@ cpu_cache_nop_range(paddr_t pa, psize_t 
 void (*cpu_dcache_wbinv_range)(paddr_t, psize_t) = cpu_cache_nop_range;
 void (*cpu_dcache_inv_range)(paddr_t, psize_t) = cpu_cache_nop_range;
 void (*cpu_dcache_wb_range)(paddr_t, psize_t) = cpu_cache_nop_range;
+
+void
+icache_flush(void)
+{
+#ifdef MULTIPROCESSOR
+   CPU_INFO_ITERATOR cii;
+   struct cpu_info *ci;
+   unsigned long hart_mask = 0;
+#endif
+
+   fence_i();
+
+#ifdef MULTIPROCESSOR
+   CPU_INFO_FOREACH(cii, ci) {
+   if (ci == curcpu())
+   continue;
+   hart_mask |= (1UL << ci->ci_hartid);
+   }
+
+   /*
+* From the RISC-V ISA:
+*
+* To make a store to instruction memory visible t

riscv64/trap.c debug printfs

2021-09-03 Thread Jeremie Courreges-Anglas


This one is a bit too chatty whenever you run a program under egdb.
But the other printfs in this file seem ok, thus I'm not touching them.

ok?


Index: trap.c
===
RCS file: /d/cvs/src/sys/arch/riscv64/riscv64/trap.c,v
retrieving revision 1.16
diff -u -p -p -u -r1.16 trap.c
--- trap.c  26 Jul 2021 22:13:19 -  1.16
+++ trap.c  3 Sep 2021 14:25:31 -
@@ -159,7 +159,6 @@ do_trap_user(struct trapframe *frame)
trapsignal(p, SIGILL, 0, ILL_ILLTRP, sv);
break;
case EXCP_BREAKPOINT:
-   printf("BREAKPOINT\n");
sv.sival_ptr = (void *)frame->tf_stval;
trapsignal(p, SIGTRAP, 0, TRAP_BRKPT, sv);
break;

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: riscv64 ptrace(2) tweaks

2021-09-03 Thread Jeremie Courreges-Anglas
On Fri, Sep 03 2021, Mark Kettenis  wrote:
>> From: Jeremie Courreges-Anglas 
>> Date: Fri, 03 Sep 2021 14:32:26 +0200
>> 
>> Two changes that would be useful:
>> - enable PT_*FPREGS, Mark has already done the job.

>> - hide PT_STEP since hardware support seems missing (the spec only talks
>>   about single stepping support in "Debug mode", which is not "Machine" or
>>   "Supervisor" mode).  Since we don't emulate it (like mips64 for
>>   example) it doesn't make sense to provide the define.

>> I doubt that
>>   hiding PT_STEP [will] magically fix devel/gdb runtime support though.

Actually it does.

(gdb) b main
Breakpoint 1 at 0x1d00: file /usr/src/usr.bin/du/du.c, line 69.
(gdb) r
Starting program: /usr/obj/usr.bin/du/du

Breakpoint 1, main (argc=, argv=) at 
/usr/src/usr.bin/du/du.c:69
69  if (pledge("stdio rpath", NULL) == -1)
(gdb)

The details are a bit gory but somehow egdb manages to cope.

>> 
>> Thoughts?  ok?
>
> ok kettenis@

Thank you Mark!

>> Index: ptrace.h
>> ===
>> RCS file: /d/cvs/src/sys/arch/riscv64/include/ptrace.h,v
>> retrieving revision 1.2
>> diff -u -p -p -u -r1.2 ptrace.h
>> --- ptrace.h 12 May 2021 01:20:52 -  1.2
>> +++ ptrace.h 3 Sep 2021 12:25:54 -
>> @@ -16,10 +16,10 @@
>>   * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>>   */
>>  
>> +#if 0
>>  #define PT_STEP (PT_FIRSTMACH + 0)
>> +#endif
>>  #define PT_GETREGS  (PT_FIRSTMACH + 1)
>>  #define PT_SETREGS  (PT_FIRSTMACH + 2)
>> -#if 0  // XXX ptrace fpreg support
>>  #define PT_GETFPREGS(PT_FIRSTMACH + 3)
>>  #define PT_SETFPREGS(PT_FIRSTMACH + 4)
>> -#endif
>> 
>> 
>> -- 
>> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
>> 
>> 
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



riscv64 ptrace(2) tweaks

2021-09-03 Thread Jeremie Courreges-Anglas


Two changes that would be useful:
- enable PT_*FPREGS, Mark has already done the job.
- hide PT_STEP since hardware support seems missing (the spec only talks
  about single stepping support in "Debug mode", which is not "Machine" or
  "Supervisor" mode).  Since we don't emulate it (like mips64 for
  example) it doesn't make sense to provide the define.  I doubt that
  hiding PT_STEP won't magically fix devel/gdb runtime support though.

Thoughts?  ok?


Index: ptrace.h
===
RCS file: /d/cvs/src/sys/arch/riscv64/include/ptrace.h,v
retrieving revision 1.2
diff -u -p -p -u -r1.2 ptrace.h
--- ptrace.h12 May 2021 01:20:52 -  1.2
+++ ptrace.h3 Sep 2021 12:25:54 -
@@ -16,10 +16,10 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
+#if 0
 #definePT_STEP (PT_FIRSTMACH + 0)
+#endif
 #definePT_GETREGS  (PT_FIRSTMACH + 1)
 #definePT_SETREGS  (PT_FIRSTMACH + 2)
-#if 0  // XXX ptrace fpreg support
 #definePT_GETFPREGS(PT_FIRSTMACH + 3)
 #definePT_SETFPREGS(PT_FIRSTMACH + 4)
-#endif


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: usertc: small consistency tweaks

2021-07-25 Thread Jeremie Courreges-Anglas


cc'ing cheloha@ since he probably cares about this.

On Sun, Jul 25 2021, Mark Kettenis  wrote:
>> From: Jeremie Courreges-Anglas 
>> Date: Sun, 25 Jul 2021 04:31:20 +0200
>> 
>> On Sat, Jul 24 2021, Mark Kettenis  wrote:
>> >> From: Jeremie Courreges-Anglas 
>> >> Date: Sat, 24 Jul 2021 21:22:23 +0200
>> >> 
>> >> hifive /usr/src/regress/sys/kern/gettimeofday$ doas -u build time 
>> >> obj/gettimeofday
>> >> 6.64 real 6.63 user 0.02 sys
>> >> hifive /usr/src/regress/sys/kern/gettimeofday$ doas -u build env 
>> >> LIBC_NOUSERTC=1 time obj/gettimeofday
>> >> 6.48 real 0.60 user 5.42 sys
>> >> 
>> >> Initially I thought that a more descriptive name than TC_TB could be
>> >> helpful (TC_TIMEBASE?).  But since powerpc also uses TC_TB I think it's
>> >> fine as a first step.  We can change it later easily, it's just a define
>> >> name.
>> >> 
>> >> I haven't even built a release with this, not sure it's worth it.
>> >> If you have cpu cycles to spare, please say so.
>> >> 
>> >> ok?
>> >
>> > Two small nits below.  With that fixed, ok kettenis@
>> 
>> [...]
>> 
>> >> Index: lib/libc/arch/riscv64/gen/usertc.c
>> >> ===
>> >> RCS file: /cvs/src/lib/libc/arch/riscv64/gen/usertc.c,v
>> >> retrieving revision 1.1
>> >> diff -u -p -r1.1 usertc.c
>> >> --- lib/libc/arch/riscv64/gen/usertc.c29 Apr 2021 18:33:36 -  
>> >> 1.1
>> >> +++ lib/libc/arch/riscv64/gen/usertc.c24 Jul 2021 17:07:01 -
>> >> @@ -1,6 +1,7 @@
>> >>  /*   $OpenBSD: usertc.c,v 1.1 2021/04/29 18:33:36 drahn Exp $
>> >> */
>> >>  /*
>> >>   * Copyright (c) 2020 Paul Irofti 
>> >> + * Copyright (c) 2021 Jeremie Courreges-Anglas 
>> >>   *
>> >>   * Permission to use, copy, modify, and distribute this software for any
>> >>   * purpose with or without fee is hereby granted, provided that the above
>> >> @@ -18,4 +19,24 @@
>> >>  #include 
>> >>  #include 
>> >>  
>> >> -int (*const _tc_get_timecount)(struct timekeep *, u_int *) = NULL;
>> >> +static inline u_int
>> >> +rdtime(void)
>> >> +{
>> >> + uint64_t ret;
>> >> + asm volatile("rdtime %0" : "=r"(ret));
>> >
>> > Can you make that __asm vol[a]tile?
>> 
>> Done.  I copied that from amd64 usertc.c.
>> 
>> >> + return ret & 0x;
>> >
>> > The & 0x isn't really necessary here and the kernel doesn't do
>> > it.  So I'd drop that bit and simply return ret.
>> 
>> I thought I would make it explicit to the reader that we only cared
>> about the low 32 bits, rather then rely on the implicit truncation.
>> Your nit was about consistency, what about trying to make other
>> implementations consistent?  Or should we make it explicit on other
>> archs?
>> 
>> Two changes, only compile-tested on amd64 and sparc64:
>> - asm/__asm__ -> __asm
>> - val & mask -> val
>> 
>> I can also drop this diff, consistency is good but so is time on our
>> hands.
>
> So the whole idea was to minimize the diffs between the kernel and
> userland implementation of the tc_get_timecount() functions.  On some
> of the architectures that isn't entirely feasable so there are some
> differences.  But it seems you realized this ;).
>
> Masking is in general unnecessary as the generic timecounter code
> (kernel and userland) already does the masking.

I'm not talking about the masking done by the timecounter API.
The *_timecount() kernel functions (and their userland counterparts)
return a u_int, not a uint64_t.  Before reaching the timecounter
internals, masking off the 32 high bits of a 64 bit value has already
been done by an implicit truncation.  Thus,

> However, there are
> exceptions.
>  
>> Index: lib/libc/arch/aarch64/gen/usertc.c
>> ===
>> RCS file: /d/cvs/src/lib/libc/arch/aarch64/gen/usertc.c,v
>> retrieving revision 1.2
>> diff -u -p -r1.2 usertc.c
>> --- lib/libc/arch/aarch64/gen/usertc.c   15 Jul 2020 22:58:33 -  
>> 1.2
>> +++ lib/libc/arch/aarch64/gen/usertc.c   24 Jul 2021 23:45:52 -
>> @@ -29,7 +29,7 @@ agt

usertc: small consistency tweaks (was: Re: riscv64 usertc)

2021-07-24 Thread Jeremie Courreges-Anglas
On Sat, Jul 24 2021, Mark Kettenis  wrote:
>> From: Jeremie Courreges-Anglas 
>> Date: Sat, 24 Jul 2021 21:22:23 +0200
>> 
>> hifive /usr/src/regress/sys/kern/gettimeofday$ doas -u build time 
>> obj/gettimeofday
>> 6.64 real 6.63 user 0.02 sys
>> hifive /usr/src/regress/sys/kern/gettimeofday$ doas -u build env 
>> LIBC_NOUSERTC=1 time obj/gettimeofday
>> 6.48 real 0.60 user 5.42 sys
>> 
>> Initially I thought that a more descriptive name than TC_TB could be
>> helpful (TC_TIMEBASE?).  But since powerpc also uses TC_TB I think it's
>> fine as a first step.  We can change it later easily, it's just a define
>> name.
>> 
>> I haven't even built a release with this, not sure it's worth it.
>> If you have cpu cycles to spare, please say so.
>> 
>> ok?
>
> Two small nits below.  With that fixed, ok kettenis@

[...]

>> Index: lib/libc/arch/riscv64/gen/usertc.c
>> ===
>> RCS file: /cvs/src/lib/libc/arch/riscv64/gen/usertc.c,v
>> retrieving revision 1.1
>> diff -u -p -r1.1 usertc.c
>> --- lib/libc/arch/riscv64/gen/usertc.c   29 Apr 2021 18:33:36 -  
>> 1.1
>> +++ lib/libc/arch/riscv64/gen/usertc.c   24 Jul 2021 17:07:01 -0000
>> @@ -1,6 +1,7 @@
>>  /*  $OpenBSD: usertc.c,v 1.1 2021/04/29 18:33:36 drahn Exp $*/
>>  /*
>>   * Copyright (c) 2020 Paul Irofti 
>> + * Copyright (c) 2021 Jeremie Courreges-Anglas 
>>   *
>>   * Permission to use, copy, modify, and distribute this software for any
>>   * purpose with or without fee is hereby granted, provided that the above
>> @@ -18,4 +19,24 @@
>>  #include 
>>  #include 
>>  
>> -int (*const _tc_get_timecount)(struct timekeep *, u_int *) = NULL;
>> +static inline u_int
>> +rdtime(void)
>> +{
>> +uint64_t ret;
>> +asm volatile("rdtime %0" : "=r"(ret));
>
> Can you make that __asm vol[a]tile?

Done.  I copied that from amd64 usertc.c.

>> +return ret & 0x;
>
> The & 0x isn't really necessary here and the kernel doesn't do
> it.  So I'd drop that bit and simply return ret.

I thought I would make it explicit to the reader that we only cared
about the low 32 bits, rather then rely on the implicit truncation.
Your nit was about consistency, what about trying to make other
implementations consistent?  Or should we make it explicit on other
archs?

Two changes, only compile-tested on amd64 and sparc64:
- asm/__asm__ -> __asm
- val & mask -> val

I can also drop this diff, consistency is good but so is time on our
hands.


Index: lib/libc/arch/aarch64/gen/usertc.c
===
RCS file: /d/cvs/src/lib/libc/arch/aarch64/gen/usertc.c,v
retrieving revision 1.2
diff -u -p -r1.2 usertc.c
--- lib/libc/arch/aarch64/gen/usertc.c  15 Jul 2020 22:58:33 -  1.2
+++ lib/libc/arch/aarch64/gen/usertc.c  24 Jul 2021 23:45:52 -
@@ -29,7 +29,7 @@ agtimer_get_timecount(struct timecounter
 */
__asm volatile("isb" ::: "memory");
__asm volatile("mrs %x0, CNTVCT_EL0" : "=r" (val));
-   return (val & 0x);
+   return val;
 }
 
 static int
Index: lib/libc/arch/amd64/gen/usertc.c
===
RCS file: /d/cvs/src/lib/libc/arch/amd64/gen/usertc.c,v
retrieving revision 1.3
diff -u -p -r1.3 usertc.c
--- lib/libc/arch/amd64/gen/usertc.c23 Aug 2020 21:38:47 -  1.3
+++ lib/libc/arch/amd64/gen/usertc.c24 Jul 2021 23:45:52 -
@@ -22,7 +22,7 @@ static inline u_int
 rdtsc_lfence(void)
 {
uint32_t hi, lo;
-   asm volatile("lfence; rdtsc" : "=a"(lo), "=d"(hi));
+   __asm volatile("lfence; rdtsc" : "=a"(lo), "=d"(hi));
return ((uint64_t)lo)|(((uint64_t)hi)<<32);
 }
 
Index: lib/libc/arch/mips64/gen/usertc.c
===
RCS file: /d/cvs/src/lib/libc/arch/mips64/gen/usertc.c,v
retrieving revision 1.2
diff -u -p -r1.2 usertc.c
--- lib/libc/arch/mips64/gen/usertc.c   18 Jul 2020 08:37:43 -  1.2
+++ lib/libc/arch/mips64/gen/usertc.c   25 Jul 2021 02:16:21 -
@@ -23,7 +23,7 @@ get_cp0_count(void)
 {
uint32_t count;
 
-   __asm__ volatile (
+   __asm volatile (
"   .setpush\n"
"   .setmips64r2\n"
"   rdhwr   %0, $2\n"
Index: lib/libc/arch/sparc64/gen/usertc.c
===
RCS file: /d/cvs/src/lib/libc/arch/sparc64/g

riscv64 usertc

2021-07-24 Thread Jeremie Courreges-Anglas


hifive /usr/src/regress/sys/kern/gettimeofday$ doas -u build time 
obj/gettimeofday
6.64 real 6.63 user 0.02 sys
hifive /usr/src/regress/sys/kern/gettimeofday$ doas -u build env 
LIBC_NOUSERTC=1 time obj/gettimeofday
6.48 real 0.60 user 5.42 sys

Initially I thought that a more descriptive name than TC_TB could be
helpful (TC_TIMEBASE?).  But since powerpc also uses TC_TB I think it's
fine as a first step.  We can change it later easily, it's just a define
name.

I haven't even built a release with this, not sure it's worth it.
If you have cpu cycles to spare, please say so.

ok?


Index: sys/arch/riscv64/include/timetc.h
===
RCS file: /cvs/src/sys/arch/riscv64/include/timetc.h,v
retrieving revision 1.2
diff -u -p -r1.2 timetc.h
--- sys/arch/riscv64/include/timetc.h   12 May 2021 01:20:52 -  1.2
+++ sys/arch/riscv64/include/timetc.h   23 Jul 2021 13:30:08 -
@@ -19,5 +19,6 @@
 #ifndef _MACHINE_TIMETC_H_
 #define _MACHINE_TIMETC_H_
 
+#define TC_TB  1
 
 #endif /* _MACHINE_TIMETC_H_ */
Index: sys/arch/riscv64/riscv64/clock.c
===
RCS file: /cvs/src/sys/arch/riscv64/riscv64/clock.c,v
retrieving revision 1.2
diff -u -p -r1.2 clock.c
--- sys/arch/riscv64/riscv64/clock.c21 Jun 2021 15:19:39 -  1.2
+++ sys/arch/riscv64/riscv64/clock.c23 Jul 2021 13:29:42 -
@@ -47,6 +47,7 @@ static struct timecounter tb_timecounter
.tc_name = "tb",
.tc_quality = 0,
.tc_priv = NULL,
+   .tc_user = TC_TB,
 };
 
 void   cpu_startclock(void);
Index: lib/libc/arch/riscv64/gen/usertc.c
===
RCS file: /cvs/src/lib/libc/arch/riscv64/gen/usertc.c,v
retrieving revision 1.1
diff -u -p -r1.1 usertc.c
--- lib/libc/arch/riscv64/gen/usertc.c  29 Apr 2021 18:33:36 -  1.1
+++ lib/libc/arch/riscv64/gen/usertc.c  24 Jul 2021 17:07:01 -
@@ -1,6 +1,7 @@
 /* $OpenBSD: usertc.c,v 1.1 2021/04/29 18:33:36 drahn Exp $*/
 /*
  * Copyright (c) 2020 Paul Irofti 
+ * Copyright (c) 2021 Jeremie Courreges-Anglas 
  *
  * Permission to use, copy, modify, and distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -18,4 +19,24 @@
 #include 
 #include 
 
-int (*const _tc_get_timecount)(struct timekeep *, u_int *) = NULL;
+static inline u_int
+rdtime(void)
+{
+   uint64_t ret;
+   asm volatile("rdtime %0" : "=r"(ret));
+   return ret & 0x;
+}
+
+static int
+tc_get_timecount(struct timekeep *tk, u_int *tc)
+{
+   switch (tk->tk_user) {
+   case TC_TB:
+   *tc = rdtime();
+   return 0;
+   }
+
+   return -1;
+}
+
+int (*const _tc_get_timecount)(struct timekeep *, u_int *) = tc_get_timecount;


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



readelf(1) on riscv64: pretty-print machine name

2021-07-24 Thread Jeremie Courreges-Anglas


Before:
 Machine:   : f3
After:
 Machine:   RISC-V

ok?


Index: binutils/readelf.c
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/binutils/readelf.c,v
retrieving revision 1.22
diff -u -p -r1.22 readelf.c
--- binutils/readelf.c  3 May 2021 08:53:25 -   1.22
+++ binutils/readelf.c  24 Jul 2021 16:06:13 -
@@ -1733,6 +1733,7 @@ get_machine_name (unsigned e_machine)
 case EM_ALTERA_NIOS2:  return "Altera Nios II";
 case EM_XC16X: return "Infineon Technologies xc16x";
 case EM_AARCH64:   return "AArch64";
+case EM_RISCV: return "RISC-V";
 default:
   snprintf (buff, sizeof (buff), _(": %x"), e_machine);
   return buff;


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: riscv64: slightly optimized copyin/copyout/kcopy

2021-07-23 Thread Jeremie Courreges-Anglas
On Fri, Jul 23 2021, Mark Kettenis  wrote:
>> From: Jeremie Courreges-Anglas 
>> Date: Fri, 23 Jul 2021 11:54:51 +0200
>> Content-Type: text/plain
>> 
>> 
>> I've been using a variation of this diff on my hifive unmatched since
>> a few days.  The goal is to at least optimize the aligned cases by using
>> 8 or 4 bytes loads/stores.  On this hifive unmatched, I found that
>> unaligned 8 or 4 bytes loads/stores loops are utterly slow, much slower
>> than equivalent 1 byte loads/stores (say 40x slower).
>> 
>> This improves eg i/o throughput and shaves off between 10 and 15s out of
>> a total 11m30s in ''make clean; make -j4'' kernel builds.
>> 
>> I have another diff that tries to re-align initially unaligned addresses
>> if possible but it's uglier and it's hard to tell whether it makes any
>> difference in real life.
>> 
>> ok?
>> 
>> 
>> Index: copy.S
>> ===
>> RCS file: /d/cvs/src/sys/arch/riscv64/riscv64/copy.S,v
>> retrieving revision 1.6
>> diff -u -p -p -u -r1.6 copy.S
>> --- copy.S   28 Jun 2021 18:53:10 -  1.6
>> +++ copy.S   23 Jul 2021 07:45:16 -
>> @@ -49,8 +49,38 @@ ENTRY(copyin)
>>  SWAP_FAULT_HANDLER(a3, a4, a5)
>>  ENTER_USER_ACCESS(a4)
>>  
>> -// XXX optimize?
>>  .Lcopyio:
>> +.Lcopy8:
>> +li  a5, 8
>> +bltua2, a5, .Lcopy4
>> +
>> +or  a7, a0, a1
>> +andia7, a7, 7
>> +bneza7, .Lcopy4
>> +
>> +1:  ld  a4, 0(a0)
>> +addia0, a0, 8
>> +sd  a4, 0(a1)
>> +addia1, a1, 8
>> +addia2, a2, -8
>> +bgtua2, a5, 1b
>
> Shouldn't this be
>
>   bgeua2, a5, 1b

Yes, that's better ideed, thanks!  Updated diff.


Index: copy.S
===
RCS file: /d/cvs/src/sys/arch/riscv64/riscv64/copy.S,v
retrieving revision 1.6
diff -u -p -p -u -r1.6 copy.S
--- copy.S  28 Jun 2021 18:53:10 -  1.6
+++ copy.S  23 Jul 2021 11:52:54 -
@@ -49,8 +49,38 @@ ENTRY(copyin)
SWAP_FAULT_HANDLER(a3, a4, a5)
ENTER_USER_ACCESS(a4)
 
-// XXX optimize?
 .Lcopyio:
+.Lcopy8:
+   li  a5, 8
+   bltua2, a5, .Lcopy4
+
+   or  a7, a0, a1
+   andia7, a7, 7
+   bneza7, .Lcopy4
+
+1: ld  a4, 0(a0)
+   addia0, a0, 8
+   sd  a4, 0(a1)
+   addia1, a1, 8
+   addia2, a2, -8
+   bgeua2, a5, 1b
+
+.Lcopy4:
+   li  a5, 4
+   bltua2, a5, .Lcopy1
+
+   andia7, a7, 3
+   bneza7, .Lcopy1
+
+1: lw  a4, 0(a0)
+   addia0, a0, 4
+   sw  a4, 0(a1)
+   addia1, a1, 4
+   addia2, a2, -4
+   bgeua2, a5, 1b
+
+.Lcopy1:
+   beqza2, .Lcopy0
 1: lb  a4, 0(a0)
addia0, a0, 1
sb  a4, 0(a1)
@@ -58,6 +88,7 @@ ENTRY(copyin)
addia2, a2, -1
bneza2, 1b
 
+.Lcopy0:
EXIT_USER_ACCESS(a4)
SET_FAULT_HANDLER(a3, a4)
 .Lcopyiodone:


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



riscv64: slightly optimized copyin/copyout/kcopy

2021-07-23 Thread Jeremie Courreges-Anglas


I've been using a variation of this diff on my hifive unmatched since
a few days.  The goal is to at least optimize the aligned cases by using
8 or 4 bytes loads/stores.  On this hifive unmatched, I found that
unaligned 8 or 4 bytes loads/stores loops are utterly slow, much slower
than equivalent 1 byte loads/stores (say 40x slower).

This improves eg i/o throughput and shaves off between 10 and 15s out of
a total 11m30s in ''make clean; make -j4'' kernel builds.

I have another diff that tries to re-align initially unaligned addresses
if possible but it's uglier and it's hard to tell whether it makes any
difference in real life.

ok?


Index: copy.S
===
RCS file: /d/cvs/src/sys/arch/riscv64/riscv64/copy.S,v
retrieving revision 1.6
diff -u -p -p -u -r1.6 copy.S
--- copy.S  28 Jun 2021 18:53:10 -  1.6
+++ copy.S  23 Jul 2021 07:45:16 -
@@ -49,8 +49,38 @@ ENTRY(copyin)
SWAP_FAULT_HANDLER(a3, a4, a5)
ENTER_USER_ACCESS(a4)
 
-// XXX optimize?
 .Lcopyio:
+.Lcopy8:
+   li  a5, 8
+   bltua2, a5, .Lcopy4
+
+   or  a7, a0, a1
+   andia7, a7, 7
+   bneza7, .Lcopy4
+
+1: ld  a4, 0(a0)
+   addia0, a0, 8
+   sd  a4, 0(a1)
+   addia1, a1, 8
+   addia2, a2, -8
+   bgtua2, a5, 1b
+
+.Lcopy4:
+   li  a5, 4
+   bltua2, a5, .Lcopy1
+
+   andia7, a7, 3
+   bneza7, .Lcopy1
+
+1: lw  a4, 0(a0)
+   addia0, a0, 4
+   sw  a4, 0(a1)
+   addia1, a1, 4
+   addia2, a2, -4
+   bgtua2, a5, 1b
+
+.Lcopy1:
+   beqza2, .Lcopy0
 1: lb  a4, 0(a0)
addia0, a0, 1
sb  a4, 0(a1)
@@ -58,6 +88,7 @@ ENTRY(copyin)
addia2, a2, -1
bneza2, 1b
 
+.Lcopy0:
EXIT_USER_ACCESS(a4)
SET_FAULT_HANDLER(a3, a4)
 .Lcopyiodone:


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: ksh: require expression in while loop

2021-07-05 Thread Jeremie Courreges-Anglas
On Sun, Jul 04 2021, Todd C. Miller  wrote:
> On Sun, 04 Jul 2021 23:25:25 +0200, Alexander Hall wrote:
>
>> The "... do done" variant has been frequently used by me, and seems to appear
>>  at least three times in install.sub, so if this goes in, please scan the scr
>> ipts in our tree first, at least for trivial cases.
>
> Fair enough, let's just require a non-empty expression but still
> allow an empty loop body.

> Index: bin/ksh/syn.c
> ===
> RCS file: /cvs/src/bin/ksh/syn.c,v
> retrieving revision 1.39
> diff -u -p -u -r1.39 syn.c
> --- bin/ksh/syn.c 24 Apr 2018 08:25:16 -  1.39
> +++ bin/ksh/syn.c 4 Jul 2021 22:21:39 -
> @@ -331,6 +331,8 @@ get_command(int cf)
>   nesting_push(_nesting, c);
>   t = newtp((c == WHILE) ? TWHILE : TUNTIL);
>   t->left = c_list(true);
> + if (t->left == NULL)
> + syntaxerr(NULL);
>   t->right = dogroup();
>   nesting_pop(_nesting);
>   break;
>

LGTM as a first step, ok jca@

> It would be a good idea to call this out
> as a portability issue in the ksh manual but that can be done
> separately.

I'd prefer to fix the odd uses we have in tree and end up with your
initial diff in a third step.

Here are the three cases pointed out by halex@, mechanical diff.

ok? / Todd, feel free to pick it up with my ok.


Index: install.sub
===
RCS file: /d/cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1165
diff -u -p -p -u -r1.1165 install.sub
--- install.sub 3 Jun 2021 15:05:55 -   1.1165
+++ install.sub 5 Jul 2021 13:02:37 -
@@ -223,7 +223,7 @@ tmpdir() {
 unique_filename() {
local _fn=$1 _ufn
 
-   while _ufn=${_fn}.$RANDOM && [[ -e $_ufn ]]; do done
+   while _ufn=${_fn}.$RANDOM && [[ -e $_ufn ]]; do :; done
print -- "$_ufn"
 }
 
@@ -530,7 +530,7 @@ configure_disk() {
 
 # Acquire lock.
 lock() {
-   while ! mkdir /tmp/i/lock 2>/dev/null && sleep .1; do done
+   while ! mkdir /tmp/i/lock 2>/dev/null && sleep .1; do :; done
 }
 
 # Release lock.
@@ -765,7 +765,7 @@ _ask() {
 ask() {
 
# Prompt again in case the dmesg listener detected a change.
-   while ! _ask "$1" "$2"; do done
+   while ! _ask "$1" "$2"; do :; done
log_answers "$1" "$resp"
 }
 
 

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: tcpdump: print 802.11 sequence numbers properly

2021-06-28 Thread Jeremie Courreges-Anglas
On Mon, Jun 28 2021, Stefan Sperling  wrote:
> tcpdump -e -v -y IEEE802_11_RADIO currently prints sequence number
> and fragment number as a combined decimal value.
>
> This patch makes tcpdump display these values separately which is a lot
> easier to follow along as packets scroll by.
>
> ok?

ok jca@

> diff 18a81a05d6e3098eadc4b5e23d6656377f87591a /usr/src
> blob - 7528f50e45765f83d5d719d831df2880838bc28c
> file + usr.sbin/tcpdump/print-802_11.c
> --- usr.sbin/tcpdump/print-802_11.c
> +++ usr.sbin/tcpdump/print-802_11.c
> @@ -162,7 +162,9 @@ ieee80211_hdr(struct ieee80211_frame *wh)
>   u_int16_t seq;
>   TCARR(wh->i_seq);
>   bcopy(wh->i_seq, , sizeof(u_int16_t));
> - printf(" (seq %u): ", letoh16(seq));
> + printf(" (seq %u frag %u): ",
> + letoh16(seq) >> IEEE80211_SEQ_SEQ_SHIFT,
> + letoh16(seq) & IEEE80211_SEQ_FRAG_MASK);
>   } else
>   printf(": ");
>  
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



base-gcc: fix -Wno-error=uninitialized

2021-06-23 Thread Jeremie Courreges-Anglas


In base-gcc -Wno-error=uninitialized is currently ineffective, in that
cc1 still errors out with the following flags combination:

  billy /tmp$ cat t.c
  #include 

  int
  f(void)
  {
  int r;
  return r;
  }
  billy /tmp$ gcc -v -c -O2 -Wall -Werror  -Wno-error=uninitialized t.c

Previous behavior:

  [...]
  cc1.old: warnings being treated as errors
  t.c: In function 'f':
  t.c:7: warning: 'r' is used uninitialized in this function
  billy /tmp$ echo $?
  1
  billy /tmp$

After the patch (expected behavior):

  billy /tmp$ gcc -c -O2 -Wall -Werror -Wno-error=uninitialized t.c
  t.c: In function 'f':
  t.c:7: warning: 'r' is used uninitialized in this function
  billy /tmp$ echo $?
  0
  billy /tmp$

I know that base-gcc is low priority on our roadmap so I'll explain the
rationale for this diff:

I had plans for using -Wall -Werror -Wno-error=uninitialized in our
kernel builds, but those plans went nowhere - so far.  One of the
problems was adding more differences between clang and gcc in kernel
Makefiles (because -Wno-error=uninitialized didn't work with base-gcc).
Another problem was (in my mind at least) base-gcc spewing lots of bogus
"may be used uninitialized" warnings.  I have another possible fix
for that.

Anyway, I'd like to see where those tiny fixes can lead us.  Even if the
answer is "nowhere", the fix below is simple and worth committing
I think.

(If you care about how it works, see diagnostic_report_diagnostic() and
diagnostic_action_after_output() in diagnostic.c)

ok?


Index: tree-ssa.c
===
RCS file: /cvs/src/gnu/gcc/gcc/tree-ssa.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 tree-ssa.c
--- tree-ssa.c  15 Oct 2009 17:11:28 -  1.1.1.1
+++ tree-ssa.c  21 Jun 2021 23:37:37 -
@@ -1177,7 +1177,7 @@ warn_uninit (tree t, const char *gmsgid,
   locus = (context != NULL && EXPR_HAS_LOCATION (context)
   ? EXPR_LOCUS (context)
   : _SOURCE_LOCATION (var));
-  warning (0, gmsgid, locus, var);
+  warning (OPT_Wuninitialized, gmsgid, locus, var);
   fun_locus = _SOURCE_LOCATION (cfun->decl);
   if (locus->file != fun_locus->file
   || locus->line < fun_locus->line


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: Patch: ksh: fix input handling for 4 byte UTF-8 sequences

2021-06-03 Thread Jeremie Courreges-Anglas
On Wed, Jun 02 2021, Ingo Schwarze  wrote:
> Hi,
>
> feeling hesitant to commit into ksh without at least one proper OK,
> i'm resending this patch here, sorry if i missed private feedback.

I found two mails in my drafts folder, sorry, you didn't miss any
feedback from me.

> What the existing code does:
> It tries to make sure that multi-byte UTF-8 characters get passed on by
> the shell without fragmentation, not one byte at time.  I heard people
> say that some software, for example tmux(1), may sometimes get confused
> when receiving a UTF-8 character in a piecemeal manner.
>
> Which problem needs fixing:
> Of the four-byte UTF-8 sequences, only a subset is identified by the
> existing code.  The other four-byte UTF-8 sequences still get chopped
> up resulting in individual bytes being passed on.
>
>
> I'm also adding a few comments as suggested by jca@.  Parsing of UTF-8
> is less trivial than one might think, witnessed once again by the fact
> that i got this code wrong in the first place.

Thanks for this, though I was mostly interested into a pointer to the
relevant standard document that was used.  Now that the checks match the
Unicode standard, I'm less confused.  You're now pointing readers to the
utf8(7) manpage.  Discussion for another diff: should this manpage list
valid sequences instead of invalid ones?

> I also changed "cc & 0x20" to "cc > 0x9f" and "cc & 0x30" to "cc > 0x8f"
> for uniformity and readabilty - UTF-8-parsing is bad enough without
> needless micro-optimization, right?

I don't see a reason to optimize this.  IMO the checks should look just
like in your proposal, which matches the table in section "Unicode
Encoding Forms" in UnicodeStandard-13.0.pdf.

> Note that even with the patch below, moving backward and forward
> over a blowfish icon on the command line still does not work because
> the character is width 2 and the ksh code intentionally does not
> use wcwidth(3).  But maybe it improves something in tmux?  Not sure.
>
> Either way, unless it causes regressions, this (or a further improved
> version) should go in because what is there is clearly wrong.
>
> OK?

ok jca@

>   Ingo
>
> Index: emacs.c
> ===
> RCS file: /cvs/src/bin/ksh/emacs.c,v
> retrieving revision 1.87
> diff -u -p -r1.87 emacs.c
> --- emacs.c   8 May 2020 14:30:42 -   1.87
> +++ emacs.c   13 May 2021 18:16:13 -
> @@ -1851,11 +1851,17 @@ x_e_getu8(char *buf, int off)
>   return -1;
>   buf[off++] = c;
>  
> - if (c == 0xf4)
> + /*
> +  * In the following, comments refer to violations of
> +  * the inequality tests at the ends of the lines.
> +  * See the utf8(7) manual page for details.
> +  */
> +
> + if ((c & 0xf8) == 0xf0 && c < 0xf5)  /* beyond Unicode */
>   len = 4;
>   else if ((c & 0xf0) == 0xe0)
>   len = 3;
> - else if ((c & 0xe0) == 0xc0 && c > 0xc1)
> + else if ((c & 0xe0) == 0xc0 && c > 0xc1)  /* use single byte */
>   len = 2;
>   else
>   len = 1;
> @@ -1865,9 +1871,10 @@ x_e_getu8(char *buf, int off)
>   if (cc == -1)
>   break;
>   if (isu8cont(cc) == 0 ||
> - (c == 0xe0 && len == 3 && cc < 0xa0) ||
> - (c == 0xed && len == 3 && cc & 0x20) ||
> - (c == 0xf4 && len == 4 && cc & 0x30)) {
> + (c == 0xe0 && len == 3 && cc < 0xa0) ||  /* use 2 bytes */
> + (c == 0xed && len == 3 && cc > 0x9f) ||  /* surrogates  */
> + (c == 0xf0 && len == 4 && cc < 0x90) ||  /* use 3 bytes */
> + (c == 0xf4 && len == 4 && cc > 0x8f)) {  /* beyond Uni. */
>   x_e_ungetc(cc);
>   break;
>   }
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: services(5): more cleanup

2021-05-16 Thread Jeremie Courreges-Anglas
On Sat, May 15 2021, Aisha Tammy  wrote:
> On 5/11/21 9:04 PM, Kurt Mosiejczuk wrote:
>> On Wed, May 12, 2021 at 01:13:55AM +0200, Jeremie Courreges-Anglas wrote:
>>
>>> I'd like to drop SWAT, unofficial and dropped by the samba project
>>> around the switch to samba4.
>>>> - moved smtps/465 to the standards section (rfc8314)
>>> The new service was named "submissions".  I guess we should use both
>>> that and the "smtps" alias.
>>> https://datatracker.ietf.org/doc/html/rfc8314#section-7.3
>>> ok?
> A quick question, does this mean that the port in pf.conf will also have
> to be renamed?
> I have a few machines which use something to the effect of `pass in on
> egress proto tcp to port smtps ...`.
> Will that be broken by this? Similarly smtpd.conf? Or do they do this
> port-name translation separately?

I'd suggest you do a quick test. ;)

> Best,
> Aisha
>
>> ok kmos
>>
>> --Kurt
>>
>>> Index: services
>>> ===
>>> RCS file: /d/cvs/src/etc/services,v
>>> retrieving revision 1.100
>>> diff -u -p -p -u -r1.100 services
>>> --- services5 May 2021 11:49:17 -   1.100
>>> +++ services11 May 2021 23:03:12 -
>>> @@ -123,7 +123,7 @@ microsoft-ds445/tcp # 
>>> Microsoft-DS
>>>   microsoft-ds  445/udp # Microsoft-DS
>>>   kpasswd   464/tcp # Kerberos 5 password 
>>> changing
>>>   kpasswd   464/udp # Kerberos 5 password 
>>> changing
>>> -smtps  465/tcp # mail message 
>>> submission (TLS)
>>> +submissions465/tcp smtps   # mail message 
>>> submission (TLS)
>>>   photuris  468/tcp # Photuris Key Management
>>>   photuris  468/udp
>>>   isakmp500/udp # ISAKMP key management
>>> @@ -296,7 +296,6 @@ kerberos_master 751/udp # 
>>> Kerberos 4
>>>   kerberos_master   751/tcp # Kerberos 4 kadmin
>>>   krb_prop  754/tcp hprop   # Kerberos slave propagation
>>>   krbupdate 760/tcp kreg# BSD Kerberos registration
>>> -swat   901/tcp # Samba Web 
>>> Administration Tool
>>>   datametrics   1645/udp
>>>   ekshell2  2106/tcp# Encrypted kshell - UColorado, 
>>> Boulder
>>>   webster   2627/tcp# Network dictionary
>>>
>>> -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE
>>> 1524 E7EE
>>>
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: panic(9): set panicstr atomically

2021-05-13 Thread Jeremie Courreges-Anglas
On Thu, May 13 2021, Jeremie Courreges-Anglas  wrote:
> On Wed, May 12 2021, Scott Cheloha  wrote:
>> Hi,
>>
>> In a separate mail thread, bluhm@ mentioned that panic(9) does not
>> cleanly handle multiple CPUs entering it simultaneously:
>>
>> https://marc.info/?l=openbsd-tech=161908805925325=2
>>
>> I'm unsure which part of panic(9) is causing the problem he mentions,
>> but one obvious issue I see is that panicstr is not set atomically,
>> so two CPUs entering panic(9) simultaneously may clobber panicbuf.
>>
>> If we set panicstr atomically only one CPU will write panicbuf.
>>
>> Thoughts?
>
> My understanding is that to set panicstr atomically and avoid clobbering,
> you only need atomic_cas_ptr.
>
> Your diff makes panicstr point to volatile data.  If intended, what's
> the rationale?  I don't see how it helps avoid races when one cpu
> "acquires" panicstr and then writes to panicbuf, and another CPU also
> enters panic but just tries to print panicbuf.

Maybe I should stress more that your diff looks like an improvement
overall and it solves a real world problem.  Even if I don't understand
the volatile addition, it probably can't hurt as is, so feel free to go
with other folks' oks.  :)

> If the goal was to mark panicstr itself as volatile, then you're
> probably trying to solve another problem (making writes to panicstr
> more instantly/widely visible?) and I *do not know* if that's the right
> approach (or even needed), but volatile comes with a cost.
>
> Take all of this with a grain of salt, I'm not in familiar territory
> here.
>
>> Index: kern/subr_prf.c
>> ===
>> RCS file: /cvs/src/sys/kern/subr_prf.c,v
>> retrieving revision 1.102
>> diff -u -p -r1.102 subr_prf.c
>> --- kern/subr_prf.c  28 Nov 2020 17:53:05 -  1.102
>> +++ kern/subr_prf.c  13 May 2021 00:04:28 -
>> @@ -97,7 +97,7 @@ struct mutex kprintf_mutex =
>>   */
>>  
>>  extern  int log_open;   /* subr_log: is /dev/klog open? */
>> -const   char *panicstr; /* arg to first call to panic (used as a flag
>> +volatile const char *panicstr; /* arg to first call to panic (used as a flag
>> to indicate that panic has already been called). */
>>  const   char *faultstr; /* page fault string */
>>  #ifdef DDB
>> @@ -195,12 +195,10 @@ panic(const char *fmt, ...)
>>  
>>  bootopt = RB_AUTOBOOT | RB_DUMP;
>>  va_start(ap, fmt);
>> -if (panicstr)
>> +if (atomic_cas_ptr(, NULL, panicbuf) != NULL)
>>  bootopt |= RB_NOSYNC;
>> -else {
>> +else
>>  vsnprintf(panicbuf, sizeof panicbuf, fmt, ap);
>> -panicstr = panicbuf;
>> -}
>>  va_end(ap);
>>  
>>  printf("panic: ");
>> Index: sys/systm.h
>> ===
>> RCS file: /cvs/src/sys/sys/systm.h,v
>> retrieving revision 1.153
>> diff -u -p -r1.153 systm.h
>> --- sys/systm.h  28 Apr 2021 09:42:04 -  1.153
>> +++ sys/systm.h  13 May 2021 00:04:28 -
>> @@ -71,7 +71,7 @@
>>   * patched by a stalking hacker.
>>   */
>>  extern int securelevel; /* system security level */
>> -extern const char *panicstr;/* panic message */
>> +extern volatile const char *panicstr;   /* panic message */
>>  extern const char *faultstr;/* fault message */
>>  extern const char version[];/* system version */
>>  extern const char copyright[];  /* system copyright */
>>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: panic(9): set panicstr atomically

2021-05-13 Thread Jeremie Courreges-Anglas
On Wed, May 12 2021, Scott Cheloha  wrote:
> Hi,
>
> In a separate mail thread, bluhm@ mentioned that panic(9) does not
> cleanly handle multiple CPUs entering it simultaneously:
>
> https://marc.info/?l=openbsd-tech=161908805925325=2
>
> I'm unsure which part of panic(9) is causing the problem he mentions,
> but one obvious issue I see is that panicstr is not set atomically,
> so two CPUs entering panic(9) simultaneously may clobber panicbuf.
>
> If we set panicstr atomically only one CPU will write panicbuf.
>
> Thoughts?

My understanding is that to set panicstr atomically and avoid clobbering,
you only need atomic_cas_ptr.

Your diff makes panicstr point to volatile data.  If intended, what's
the rationale?  I don't see how it helps avoid races when one cpu
"acquires" panicstr and then writes to panicbuf, and another CPU also
enters panic but just tries to print panicbuf.

If the goal was to mark panicstr itself as volatile, then you're
probably trying to solve another problem (making writes to panicstr
more instantly/widely visible?) and I *do not know* if that's the right
approach (or even needed), but volatile comes with a cost.

Take all of this with a grain of salt, I'm not in familiar territory
here.

> Index: kern/subr_prf.c
> ===
> RCS file: /cvs/src/sys/kern/subr_prf.c,v
> retrieving revision 1.102
> diff -u -p -r1.102 subr_prf.c
> --- kern/subr_prf.c   28 Nov 2020 17:53:05 -  1.102
> +++ kern/subr_prf.c   13 May 2021 00:04:28 -
> @@ -97,7 +97,7 @@ struct mutex kprintf_mutex =
>   */
>  
>  extern   int log_open;   /* subr_log: is /dev/klog open? */
> -constchar *panicstr; /* arg to first call to panic (used as a flag
> +volatile const char *panicstr; /* arg to first call to panic (used as a flag
>  to indicate that panic has already been called). */
>  constchar *faultstr; /* page fault string */
>  #ifdef DDB
> @@ -195,12 +195,10 @@ panic(const char *fmt, ...)
>  
>   bootopt = RB_AUTOBOOT | RB_DUMP;
>   va_start(ap, fmt);
> - if (panicstr)
> + if (atomic_cas_ptr(, NULL, panicbuf) != NULL)
>   bootopt |= RB_NOSYNC;
> - else {
> + else
>   vsnprintf(panicbuf, sizeof panicbuf, fmt, ap);
> - panicstr = panicbuf;
> - }
>   va_end(ap);
>  
>   printf("panic: ");
> Index: sys/systm.h
> ===
> RCS file: /cvs/src/sys/sys/systm.h,v
> retrieving revision 1.153
> diff -u -p -r1.153 systm.h
> --- sys/systm.h   28 Apr 2021 09:42:04 -  1.153
> +++ sys/systm.h   13 May 2021 00:04:28 -
> @@ -71,7 +71,7 @@
>   * patched by a stalking hacker.
>   */
>  extern int securelevel;  /* system security level */
> -extern const char *panicstr; /* panic message */
> +extern volatile const char *panicstr;/* panic message */
>  extern const char *faultstr; /* fault message */
>  extern const char version[]; /* system version */
>  extern const char copyright[];   /* system copyright */
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



services(5): more cleanup

2021-05-11 Thread Jeremie Courreges-Anglas
On Wed, May 05 2021, Stuart Henderson  wrote:
> On 2021/05/04 12:07, Jan Klemkow wrote:
>> Hi,
>> 
>> Add missing ftps defaults ports to servies(5).
>> 
>> OK?
>> 
>> bye,
>> Jan
>> 
>> Index: services
>> ===
>> RCS file: /cvs/src/etc/services,v
>> retrieving revision 1.99
>> diff -u -p -r1.99 services
>> --- services 18 Feb 2021 02:30:29 -  1.99
>> +++ services 4 May 2021 10:01:35 -
>> @@ -318,6 +318,10 @@ krb_prop754/tcp hprop   # 
>> Kerberos slav
>>  krbupdate   760/tcp kreg# BSD Kerberos registration
>>  supfilesrv  871/tcp # SUP server
>>  swat901/tcp # Samba Web 
>> Administration Tool
>> +ftps-data   989/tcp # ftp data over TLS/SSL
>> +ftps-data   989/udp # ftp data over TLS/SSL
>> +ftps990/tcp # ftp control over 
>> TLS/SSL
>> +ftps990/udp # ftp control over 
>> TLS/SSL
>
> I'm OK with adding the TCP ones (though ftp-over-tls always makes me
> want to rant...). It's not going to run on UDP though so I think those
> should not be added.

+2

> Every new entry in this file reduces the range available for dynamic
> port selection, so it would seem a good idea to cull a few if we're
> adding some. Here are some likely candidates;
>
> - removed a few UDP entries for protocols that won't use it
>
> - dropped some obsolete protocols

I'd like to drop SWAT, unofficial and dropped by the samba project
around the switch to samba4.

> - moved smtps/465 to the standards section (rfc8314)

The new service was named "submissions".  I guess we should use both
that and the "smtps" alias.
https://datatracker.ietf.org/doc/html/rfc8314#section-7.3

ok?


Index: services
===
RCS file: /d/cvs/src/etc/services,v
retrieving revision 1.100
diff -u -p -p -u -r1.100 services
--- services5 May 2021 11:49:17 -   1.100
+++ services11 May 2021 23:03:12 -
@@ -123,7 +123,7 @@ microsoft-ds445/tcp # 
Microsoft-DS
 microsoft-ds   445/udp # Microsoft-DS
 kpasswd464/tcp # Kerberos 5 password 
changing
 kpasswd464/udp # Kerberos 5 password 
changing
-smtps  465/tcp # mail message submission (TLS)
+submissions465/tcp smtps   # mail message submission (TLS)
 photuris   468/tcp # Photuris Key Management
 photuris   468/udp
 isakmp 500/udp # ISAKMP key management
@@ -296,7 +296,6 @@ kerberos_master 751/udp # 
Kerberos 4 
 kerberos_master751/tcp # Kerberos 4 kadmin
 krb_prop   754/tcp hprop   # Kerberos slave propagation
 krbupdate  760/tcp kreg# BSD Kerberos registration
-swat   901/tcp # Samba Web Administration Tool
 datametrics1645/udp
 ekshell2   2106/tcp# Encrypted kshell - UColorado, 
Boulder
 webster2627/tcp# Network dictionary

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: apmd/apm: propagate failure to apm, make apm report failure

2021-04-06 Thread Jeremie Courreges-Anglas
On Wed, Apr 07 2021, Klemens Nanni  wrote:
> On Tue, Apr 06, 2021 at 11:35:44PM +0200, Jeremie Courreges-Anglas wrote:

[...]

>> > @@ -321,40 +328,49 @@ handle_client(int sock_fd, int ctl_fd)
>> >return reply.newstate;
>> >  }
>> >  
>> > -void
>> > +int
>> >  suspend(int ctl_fd)
>> >  {
>> > +  int ret;
>> > +
>> >logmsg(LOG_NOTICE, "system suspending");
>> >power_status(ctl_fd, 1, NULL);
>> >do_etc_file(_PATH_APM_ETC_SUSPEND);
>> >sync();
>> >sleep(1);
>> > -  if (ioctl(ctl_fd, APM_IOC_SUSPEND, 0) == -1)
>> > +  if ((ret = ioctl(ctl_fd, APM_IOC_SUSPEND, 0)) == -1)
>> >logmsg(LOG_WARNING, "%s: %s", __func__, strerror(errno));
>> 
>> If you hit the error case logmsg() might clobber the errno and make it
>> unavailable later...
> Right, better use a "save_errno" in all three functions, then.

And those functions could return zero/errno, this saves a few more
lines.  ok?

BTW now handle_client() could stop setting newstate on error.  But as far as
I'm concerned that's for another day and another diff.



Index: apmd.c
===
RCS file: /cvs/src/usr.sbin/apmd/apmd.c,v
retrieving revision 1.104
diff -u -p -r1.104 apmd.c
--- apmd.c  6 Apr 2021 22:12:48 -   1.104
+++ apmd.c  6 Apr 2021 22:27:26 -
@@ -271,18 +271,15 @@ handle_client(int sock_fd, int ctl_fd)
switch (cmd.action) {
case SUSPEND:
reply.newstate = SUSPENDING;
-   if (suspend(ctl_fd) == -1)
-   reply.error = errno;
+   reply.error = suspend(ctl_fd);
break;
case STANDBY:
reply.newstate = STANDING_BY;
-   if (stand_by(ctl_fd) == -1)
-   reply.error = errno;
+   reply.error = stand_by(ctl_fd);
break;
case HIBERNATE:
reply.newstate = HIBERNATING;
-   if (hibernate(ctl_fd) == -1)
-   reply.error = errno;
+   reply.error = hibernate(ctl_fd);
break;
case SETPERF_LOW:
reply.newstate = NORMAL;
@@ -329,46 +326,58 @@ handle_client(int sock_fd, int ctl_fd)
 int
 suspend(int ctl_fd)
 {
-   int ret;
+   int error = 0;
 
logmsg(LOG_NOTICE, "system suspending");
power_status(ctl_fd, 1, NULL);
do_etc_file(_PATH_APM_ETC_SUSPEND);
sync();
sleep(1);
-   if ((ret = ioctl(ctl_fd, APM_IOC_SUSPEND, 0)) == -1)
+
+   if (ioctl(ctl_fd, APM_IOC_SUSPEND, 0) == -1) {
+   error = errno;
logmsg(LOG_WARNING, "%s: %s", __func__, strerror(errno));
-   return (ret);
+   }
+
+   return error;
 }
 
 int
 stand_by(int ctl_fd)
 {
-   int ret;
+   int error = 0;
 
logmsg(LOG_NOTICE, "system entering standby");
power_status(ctl_fd, 1, NULL);
do_etc_file(_PATH_APM_ETC_STANDBY);
sync();
sleep(1);
-   if ((ret = ioctl(ctl_fd, APM_IOC_STANDBY, 0)) == -1)
+
+   if (ioctl(ctl_fd, APM_IOC_STANDBY, 0) == -1) {
+   error = errno;
logmsg(LOG_WARNING, "%s: %s", __func__, strerror(errno));
-   return (ret);
+   }
+
+   return error;
 }
 
 int
 hibernate(int ctl_fd)
 {
-   int ret;
+   int error = 0;
 
logmsg(LOG_NOTICE, "system hibernating");
power_status(ctl_fd, 1, NULL);
do_etc_file(_PATH_APM_ETC_HIBERNATE);
sync();
sleep(1);
-   if ((ret = ioctl(ctl_fd, APM_IOC_HIBERNATE, 0)) == -1)
+
+   if (ioctl(ctl_fd, APM_IOC_HIBERNATE, 0) == -1) {
+   error = errno;
logmsg(LOG_WARNING, "%s: %s", __func__, strerror(errno));
-   return (ret);
+   }
+
+   return error;
 }
 
 void


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: apmd/apm: propagate failure to apm, make apm report failure

2021-04-06 Thread Jeremie Courreges-Anglas
On Fri, Apr 02 2021, Klemens Nanni  wrote:
> On Fri, Mar 26, 2021 at 10:49:53PM +0100, Klemens Nanni wrote:
>> On Fri, Mar 26, 2021 at 10:38:30PM +0100, Klemens Nanni wrote:
>> > apm(8) never knows gets the result of the requested power action carried
>> > out by apmd(8), so platforms without suspend/resume support behave like
>> > this:
>> > 
>> >$ zzz; echo $?
>> >Suspending system...
>> >0
>> >$ apm -z; echo $?
>> >System will enter suspend mode momentarily.
>> >0
>> > 
>> > Prior to the latest apmd commit there wasn't even a syslog message
>> > reporting any failure whatsoever.
>> > 
>> > 
>> > This diff adds an extra `int error' field to `struct apm_reply' which
>> > such that apmd has means to tell apm if something went in simple
>> > errno(2) fashion.
>> > 
>> > To do so I need to hoist the power action inside handle_client(),
>> > obviously before the reply it sent back to apm -- currently apmd replies
>> > *before* carrying out the requested power actions.
>> > 
>> > 
>> > On arm64 it looks like this then:
>> > 
>> >$ zzz; echo $?
>> >Suspending system...
>> >zzz: suspend: Operation not supported
>> >1
>> >$ apm -z; echo $?
>> >System will enter suspend mode momentarily.
>> >apm: suspend: Operation not supported
>> >1
>> > 
>> > amd64 notebooks for example keep suspending without error messages and
>> > exit zero as before, i.e. expected behaviour stays unchanged for
>> > platforms that already work.
>> > 
>> > Feedback? OK?
>> Correct diff without fat fingered sleep(3) this time.
> Anyone interested in this attempt to improve user experience on
> platforms without proper power management support?
>
> suspend/resume is just a special case;  in general I'm fond of programs
> telling me when things like ioctls go wrong.

Sorry for being late to the party.  I agree with the direction but
I have some changes on top.

> Index: usr.sbin/apm/apm.c
> ===
> RCS file: /cvs/src/usr.sbin/apm/apm.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 apm.c
> --- usr.sbin/apm/apm.c23 Sep 2020 05:50:26 -  1.37
> +++ usr.sbin/apm/apm.c2 Apr 2021 16:07:36 -
> @@ -97,6 +97,7 @@ do_zzz(int fd, enum apm_action action)
>   struct apm_command command;
>   struct apm_reply reply;
>   char *msg;
> + int ret;
>  
>   switch (action) {
>   case NONE:
> @@ -117,7 +118,10 @@ do_zzz(int fd, enum apm_action action)
>   }
>  
>   printf("%s...\n", msg);
> - exit(send_command(fd, , ));
> + ret = send_command(fd, , );
> + if (reply.error)
> + errx(1, "%s: %s", apm_state(reply.newstate), 
> strerror(reply.error));
> + exit(ret);
>  }
>  
>  static int
> @@ -418,5 +422,7 @@ balony:
>   default:
>   break;
>   }
> + if (reply.error)
> + errx(1, "%s: %s", apm_state(reply.newstate), 
> strerror(reply.error));
>   return (0);
>  }
> Index: usr.sbin/apmd/apm-proto.h
> ===
> RCS file: /cvs/src/usr.sbin/apmd/apm-proto.h,v
> retrieving revision 1.10
> diff -u -p -r1.10 apm-proto.h
> --- usr.sbin/apmd/apm-proto.h 23 Sep 2020 05:50:26 -  1.10
> +++ usr.sbin/apmd/apm-proto.h 2 Apr 2021 16:07:37 -
> @@ -64,6 +64,7 @@ struct apm_reply {
>   enum apm_perfmode perfmode;
>   int cpuspeed;
>   struct apm_power_info batterystate;
> + int error;
>  };
>  
>  #define APMD_VNO 3

You're changing the size/layout of the structure, so this should be
bumped to avoid weird behavior where apm and apmd are out of sync.

> @@ -71,3 +72,4 @@ struct apm_reply {
>  extern const char *battstate(int state);
>  extern const char *ac_state(int state);
>  extern const char *perf_mode(int mode);
> +extern const char *apm_state(int apm_state);
> Index: usr.sbin/apmd/apmd.c
> ===
> RCS file: /cvs/src/usr.sbin/apmd/apmd.c,v
> retrieving revision 1.102
> diff -u -p -r1.102 apmd.c
> --- usr.sbin/apmd/apmd.c  25 Mar 2021 20:46:55 -  1.102
> +++ usr.sbin/apmd/apmd.c  2 Apr 2021 16:07:37 -
> @@ -65,9 +65,9 @@ void usage(void);
>  int power_status(int fd, int force, struct apm_power_info *pinfo);
>  int bind_socket(const char *sn);
>  enum apm_state handle_client(int sock_fd, int ctl_fd);
> -void suspend(int ctl_fd);
> -void stand_by(int ctl_fd);
> -void hibernate(int ctl_fd);
> +int suspend(int ctl_fd);
> +int stand_by(int ctl_fd);
> +int hibernate(int ctl_fd);
>  void resumed(int ctl_fd);
>  void setperfpolicy(char *policy);
>  void sigexit(int signo);
> @@ -266,16 +266,23 @@ handle_client(int sock_fd, int ctl_fd)
>   return NORMAL;
>   }
>  
> + reply.error = 0;
>   power_status(ctl_fd, 0, );
>   switch (cmd.action) {
>   case SUSPEND:
>   reply.newstate = SUSPENDING;
> + if (suspend(ctl_fd) == -1)
> +  

Re: arm64: make cwfg(4) report battery information to apm(4)

2021-03-24 Thread Jeremie Courreges-Anglas
On Wed, Mar 24 2021, Klemens Nanni  wrote:
> On Wed, Mar 24, 2021 at 12:49:51AM +0100, Jeremie Courreges-Anglas wrote:
>  
>> >> > @@ -202,6 +217,12 @@ cwfg_attach(struct device *parent, struc
>> >> >  
>> >> > sensor_task_register(sc, cwfg_update_sensors, 5);
>> >> >  
>> >> > +#if NAPM > 0
>> >> > +   /* make sure we have the apm state initialized before apm 
>> >> > attaches */
>> >> > +   cwfg_update_sensors(sc);
>> >> > +   apm_setinfohook(cwfg_apminfo);
>> >> > +#endif
>> >> > +
>> >> > printf("\n");
>> >> >  }
>> >> >  
>> >> > @@ -324,6 +345,7 @@ cwfg_update_sensors(void *arg)
>> >> > uint32_t vcell, rtt, tmp;
>> >> > uint8_t val;
>> >> > int error, n;
>> >> > +   u_char bat_percent;
>> >> >  
>> >> > if ((error = cwfg_lock(sc)) != 0)
>> >> > return;
>> >> > @@ -348,6 +370,7 @@ cwfg_update_sensors(void *arg)
>> >> > if ((error = cwfg_read(sc, SOC_HI_REG, )) != 0)
>> >> > goto done;
>> >> > if (val != 0xff) {
>> >> > +   bat_percent = val;
>> >> > sc->sc_sensor[CWFG_SENSOR_SOC].value = val * 1000;
>> >> > sc->sc_sensor[CWFG_SENSOR_SOC].flags &= 
>> >> > ~SENSOR_FINVALID;
>> >> > }
>> >> 
>> >> If val == 0xff bat_percent is unitialized.  Note that in this error
>> >> condition the sensors code leaves sc->sc_sensor[CWFG_SENSOR_SOC].value
>> >> alone.
>> > Oops.  Both `val' and `rtt' can be "useless" and we could end up with
>> > a partially updated `cwfg_power'.
>> 
>> With the current code, rtt is always meaningful.  I was really talking
>> only about bat_percent being possibly uninitialized.
> Yes, `rtt' always means something but the code does not always populate
> the struct member with it from which I read unconditionally - this is
> what I meant.
>
> Hence, instead of always reading from it and possibly getting a stale
> value, the second diff makes sure that each update cycle resets every
> value and only updates those that come from a fresh reading.
>
>> > If we always reset all values up front and then update whatever is
>> > possible, we can avoid the intermediate variable completely and end up
>> > with `cwfg_power' providing consistent readings.
>> 
>> Except if reading one register fails and we take the goto done shortcut.
>> In that case sensors and apm get out of sync, which is bad IMHO.
> My intention was that I'd rather provide an all reset struct with a
> single value updated that is known to be good rather than lazily
> updating whatever is possible.
>
>> >> So to keep apm and sensors in sync I think it would be better to reuse
>> >> the cached sc->sc_sensor[CWFG_SENSOR_SOC].value.
>> > I did `sc->sc_sensor[CWFG_SENSOR_SOC].value / 1000' first but ended up
>> > with bogus values, hence the `bat_percent' buffer to avoid arithmetics.
>> >
>> >
>> >> I don't know whether the error condition mentioned above happens
>> >> frequently with this driver.  Reporting APM_BATT_ABSENT (and similar for
>> >> sensors) would be useful, and could be done in a subsequent step.
>> > But that isn't the case?  From apm(4):
>> >
>> >  APM_BATTERY_ABSENT
>> >   No battery installed.
>> >
>> > The driver just can't tell us enough, but the battery is still there
>> > (we get good percentage/liftime readings), so
>> >
>> >  APM_BATT_UNKNOWN
>> >   Cannot read the current battery state.
>> >
>> > is only appropiate here imho.
>> >
>> >
>> >> What's the underlying hardware, does it involve a pluggable battery?
>> > Nope, Pinebook Pro with one internal battery and AC.
>> 
>> Since the battery can't be removed in your pinebook, then obviously
>> APM_BATTERY_ABSENT isn't very meaningful.  But maybe the CellWise
>> hardware supports pluggable batteries.  Anyway...
>> 
>> The diff below is mostly your diff, except:
>> - statically initialize cwfg_power with proper values.  That way there's
>>   a reason less for in

Re: arm64: make cwfg(4) report battery information to apm(4)

2021-03-23 Thread Jeremie Courreges-Anglas
On Mon, Mar 22 2021, Klemens Nanni  wrote:
> Better diff at the end thanks to jca's eyeballing, see comments inline.
>
> kettenis:  I see room for improvement in our subsystems and their
> interactions, but I don't think the current situation is bad enough to
> leave those bits out for now.
>
> Feedback? OK?
>

[...]

>> > @@ -202,6 +217,12 @@ cwfg_attach(struct device *parent, struc
>> >  
>> >sensor_task_register(sc, cwfg_update_sensors, 5);
>> >  
>> > +#if NAPM > 0
>> > +  /* make sure we have the apm state initialized before apm attaches */
>> > +  cwfg_update_sensors(sc);
>> > +  apm_setinfohook(cwfg_apminfo);
>> > +#endif
>> > +
>> >printf("\n");
>> >  }
>> >  
>> > @@ -324,6 +345,7 @@ cwfg_update_sensors(void *arg)
>> >uint32_t vcell, rtt, tmp;
>> >uint8_t val;
>> >int error, n;
>> > +  u_char bat_percent;
>> >  
>> >if ((error = cwfg_lock(sc)) != 0)
>> >return;
>> > @@ -348,6 +370,7 @@ cwfg_update_sensors(void *arg)
>> >if ((error = cwfg_read(sc, SOC_HI_REG, )) != 0)
>> >goto done;
>> >if (val != 0xff) {
>> > +  bat_percent = val;
>> >sc->sc_sensor[CWFG_SENSOR_SOC].value = val * 1000;
>> >sc->sc_sensor[CWFG_SENSOR_SOC].flags &= ~SENSOR_FINVALID;
>> >}
>> 
>> If val == 0xff bat_percent is unitialized.  Note that in this error
>> condition the sensors code leaves sc->sc_sensor[CWFG_SENSOR_SOC].value
>> alone.
> Oops.  Both `val' and `rtt' can be "useless" and we could end up with
> a partially updated `cwfg_power'.

With the current code, rtt is always meaningful.  I was really talking
only about bat_percent being possibly uninitialized.

> If we always reset all values up front and then update whatever is
> possible, we can avoid the intermediate variable completely and end up
> with `cwfg_power' providing consistent readings.

Except if reading one register fails and we take the goto done shortcut.
In that case sensors and apm get out of sync, which is bad IMHO.

[...]

>> So to keep apm and sensors in sync I think it would be better to reuse
>> the cached sc->sc_sensor[CWFG_SENSOR_SOC].value.
> I did `sc->sc_sensor[CWFG_SENSOR_SOC].value / 1000' first but ended up
> with bogus values, hence the `bat_percent' buffer to avoid arithmetics.
>
>
>> I don't know whether the error condition mentioned above happens
>> frequently with this driver.  Reporting APM_BATT_ABSENT (and similar for
>> sensors) would be useful, and could be done in a subsequent step.
> But that isn't the case?  From apm(4):
>
>  APM_BATTERY_ABSENT
>   No battery installed.
>
> The driver just can't tell us enough, but the battery is still there
> (we get good percentage/liftime readings), so
>
>  APM_BATT_UNKNOWN
>   Cannot read the current battery state.
>
> is only appropiate here imho.
>
>
>> What's the underlying hardware, does it involve a pluggable battery?
> Nope, Pinebook Pro with one internal battery and AC.

Since the battery can't be removed in your pinebook, then obviously
APM_BATTERY_ABSENT isn't very meaningful.  But maybe the CellWise
hardware supports pluggable batteries.  Anyway...

The diff below is mostly your diff, except:
- statically initialize cwfg_power with proper values.  That way there's
  a reason less for initializing it early by forcefully calling
  cwfg_update_sensors().
- only update cwfg_power when we already fetched new values for sensors.

I hope that this approach will make changing the cwfg_update_sensors()
code easier.

If it works for you and you agree with this tweaked proposal, ok jca@


Index: cwfg.c
===
RCS file: /d/cvs/src/sys/dev/fdt/cwfg.c,v
retrieving revision 1.2
diff -u -p -p -u -r1.2 cwfg.c
--- cwfg.c  22 Mar 2021 18:37:26 -  1.2
+++ cwfg.c  23 Mar 2021 23:49:22 -
@@ -32,12 +32,15 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include 
 
 #include 
 
+#include "apm.h"
+
 #defineVERSION_REG 0x00
 #defineVCELL_HI_REG0x02
 #define VCELL_HI_MASK  0x3f
@@ -119,6 +122,22 @@ struct cfdriver cwfg_cd = {
NULL, "cwfg", DV_DULL
 };
 
+#if NAPM > 0
+struct apm_power_info cwfg_power = {
+   .battery_state = APM_BATT_UNKNOWN,
+   .ac_state = APM_AC_UNKNOWN,
+   .battery_life = 0,
+   .minutes_left = -1,
+};
+
+int
+cwfg_apminfo(struct apm_power_info *info)
+{
+   memcpy(info, _power, sizeof(*info));
+   return 0;
+}
+#endif
+
 int
 cwfg_match(struct device *parent, void *match, void *aux)
 {
@@ -202,6 +221,10 @@ cwfg_attach(struct device *parent, struc
 
sensor_task_register(sc, cwfg_update_sensors, 5);
 
+#if NAPM > 0
+   apm_setinfohook(cwfg_apminfo);
+#endif
+
printf("\n");
 }
 
@@ -350,6 +373,11 @@ cwfg_update_sensors(void *arg)
if (val != 0xff) {
sc->sc_sensor[CWFG_SENSOR_SOC].value = 

Re: arm64: make cwfg(4) report battery information to apm(4)

2021-03-21 Thread Jeremie Courreges-Anglas
On Sun, Mar 21 2021, Mark Kettenis  wrote:
>> Date: Sun, 21 Mar 2021 17:22:05 +0100
>> From: Klemens Nanni 
>> 
>> On Sun, Mar 21, 2021 at 02:02:00PM +0100, Mark Kettenis wrote:
>> > > Date: Sun, 21 Mar 2021 01:02:53 +0100
>> > > From: Klemens Nanni 
>> > > 
>> > > apm(4/arm64) merely provides an all zero/unknown stub for those values,
>> > > e.g. apm(8) output is useless.
>> > > 
>> > > Hardware sensors however provide the information:
>> > > 
>> > >  $ sysctl hw.sensors
>> > >  hw.sensors.rktemp0.temp0=32.22 degC (CPU)
>> > >  hw.sensors.rktemp0.temp1=33.89 degC (GPU)
>> > >  hw.sensors.cwfg0.volt0=3.76 VDC (battery voltage)
>> > >  hw.sensors.cwfg0.raw0=259 (battery remaining minutes)
>> > >  hw.sensors.cwfg0.percent0=58.00% (battery percent)
>> > > 
>> > > Diff below simply copies them over using apm_setinfohook()
>> > > (I've looked at sys/arch/loongson/dev/kb3310.c which does the same):
>> > > 
>> > >  $ apm
>> > >  Battery state: high, 58% remaining, 259 minutes life estimate
>> > >  A/C adapter state: not known
>> > >  Performance adjustment mode: auto (408 MHz)
>> > > 
>> > > Feedback? OK?
>> > 
>> > This doesn't scale.
>> What exactly does not scale?  The way how various drivers hook into
>> apm(4)?  I'm not familiar enough (yet) with the framework(s) to judge
>> their overall design and/or interop strategy off hand.
>
> Since there is no firmware abstraction like on i386 (and to some
> extent amd64) there will be many drivers that provide battery
> informarion on armv7/arm64.
>
>> > The whole apm(4) interface is too closely tied to the original APM
>> > BIOS model.  Even with acpi(4) it is a bit of a square peg for a round
>> > hole, for example on machines with more than one battery.
>> Right, there is hardware which doesn't fit this model and our apm* is
>> not exactly up to speed with those, but I still don't see actual issues
>> (as per above).
>> 
>> > I'm not even sure apm(8) should bother reporting some sort of battery
>> > status.
>> apm* showing battery information seems only naturally to me since that
>> is the driver/daemon/tool one issues power commands with, often based
>> on such information - think of `apmd -z 15':  given that I want my box
>> to safely suspend around 15% remaining battery, it seems only
>> consequential that apm* is the same tool I query such information with.
>
> apmd(8) and apm(8) are not the same tool though.  Having a deamon to
> run scripts on certain power-state changes makes some sense, but I'd
> argue that sensorsd(8) could be a reasonable place to implement this
> as well.

When I dived into the apm(4) and apmd(8) code I noted how redundant it
was considering sensorsd(8).  But the user interface of sensorsd(8)
needs a fair bit of pondering before it can be proposed as
a replacement.  sensorsd(8) is fairly generic and its configuration
format, while extensible, isn't easy to use.  To be fair I didn't even
try to make it execute stuff based on battery level.  I suspect it
would just be useful to execute commands based on changes in one driver,
when what you need to mimic apmd(8) is to merge the values coming from
different drivers.

> The need to run apmd(8) in order to suspend/hibernate is a bit of an
> historical wart.

It's not clear to me right now why this was needed and why it's not
needed anymore.

(I'm just talking about basic suspend/hibernate, not about the
nifty -z/-Z additions in apmd(8)).

> And we already removed powermanagement state support
> from apmd(8).  These days, users should probably just use
> /etc/sysctl.conf to set the powermanagement state instead of starting
> apmd(8) with the appropriate -A, -H or -L option.

Indeed, -A/-H/-L are just syntactical sugar.  I wouldn't mind seeing
them go.

>> > But if it does, my suggestion would be to make it use the
>> > sensors framework.  That would need some work though such that drivers
>> > can mark sensors as providing battery information.  Maybe add a
>> > SENSOR_FBATTERY flag?

Why the 'F' and not just SENSOR_BATTERY?

>> You mean apm(8) directly using sensor_find(9) or so to look for
>> suitable sensors instead of relaying values throuh apm(4)?
>
> That's a possibility.  But having apm(4) do that might be a useful
> middle ground as it would mean you don't have to change the userland
> tools just yet.

I'm not familiar at all with the sensors framework, but if presenting
the same simple apm(4) interface is doable using sensors, then you can
count me as a reviewer! :)

(I don't know where the apm(4) interface comes from, but it looks like
we have a bunch of ports also using it.)

> My main concern with your diff is having to add APM
> hooks in all the drivers...

Or maybe we need a nicer way to register APM hooks.  IIUC
apm_setinfohook was copied from miod's work on loongson where a single
driver is in charge, depending on the underlying hardware. So it
probably can't solve all use cases as is.

>> It sounds simpler in principal but that's just my naive guess;
>> I'll take a curious 

Re: arm64: make cwfg(4) report battery information to apm(4)

2021-03-21 Thread Jeremie Courreges-Anglas
On Sun, Mar 21 2021, Klemens Nanni  wrote:
> apm(4/arm64) merely provides an all zero/unknown stub for those values,
> e.g. apm(8) output is useless.
>
> Hardware sensors however provide the information:
>
>   $ sysctl hw.sensors
>   hw.sensors.rktemp0.temp0=32.22 degC (CPU)
>   hw.sensors.rktemp0.temp1=33.89 degC (GPU)
>   hw.sensors.cwfg0.volt0=3.76 VDC (battery voltage)
>   hw.sensors.cwfg0.raw0=259 (battery remaining minutes)
>   hw.sensors.cwfg0.percent0=58.00% (battery percent)
>
> Diff below simply copies them over using apm_setinfohook()
> (I've looked at sys/arch/loongson/dev/kb3310.c which does the same):
>
>   $ apm
>   Battery state: high, 58% remaining, 259 minutes life estimate
>   A/C adapter state: not known
>   Performance adjustment mode: auto (408 MHz)
>
> Feedback? OK?

Feedback:

> Index: dev/fdt/cwfg.c
> ===
> RCS file: /cvs/src/sys/dev/fdt/cwfg.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 cwfg.c
> --- dev/fdt/cwfg.c10 Jun 2020 17:51:21 -  1.1
> +++ dev/fdt/cwfg.c20 Mar 2021 23:43:13 -
> @@ -32,12 +32,15 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  
>  #include 
>  
>  #include 
>  
> +#include "apm.h"
> +
>  #define  VERSION_REG 0x00
>  #define  VCELL_HI_REG0x02
>  #define   VCELL_HI_MASK  0x3f
> @@ -119,6 +122,18 @@ struct cfdriver cwfg_cd = {
>   NULL, "cwfg", DV_DULL
>  };
>  
> +int cwfg_apminfo(struct apm_power_info *info);

Why out of the #if NAPM > 0 check?

> +#if NAPM > 0
> +struct apm_power_info cwfg_power;
> +
> +int
> +cwfg_apminfo(struct apm_power_info *info)
> +{
> + bcopy(_power, info, sizeof(*info));

There's no overlap between source and destination, better use memcpy.
(Else, better use memmove.)

> + return 0;
> +}
> +#endif
> +
>  int
>  cwfg_match(struct device *parent, void *match, void *aux)
>  {
> @@ -202,6 +217,12 @@ cwfg_attach(struct device *parent, struc
>  
>   sensor_task_register(sc, cwfg_update_sensors, 5);
>  
> +#if NAPM > 0
> + /* make sure we have the apm state initialized before apm attaches */
> + cwfg_update_sensors(sc);
> + apm_setinfohook(cwfg_apminfo);
> +#endif
> +
>   printf("\n");
>  }
>  
> @@ -324,6 +345,7 @@ cwfg_update_sensors(void *arg)
>   uint32_t vcell, rtt, tmp;
>   uint8_t val;
>   int error, n;
> + u_char bat_percent;
>  
>   if ((error = cwfg_lock(sc)) != 0)
>   return;
> @@ -348,6 +370,7 @@ cwfg_update_sensors(void *arg)
>   if ((error = cwfg_read(sc, SOC_HI_REG, )) != 0)
>   goto done;
>   if (val != 0xff) {
> + bat_percent = val;
>   sc->sc_sensor[CWFG_SENSOR_SOC].value = val * 1000;
>   sc->sc_sensor[CWFG_SENSOR_SOC].flags &= ~SENSOR_FINVALID;
>   }

If val == 0xff bat_percent is unitialized.  Note that in this error
condition the sensors code leaves sc->sc_sensor[CWFG_SENSOR_SOC].value
alone.

> @@ -363,6 +386,14 @@ cwfg_update_sensors(void *arg)
>   sc->sc_sensor[CWFG_SENSOR_RTT].value = rtt;
>   sc->sc_sensor[CWFG_SENSOR_RTT].flags &= ~SENSOR_FINVALID;
>   }
> +
> +#if NAPM > 0
> + cwfg_power.battery_state = bat_percent > sc->sc_alert_level ?
> + APM_BATT_HIGH : APM_BATT_LOW;

It's cool that this driver keeps track of the "alert level".  acpibat(4)
also does that on amd64, but the apm(4)-through-acpi(4) userland
interface just hardcodes levels:

/* running on battery */
pi->battery_life = remaining * 100 / capacity;
if (pi->battery_life > 50)
pi->battery_state = APM_BATT_HIGH;
else if (pi->battery_life > 25)
pi->battery_state = APM_BATT_LOW;
else
pi->battery_state = APM_BATT_CRITICAL;

Maybe the levels reported by hardware couldn't be trusted?  Or maybe
those hardcoded values were deemed good enough, back then.  Anyway, on
this new hardware I think it makes sense to just trust the exported
values and later act if we get reports.

> + cwfg_power.ac_state = APM_AC_UNKNOWN;

This kinda points out the need for an AC driver on this platform.
If done in another driver, the code will need to be changed.  But this
looks acceptable to me for now.

> + cwfg_power.battery_life = bat_percent;

So to keep apm and sensors in sync I think it would be better to reuse
the cached sc->sc_sensor[CWFG_SENSOR_SOC].value.

I don't know whether the error condition mentioned above happens
frequently with this driver.  Reporting APM_BATT_ABSENT (and similar for
sensors) would be useful, and could be done in a subsequent step.

What's the underlying hardware, does it involve a pluggable battery?

> + cwfg_power.minutes_left = sc->sc_sensor[CWFG_SENSOR_RTT].value;
> +#endif
>  
>  done:
>   cwfg_unlock(sc);
>

-- 
jca | PGP : 

Re: ftp: make use of getline(3)

2021-02-15 Thread Jeremie Courreges-Anglas
On Sun, Feb 14 2021, Christian Weisgerber  wrote:
> Christian Weisgerber:
>
>> > Make use of getline(3) in ftp(1).
>> > 
>> > Replace fparseln(3) with getline(3).  This removes the only use
>> > of libutil.a(fparseln.o) from the ramdisk.
>> > Replace a complicated fgetln(3) idiom with the much simpler getline(3).
>> 
>> OK?
>
> ping?

That's much nicer indeed.  ok jca@

> I've been fetching distfiles with it, and I also built a bsd.rd and
> performed a http install with it.

chunked encoding still works fine too.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: video(4) multiple opens

2021-02-12 Thread Jeremie Courreges-Anglas
On Wed, Feb 10 2021, Martin Pieuchot  wrote:

[...]

> Which fields is the new lock protecting?  Why isn't the KERNEL_LOCK()
> enough?

When I mentioned this potential lack of locking to Marcus, I was
mistaken.  Some of the functions in video.c are called from syscalls
that are marked NOLOCK.  But now that I have added some printf
debugging, I can see that the kernel lock is held in places where
I didn't expect it to be held (videoioctl, videoread, videoclose...).
So there's probably a layer of locking that I am missing.

Marcus, sorry for my misleading diff. O:)

*crawls back under his rock*
-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: unwind(8): open DNSSEC trustanchor late

2021-02-06 Thread Jeremie Courreges-Anglas
On Sat, Feb 06 2021, Florian Obser  wrote:
> On Sat, Feb 06, 2021 at 01:23:35AM +0100, Jeremie Courreges-Anglas wrote:
>> On Fri, Jan 29 2021, Florian Obser  wrote:
>> > Last piece of the puzzle...
>> >
>> > Re-try to open DNSSEC trust anchor file if /var is not mounted yet.
>> > With this we are able to start unwind before the network is up and
>> > partitions are mounted.
>> 
>> Sorry for being late to the party, I just upgraded to the latest snaps
>> and DNS broke.  Reverting this diff unbreaks unwind(8) operations.
>> 
>
> Could you be more specific what broke?

Yes, sorry for the lack of details.  I just didn't get any reply from
unwind(8).

Debug output with "preference { recursor }":

--8<--
shannon /usr/src/sbin/unwind$ sudo obj/unwind -dvv &
[1] 22635
shannon /usr/src/sbin/unwind$ fstat | grep unwind
_unwind  unwind 54878 text /usr/obj   103939  -rwxr-xr-x r 11104216
_unwind  unwind 54878   wd /var   155539  drwxr-xr-x r  512
_unwind  unwind 54878 root /var   155539  drwxr-xr-x r  512
_unwind  unwind 548780 /  104248  crw--wrwttyp6
_unwind  unwind 548781 /  104248  crw--wrwttyp6
_unwind  unwind 548782 /  104248  crw--wrwttyp6
_unwind  unwind 548783* unix stream 0x0
_unwind  unwind 548784 kqueue 0x0 0 state: W
_unwind  unwind 548785* unix stream 0x0
_unwind  unwind 548786* internet dgram udp 127.0.0.1:53
_unwind  unwind 548787* internet6 dgram udp [::1]:53
_unwind  unwind 548788* internet stream tcp 0x0 127.0.0.1:53
_unwind  unwind 548789* internet6 stream tcp 0x0 [::1]:53
_unwind  unwind 54878   10* unix stream 0x0 /dev/unwind.sock
_unwind  unwind 54878   11* route raw 0 0x0
_unwind  unwind 54878   12 /var   234193  -rw-r--r--   rwp  376
_unwind  unwind 39065 text /usr/obj   103939  -rwxr-xr-x r 11104216
_unwind  unwind 39065   wd /usr/src   398245  drwxr-xr-x r 4096
_unwind  unwind 390650 /  104248  crw--wrwttyp6
_unwind  unwind 390651 /  104248  crw--wrwttyp6
_unwind  unwind 390652 /  104248  crw--wrwttyp6
_unwind  unwind 390653* unix stream 0x0
_unwind  unwind 390654 kqueue 0x0 0 state: W
_unwind  unwind 390655* unix stream 0x0
root unwind 22635 text /usr/obj   103939  -rwxr-xr-x r 11104216
root unwind 22635   wd /usr/src   398245  drwxr-xr-x r 4096
root unwind 226350 /  104248  crw--wrwttyp6
root unwind 226351 /  104248  crw--wrwttyp6
root unwind 226352 /  104248  crw--wrwttyp6
root unwind 226353* unix stream 0x0
root unwind 226354 kqueue 0x0 0 state: W
root unwind 226355* unix stream 0x0
root unwind 22635   14* route raw 0 0x0
shannon /usr/src/sbin/unwind$ dig openbsd.org @127.0.0.1
from: [127.0.0.1]:14381
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 26482
;; flags: rd ad ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
openbsd.org.IN  A

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
; EDNS: version: 0; flags: ; udp: 4096
;; MSG SIZE  rcvd: 40

[127.0.0.1]:14381: openbsd.org. IN A ?
try_next_resolver: could not find (any more) working resolvers
from: [127.0.0.1]:14381
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 26482
;; flags: rd ad ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
openbsd.org.IN  A

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
; EDNS: version: 0; flags: ; udp: 4096
;; MSG SIZE  rcvd: 40

[127.0.0.1]:14381: openbsd.org. IN A ?
try_next_resolver: could not find (any more) working resolvers
from: [127.0.0.1]:14381
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 26482
;; flags: rd ad ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
openbsd.org.IN  A

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
; EDNS: version: 0; flags: ; udp: 4096
;; MSG SIZE  rcvd: 40

[127.0.0.1]:14381: openbsd.org. IN A ?
try_next_resolver: could not find (any more) working resolvers
[... etc etc]
^C
shannon /usr/src/sbin/unwind$
-->8--


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: unwind(8): open DNSSEC trustanchor late

2021-02-05 Thread Jeremie Courreges-Anglas
On Fri, Jan 29 2021, Florian Obser  wrote:
> Last piece of the puzzle...
>
> Re-try to open DNSSEC trust anchor file if /var is not mounted yet.
> With this we are able to start unwind before the network is up and
> partitions are mounted.

Sorry for being late to the party, I just upgraded to the latest snaps
and DNS broke.  Reverting this diff unbreaks unwind(8) operations.

My unwind.conf:

  preference { recursor }

(Can't reproduce this problem with an empty config file.)

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: getopt.3 bugs section

2021-01-09 Thread Jeremie Courreges-Anglas
On Sat, Jan 09 2021, Christian Weisgerber  wrote:
> Edgar Pettijohn:
>
>> In the BUGS section for the getopt(3) manual it mentions not using
>> single digits for options. I know spamd uses -4 and -6 there are
>> probably others. Should they be changed? Or is the manual mistaken?
>
> You misunderstand.  The manual warns against the use of digits to
> pass numerical arguments.  This usage exists in some historical
> cases, e.g. "nice -10" where <10> is the number 10.

IMO giving a *number* as an example would make things clearer.

Index: getopt.3
===
RCS file: /d/cvs/src/lib/libc/stdlib/getopt.3,v
retrieving revision 1.46
diff -u -p -p -u -r1.46 getopt.3
--- getopt.34 Jan 2016 19:43:13 -   1.46
+++ getopt.39 Jan 2021 13:39:06 -
@@ -326,7 +326,7 @@ It is possible to handle digits as optio
 This allows
 .Fn getopt
 to be used with programs that expect a number
-.Pq Dq Li \-3
+.Pq Dq Li \-389
 as an option.
 This practice is wrong, and should not be used in any current development.
 It is provided for backward compatibility


Other ideas for improvement:
- give a real life example

Index: getopt.3
===
RCS file: /d/cvs/src/lib/libc/stdlib/getopt.3,v
retrieving revision 1.46
diff -u -p -p -u -r1.46 getopt.3
--- getopt.34 Jan 2016 19:43:13 -   1.46
+++ getopt.39 Jan 2021 13:44:29 -
@@ -326,7 +326,7 @@ It is possible to handle digits as optio
 This allows
 .Fn getopt
 to be used with programs that expect a number
-.Pq Dq Li \-3
+.Pq Dq Li nice \-10 program
 as an option.
 This practice is wrong, and should not be used in any current development.
 It is provided for backward compatibility

- move this warning to CAVEATS, since it's not a bug

Index: getopt.3
===
RCS file: /d/cvs/src/lib/libc/stdlib/getopt.3,v
retrieving revision 1.46
diff -u -p -p -u -r1.46 getopt.3
--- getopt.34 Jan 2016 19:43:13 -   1.46
+++ getopt.39 Jan 2021 13:47:08 -
@@ -309,24 +309,12 @@ The
 .Fn getopt
 function appeared in
 .Bx 4.3 .
-.Sh BUGS
-The
-.Fn getopt
-function was once specified to return
-.Dv EOF
-instead of \-1.
-This was changed by
-.St -p1003.2-92
-to decouple
-.Fn getopt
-from
-.In stdio.h .
-.Pp
+.Sh CAVEATS
 It is possible to handle digits as option letters.
 This allows
 .Fn getopt
 to be used with programs that expect a number
-.Pq Dq Li \-3
+.Pq Dq Li nice \-10 program
 as an option.
 This practice is wrong, and should not be used in any current development.
 It is provided for backward compatibility
@@ -361,3 +349,15 @@ while ((ch = getopt(argc, argv, "0123456
prevoptind = optind;
 }
 .Ed
+.Sh BUGS
+The
+.Fn getopt
+function was once specified to return
+.Dv EOF
+instead of \-1.
+This was changed by
+.St -p1003.2-92
+to decouple
+.Fn getopt
+from
+.In stdio.h .


Would the mention of EOF vs -1 fit better in HISTORY or CAVEATS too?

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: video(4) multiple opens

2021-01-06 Thread Jeremie Courreges-Anglas
On Wed, Jan 06 2021, Marcus Glocker  wrote:
> On Tue, Jan 05, 2021 at 11:54:31PM +0100, Jeremie Courreges-Anglas wrote:

[...]

>> Here's the diff.  IIUC the use of atomic operations isn't strictly
>> needed here since open(2) runs with the kernel lock, but the result
>> is easy to understand IMO.
>
> I don't agree with that, see my comments bellow in point a) and b).
>  
>> Thoughts?  ok?
>
> I think it doesn't harm to allow the same process to do multiple opens
> on video(1) as a first improvement.  But I'm not happy using
> atomic_cas_ptr(9) and atomic_swap_ptr(9) for this because:
>
>   a) As you already have mentioned, we don't require atomic
>  operations here.  I checked that those functions are very
>  rarely used in the kernel, and only there were atomic
>  operation is required.  I'm afraid that when we use those in
>  video(1), and somebody looks at the code later on to
>  eventually replace it, there will be confusion if there was
>  a specific reason why to use atomic functions.
>
>   b) IMO it doesn't simplify the code.  I first had to read the
>  manual pages to understand how those functions work.

Fair enough, I also felt that it was a bit premature.

> I would prefer to do something simpler, like in this adapted diff.
> If it works for you, I'm OK if you commit this instead.

Done, thanks.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



video(4) multiple opens

2021-01-05 Thread Jeremie Courreges-Anglas


I hit a weird failure with firefox and BigBlueButton
(https://bigbluebutton.org/) where firefox can't use my webcam.
video(1) works, same for other webrtc sites in firefox, eg meet.jit.si.
ktrace shows that a single firefox process tries to open /dev/video0
more than once, and that fails with EBUSY.  The code lies in the
libwebrtc library

  
https://webrtc.googlesource.com/src/+/refs/heads/master/modules/video_capture/linux/

In my tests the multiple open() calls only happen at initialization
time, video streaming only uses one fd.

Back to our kernel, the current restrictive behavior was introduced with

  revision 1.18
  date: 2008/07/23 22:10:21;  author: mglocker;  state: Exp;  lines: +11 -4;
  If /dev/video* is already used by an application, return EBUSY to other
  applications.  Fixes a kernel panic.

  Reported by ian@

Meanwhile, the V4L2 API specifies that a device "can be opened more than
once" from multiple processes, with access to certain methods blocked
when an application starts reading from the device.

  
https://www.kernel.org/doc/html/v5.10/userspace-api/media/v4l/open.html#multiple-opens

So the API says we're being too restrictive, but we don't want to go
back to uncontrolled access either.  I guess the ideal solution would be
to implement multiple process access with fine-grained checks, but...
I don't have time for that!

An easy improvement for my use case would be to allow the same process
to open a device multiple times.  It fixes firefox + BigBlueButton for
me and doesn't make concurrent accesses worse (multiple threads from the
same process can already do concurrent accesses, which is something
we might want to look at).

Here's the diff.  IIUC the use of atomic operations isn't strictly
needed here since open(2) runs with the kernel lock, but the result
is easy to understand IMO.

Thoughts?  ok?


Index: dev/video.c
===
RCS file: /d/cvs/src/sys/dev/video.c,v
retrieving revision 1.46
diff -u -p -r1.46 video.c
--- dev/video.c 28 Dec 2020 18:28:11 -  1.46
+++ dev/video.c 5 Jan 2021 22:34:04 -
@@ -28,6 +28,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include 
@@ -46,8 +48,7 @@ struct video_softc {
struct device   *sc_dev;/* hardware device struct */
struct video_hw_if  *hw_if; /* hardware interface */
char sc_dying;  /* device detached */
-#define VIDEO_OPEN 0x01
-   char sc_open;
+   struct process  *sc_owner;  /* owner process */
 
int  sc_fsize;
uint8_t *sc_fbuffer;
@@ -101,6 +102,7 @@ videoattach(struct device *parent, struc
sc->hw_hdl = sa->hdl;
sc->sc_dev = parent;
sc->sc_fbufferlen = 0;
+   sc->sc_owner = NULL;
 
if (sc->hw_if->get_bufsize)
sc->sc_fbufferlen = (sc->hw_if->get_bufsize)(sc->hw_hdl);
@@ -121,6 +123,7 @@ videoopen(dev_t dev, int flags, int fmt,
 {
int unit;
struct video_softc *sc;
+   struct process *owner;
 
unit = VIDEOUNIT(dev);
if (unit >= video_cd.cd_ndevs ||
@@ -128,9 +131,13 @@ videoopen(dev_t dev, int flags, int fmt,
 sc->hw_if == NULL)
return (ENXIO);
 
-   if (sc->sc_open & VIDEO_OPEN)
-   return (EBUSY);
-   sc->sc_open |= VIDEO_OPEN;
+   owner = atomic_cas_ptr(>sc_owner, NULL, p->p_p);
+   if (owner != NULL) {
+   if (owner == p->p_p)
+   return (0);
+   else
+   return (EBUSY);
+   }
 
sc->sc_vidmode = VIDMODE_NONE;
sc->sc_frames_ready = 0;
@@ -153,7 +160,7 @@ videoclose(dev_t dev, int flags, int fmt
if (sc->hw_if->close != NULL)
r = sc->hw_if->close(sc->hw_hdl);
 
-   sc->sc_open &= ~VIDEO_OPEN;
+   atomic_swap_ptr(>sc_owner, NULL);
 
return (r);
 }


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: ftp(1): handle HTTP 308

2021-01-01 Thread Jeremie Courreges-Anglas
On Thu, Dec 31 2020, Lucas  wrote:
> Weekly bump

chrisz@ had a similar diff, already ok'd by kn@ and me.
Christopher, would you mind committing it?

> Index: fetch.c
> ===
> RCS file: /home/cvs/src/usr.bin/ftp/fetch.c,v
> retrieving revision 1.198
> diff -u -p -r1.198 fetch.c
> --- fetch.c   18 Oct 2020 20:35:18 -  1.198
> +++ fetch.c   24 Dec 2020 14:03:03 -
> @@ -843,6 +843,7 @@ noslash:
>   case 302:   /* Found */
>   case 303:   /* See Other */
>   case 307:   /* Temporary Redirect */
> + case 308:   /* Permanent Redirect */
>   isredirect++;
>   if (redirect_loop++ > 10) {
>   warnx("Too many redirections requested");
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: Fewer uvmexp

2020-11-18 Thread Jeremie Courreges-Anglas
On Wed, Nov 18 2020, Martin Pieuchot  wrote:
> While auditing the various uses of the uvmexp fields I came across
> those under #ifdet notyet.  May I delete them so I don't have to give
> them some MP love?  Ok?

ok jca@, but while here shouldn't the rest of cpu_vm_init() go too?
Unless I'm missing something it doesn't have side effects except
computing ncolors, and ncolors is meant to be used by the code you're
removing.

> Index: arch/amd64//amd64/cpu.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
> retrieving revision 1.150
> diff -u -p -r1.150 cpu.c
> --- arch/amd64//amd64/cpu.c   13 Sep 2020 11:53:16 -  1.150
> +++ arch/amd64//amd64/cpu.c   18 Nov 2020 13:11:17 -
> @@ -443,17 +443,6 @@ cpu_vm_init(struct cpu_info *ci)
>   }
>   ncolors = max(ncolors, tcolors);
>   }
> -
> -#ifdef notyet
> - /*
> -  * Knowing the size of the largest cache on this CPU, re-color
> -  * our pages.
> -  */
> - if (ncolors <= uvmexp.ncolors)
> - return;
> - printf("%s: %d page colors\n", ci->ci_dev->dv_xname, ncolors);
> - uvm_page_recolor(ncolors);
> -#endif
>  }
>  
>  
> Index: arch/luna88k/luna88k/isr.c
> ===
> RCS file: /cvs/src/sys/arch/luna88k/luna88k/isr.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 isr.c
> --- arch/luna88k/luna88k/isr.c28 Jun 2017 10:31:48 -  1.11
> +++ arch/luna88k/luna88k/isr.c18 Nov 2020 13:11:27 -
> @@ -151,10 +151,6 @@ isrdispatch_autovec(int ipl)
>   panic("isrdispatch_autovec: bad ipl %d", ipl);
>  #endif
>  
> -#if 0/* XXX: already counted in machdep.c */
> - uvmexp.intrs++;
> -#endif
> -
>   list = _autovec[ipl];
>   if (LIST_EMPTY(list)) {
>   printf("isrdispatch_autovec: ipl %d unexpected\n", ipl);
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: [PATCH] tcpdump: Fix missing argument from icmp_print call in print-skip.c

2020-11-03 Thread Jeremie Courreges-Anglas
On Tue, Nov 03 2020, Theo Buehler  wrote:
> On Tue, Nov 03, 2020 at 04:19:34PM +0530, Neeraj Pal wrote:
>> Hi all,
>> 
>> It seems that there is a typo, 2nd argument - length is missing from
>> the function call icmp_print in print-skip.c
>
> There is quite a bit more that is wrong with print-skip.c than just
> that (try to add it to the Makefile and compile it). It was unhooked
> from the build in 1996.
>
> Shouldn't it rather be sent to the attic?

I think it can be safely removed.  ok jca@

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: [PATCH] Mention unsupported stacking in softraid(4)

2020-10-25 Thread Jeremie Courreges-Anglas
On Sun, Oct 25 2020, "Filippo Valsorda"  wrote:
> Based on the text in faq14.html, but using the manpage language.

Makes sense.  I'm not sure .Em is useful here, though.

ok jca@ if someone wants to pick this up, else I'll just commit it in
a few hours.

Thanks,

> diff --git share/man/man4/softraid.4 share/man/man4/softraid.4
> index 4fa72dd6e..98897c7dd 100644
> --- share/man/man4/softraid.4
> +++ share/man/man4/softraid.4
> @@ -201,6 +201,10 @@ There is no point in wasting a lot of time syncing 
> random data.
>  The RAID 5 discipline does not initialize parity upon creation, instead 
> parity
>  is only updated upon write.
>  .Pp
> +Stacking disciplines (CRYPTO on top of RAID 1, for example) is
> +.Em not supported
> +at this time.
> +.Pp
>  Currently there is no automated mechanism to recover from failed disks.
>  .Pp
>  Certain RAID levels can protect against some data loss
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: Non-const basename: usr.bin/ftp

2020-10-17 Thread Jeremie Courreges-Anglas
On Thu, Oct 15 2020, Christian Weisgerber  wrote:
> Accommodate POSIX basename(3) that takes a non-const parameter and
> may modify the string buffer.
>
> I've tried to follow the conventions of the existing code.
>
> ok?
>
> Index: usr.bin/ftp/fetch.c
> ===
> RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
> retrieving revision 1.197
> diff -u -p -r1.197 fetch.c
> --- usr.bin/ftp/fetch.c   4 Jul 2020 11:23:35 -   1.197
> +++ usr.bin/ftp/fetch.c   15 Oct 2020 21:14:28 -
> @@ -192,7 +192,7 @@ file_get(const char *path, const char *o
>   int  fd, out = -1, rval = -1, save_errno;
>   volatile sig_t   oldintr, oldinti;
>   const char  *savefile;
> - char*buf = NULL, *cp;
> + char*buf = NULL, *cp, *pathbuf = NULL;
>   const size_t buflen = 128 * 1024;
>   off_thashbytes;
>   ssize_t  len, wlen;
> @@ -215,8 +215,12 @@ file_get(const char *path, const char *o
>   else {
>   if (path[strlen(path) - 1] == '/')  /* Consider no file */
>   savefile = NULL;/* after dir invalid. */
> - else
> - savefile = basename(path);
> + else {
> + pathbuf = strdup(path);
> + if (pathbuf == NULL)
> + errx(1, "Can't allocate memory for filename");
> + savefile = basename(pathbuf);
> + }
>   }
>  
>   if (EMPTYSTRING(savefile)) {
> @@ -294,6 +298,7 @@ file_get(const char *path, const char *o
>  
>  cleanup_copy:
>   free(buf);
> + free(pathbuf);
>   if (out >= 0 && out != fileno(stdout))
>   close(out);
>   close(fd);
> @@ -315,6 +320,7 @@ url_get(const char *origline, const char
>   int isunavail = 0, retryafter = -1;
>   struct addrinfo hints, *res0, *res;
>   const char *savefile;
> + char *pathbuf = NULL;
>   char *proxyurl = NULL;
>   char *credentials = NULL, *proxy_credentials = NULL;
>   int fd = -1, out = -1;
> @@ -412,8 +418,12 @@ noslash:
>   else {
>   if (path[strlen(path) - 1] == '/')  /* Consider no file */
>   savefile = NULL;/* after dir invalid. */
> - else
> - savefile = basename(path);
> + else {
> + pathbuf = strdup(path);
> + if (pathbuf == NULL)
> + errx(1, "Can't allocate memory for filename");
> + savefile = basename(pathbuf);
> + }
>   }
>  
>   if (EMPTYSTRING(savefile)) {
> @@ -1106,6 +1116,7 @@ cleanup_url_get:
>   if (out >= 0 && out != fileno(stdout))
>   close(out);
>   free(buf);
> + free(pathbuf);
>   free(proxyhost);
>   free(proxyurl);
>   free(newline);
> Index: usr.bin/ftp/util.c
> ===
> RCS file: /cvs/src/usr.bin/ftp/util.c,v
> retrieving revision 1.93
> diff -u -p -r1.93 util.c
> --- usr.bin/ftp/util.c6 Jul 2020 17:11:29 -   1.93
> +++ usr.bin/ftp/util.c15 Oct 2020 21:31:55 -
> @@ -763,7 +763,7 @@ progressmeter(int flag, const char *file
>   off_t cursize, abbrevsize;
>   double elapsed;
>   int ratio, barlength, i, remaining, overhead = 30;
> - char buf[512];
> + char buf[512], *filenamebuf;
>  
>   if (flag == -1) {
>   clock_gettime(CLOCK_MONOTONIC, );
> @@ -782,11 +782,13 @@ progressmeter(int flag, const char *file
>   ratio = MAXIMUM(ratio, 0);
>   ratio = MINIMUM(ratio, 100);
>   if (!verbose && flag == -1) {
> - filename = basename(filename);
> - if (filename != NULL) {
> + filenamebuf = strdup(filename);
> + filename = basename(filenamebuf);
> + if (filenamebuf != NULL && filename != NULL) {

Can basename(3) handle a NULL input?  Yes, but I had to check, and the
semantics in this case are weird.  IMO it's better to do the error
checking in a more usual way, something like the diff below.

If you're fine with that, ok jca@


Index: util.c
===
RCS file: /d/cvs/src/usr.bin/ftp/util.c,v
retrieving revision 1.93
diff -u -p -p -u -r1.93 util.c
--- util.c  6 Jul 2020 17:11:29 -   1.93
+++ util.c  17 Oct 2020 12:20:27 -
@@ -763,7 +763,7 @@ progressmeter(int flag, const char *file
off_t cursize, abbrevsize;
double elapsed;
int ratio, barlength, i, remaining, overhead = 30;
-   char buf[512];
+   char buf[512], *filenamebuf;
 
if (flag == -1) {
clock_gettime(CLOCK_MONOTONIC, );
@@ -782,11 +782,12 @@ progressmeter(int flag, const char *file
ratio = MAXIMUM(ratio, 0);
ratio = 

Re: apmd(8) and hw.perfpolicy quirks

2020-09-27 Thread Jeremie Courreges-Anglas
On Thu, Sep 24 2020, Jeremie Courreges-Anglas  wrote:
> On Wed, Sep 23 2020, "Ted Unangst"  wrote:
>> On 2020-09-23, Jeremie Courreges-Anglas wrote:
>>
>>> ok?
>>
>> Seems fine.
>>
>>
>>> Note: I inlined the apmd(8)->apm(8) perfpolicy conversion for now, which
>>> brings a question.  I find it weird that there is a special "high"
>>> perfpolicy (effectively similar to perfpolicy=manual + setperf=100) but
>>> no "low" perfpolicy.  Is "high" useful to anyone?
>>
>> If you're benchmarking or something, it's convenient to toggle between
>> high and auto. There's less use for low, since that's what auto defaults to.
>
> Well you can do auto->high easily with apm(8) -H or sysctl
> hw.perfpolicy=manual hw.setperf=100.  I'm not sure a special "high"
> hw.perfpolicy choice brings much value and I would appreciate a simple
> "manual" vs "auto" situation.
>
> This has an impact on documentation.  sysctl(2) doesn't mention that
> setting hw.perfpolicy=high also locks hw.setperf=100.  The apm(8)
> manpage only talks about -H setting hw.setperf=100.  The description for
> apmd(8) -H says
>
>   Start apmd in *manual* performance adjustment mode,
>   initialising hw.setperf to 100.
>
> which is not the whole story.  If you use apm/apmd -H you can't later
> just run sysctl hw.setperf=50:
>
>   sysctl: hw.setperf: Operation not permitted

The diff below teaches apmd(8) -H to set hw.perfpolicy="manual" and
hw.setperf=100, instead of setting hw.perfpolicy="high".
- matches the manpage
- apm(8) reporting becomes accurate
- more symmetry with -L ("low")
- avoids the "sysctl: hw.setperf: Operation not permitted" quirk

Teaching apm(8) how to print hw.perfpolicy="high" then becomes low
priority.

While here, simplify the sysctl(2) calls: in this function we don't care
about the old values.

ok?


Index: apmd.c
===
--- apmd.c.orig
+++ apmd.c
@@ -650,27 +650,27 @@ void
 setperfpolicy(char *policy)
 {
int hw_perfpol_mib[] = { CTL_HW, HW_PERFPOLICY };
-   char oldpolicy[32];
-   size_t oldsz = sizeof(oldpolicy);
-   int setlo = 0;
+   int hw_perf_mib[] = { CTL_HW, HW_SETPERF };
+   int new_perf = -1;
 
if (strcmp(policy, "low") == 0) {
policy = "manual";
-   setlo = 1;
+   new_perf = 0;
+   } else if (strcmp(policy, "high") == 0) {
+   policy = "manual";
+   new_perf = 100;
}
 
-   if (sysctl(hw_perfpol_mib, 2, oldpolicy, ,
+   if (sysctl(hw_perfpol_mib, 2, NULL, NULL,
policy, strlen(policy) + 1) == -1)
logmsg(LOG_INFO, "cannot set hw.perfpolicy");
 
-   if (setlo == 1) {
-   int hw_perf_mib[] = {CTL_HW, HW_SETPERF};
-   int perf;
-   int new_perf = 0;
-   size_t perf_sz = sizeof(perf);
-   if (sysctl(hw_perf_mib, 2, , _sz, _perf, perf_sz) 
== -1)
-   logmsg(LOG_INFO, "cannot set hw.setperf");
-   }
+   if (new_perf == -1)
+   return;
+
+   if (sysctl(hw_perf_mib, 2, NULL, NULL,
+   _perf, sizeof(new_perf)) == -1)
+   logmsg(LOG_INFO, "cannot set hw.setperf");
 }
 
 void


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: apmd(8) and hw.perfpolicy quirks

2020-09-24 Thread Jeremie Courreges-Anglas
On Wed, Sep 23 2020, "Ted Unangst"  wrote:
> On 2020-09-23, Jeremie Courreges-Anglas wrote:
>
>> ok?
>
> Seems fine.
>
>
>> Note: I inlined the apmd(8)->apm(8) perfpolicy conversion for now, which
>> brings a question.  I find it weird that there is a special "high"
>> perfpolicy (effectively similar to perfpolicy=manual + setperf=100) but
>> no "low" perfpolicy.  Is "high" useful to anyone?
>
> If you're benchmarking or something, it's convenient to toggle between
> high and auto. There's less use for low, since that's what auto defaults to.

Well you can do auto->high easily with apm(8) -H or sysctl
hw.perfpolicy=manual hw.setperf=100.  I'm not sure a special "high"
hw.perfpolicy choice brings much value and I would appreciate a simple
"manual" vs "auto" situation.

This has an impact on documentation.  sysctl(2) doesn't mention that
setting hw.perfpolicy=high also locks hw.setperf=100.  The apm(8)
manpage only talks about -H setting hw.setperf=100.  The description for
apmd(8) -H says

  Start apmd in *manual* performance adjustment mode,
  initialising hw.setperf to 100.

which is not the whole story.  If you use apm/apmd -H you can't later
just run sysctl hw.setperf=50:

  sysctl: hw.setperf: Operation not permitted

Initially I had a diff to teach apm(8) about hw.perfpolicy="high" but
I'm not sure it's the right direction any more.  Diff below fwiw, not
looking for oks.


Index: apm/apm.c
===
RCS file: /d/cvs/src/usr.sbin/apm/apm.c,v
retrieving revision 1.37
diff -u -p -r1.37 apm.c
--- apm/apm.c   23 Sep 2020 05:50:26 -  1.37
+++ apm/apm.c   24 Sep 2020 20:29:49 -
@@ -399,7 +399,8 @@ balony:
 
if (doperf)
printf("Performance adjustment mode: %s (%d MHz)\n",
-   perf_mode(reply.perfmode), reply.cpuspeed);
+   perfmode_to_perfpolicy(reply.perfmode),
+   reply.cpuspeed);
break;
default:
break;
Index: apmd/apm-proto.h
===
RCS file: /d/cvs/src/usr.sbin/apmd/apm-proto.h,v
retrieving revision 1.10
diff -u -p -r1.10 apm-proto.h
--- apmd/apm-proto.h23 Sep 2020 05:50:26 -  1.10
+++ apmd/apm-proto.h24 Sep 2020 20:29:49 -
@@ -51,6 +51,7 @@ enum apm_perfmode {
PERF_NONE = -1,
PERF_MANUAL,
PERF_AUTO,
+   PERF_HIGH,
 };
 
 struct apm_command {
@@ -66,8 +67,9 @@ struct apm_reply {
struct apm_power_info batterystate;
 };
 
-#define APMD_VNO   3
+#define APMD_VNO   4
 
 extern const char *battstate(int state);
 extern const char *ac_state(int state);
-extern const char *perf_mode(int mode);
+extern const char *perfmode_to_perfpolicy(int mode);
+extern enum apm_perfmode perfpolicy_to_perfmode(const char *);
Index: apmd/apmd.c
===
RCS file: /d/cvs/src/usr.sbin/apmd/apmd.c,v
retrieving revision 1.98
diff -u -p -r1.98 apmd.c
--- apmd/apmd.c 24 Sep 2020 07:23:41 -  1.98
+++ apmd/apmd.c 24 Sep 2020 20:29:49 -
@@ -310,16 +310,11 @@ handle_client(int sock_fd, int ctl_fd)
break;
}
 
-   reply.perfmode = PERF_NONE;
-   if (sysctl(perfpol_mib, 2, perfpol, _sz, NULL, 0) == -1)
+   if (sysctl(perfpol_mib, 2, perfpol, _sz, NULL, 0) == -1) {
logmsg(LOG_INFO, "cannot read hw.perfpolicy");
-   else {
-   if (strcmp(perfpol, "manual") == 0 ||
-   strcmp(perfpol, "high") == 0) {
-   reply.perfmode = PERF_MANUAL;
-   } else if (strcmp(perfpol, "auto") == 0)
-   reply.perfmode = PERF_AUTO;
-   }
+   reply.perfmode = PERF_NONE;
+   } else
+   reply.perfmode = perfpolicy_to_perfmode(perfpol);
 
if (sysctl(cpuspeed_mib, 2, , _sz, NULL, 0) == -1) {
logmsg(LOG_INFO, "cannot read hw.cpuspeed");
Index: apmd/apmsubr.c
===
RCS file: /d/cvs/src/usr.sbin/apmd/apmsubr.c,v
retrieving revision 1.9
diff -u -p -r1.9 apmsubr.c
--- apmd/apmsubr.c  23 Sep 2020 05:50:26 -  1.9
+++ apmd/apmsubr.c  24 Sep 2020 20:29:49 -
@@ -31,6 +31,8 @@
 
 #include 
 #include 
+#include 
+
 #include "apm-proto.h"
 
 const char *
@@ -72,14 +74,29 @@ ac_state(int state)
 }
 
 const char *
-perf_mode(int mode)
+perfmode_to_perfpolicy(int mode)
 {
switch (mode) {
-   case PERF_MANUAL:
-   return "manual";
case PERF_AUTO:
return "auto";
+   case PERF_HIGH:
+   return "high&qu

Re: apmd(8) and hw.perfpolicy quirks

2020-09-23 Thread Jeremie Courreges-Anglas
On Wed, Sep 23 2020, Jeremie Courreges-Anglas  wrote:
> Prompted by a report from Miod: setting hw.setperf works only if the
> kernel doesn't have a usable cpu_setperf implementation.  The current
> apmd(8) code warns if setting hw.perfpolicy fails, but then handles
> back bogus values to apm(8) clients.

Some corrections:

> The easy fix is to just query the kernel about the actual hw.setperf
hw.perfpolicy

> value.  This fixes other incorrect apmd(8) assumptions:
> - hw.setperf is initially set to "manual"
hw.perfpolicy

> - hw.setperf can't change behind apmd's back
hw.perfpolicy

> ok?
>
>
> Note: I inlined the apmd(8)->apm(8) perfpolicy conversion for now, which
> brings a question.  I find it weird that there is a special "high"
> perfpolicy (effectively similar to perfpolicy=manual + setperf=100) but
> no "low" perfpolicy.  Is "high" useful to anyone?
>
> Index: apmd.c
> ===
> RCS file: /d/cvs/src/usr.sbin/apmd/apmd.c,v
> retrieving revision 1.97
> diff -u -p -r1.97 apmd.c
> --- apmd.c23 Sep 2020 05:50:26 -  1.97
> +++ apmd.c23 Sep 2020 10:46:37 -
> @@ -59,8 +59,6 @@
>  
>  int debug = 0;
>  
> -int doperf = PERF_NONE;
> -
>  extern char *__progname;
>  
>  void usage(void);
> @@ -255,7 +253,10 @@ handle_client(int sock_fd, int ctl_fd)
>   socklen_t fromlen;
>   struct apm_command cmd;
>   struct apm_reply reply;
> - int cpuspeed_mib[] = {CTL_HW, HW_CPUSPEED};
> + int perfpol_mib[] = { CTL_HW, HW_PERFPOLICY };
> + char perfpol[32];
> + size_t perfpol_sz = sizeof(perfpol);
> + int cpuspeed_mib[] = { CTL_HW, HW_CPUSPEED };
>   int cpuspeed = 0;
>   size_t cpuspeed_sz = sizeof(cpuspeed);
>  
> @@ -290,19 +291,16 @@ handle_client(int sock_fd, int ctl_fd)
>   reply.newstate = HIBERNATING;
>   break;
>   case SETPERF_LOW:
> - doperf = PERF_MANUAL;
>   reply.newstate = NORMAL;
>   logmsg(LOG_NOTICE, "setting hw.perfpolicy to low");
>   setperfpolicy("low");
>   break;
>   case SETPERF_HIGH:
> - doperf = PERF_MANUAL;
>   reply.newstate = NORMAL;
>   logmsg(LOG_NOTICE, "setting hw.perfpolicy to high");
>   setperfpolicy("high");
>   break;
>   case SETPERF_AUTO:
> - doperf = PERF_AUTO;
>   reply.newstate = NORMAL;
>   logmsg(LOG_NOTICE, "setting hw.perfpolicy to auto");
>   setperfpolicy("auto");
> @@ -312,11 +310,22 @@ handle_client(int sock_fd, int ctl_fd)
>   break;
>   }
>  
> - if (sysctl(cpuspeed_mib, 2, , _sz, NULL, 0) == -1)
> - logmsg(LOG_INFO, "cannot read hw.cpuspeed");
> + reply.perfmode = PERF_NONE;
> + if (sysctl(perfpol_mib, 2, perfpol, _sz, NULL, 0) == -1)
> + logmsg(LOG_INFO, "cannot read hw.perfpolicy");
> + else {
> + if (strcmp(perfpol, "manual") == 0 ||
> + strcmp(perfpol, "high") == 0) {
> + reply.perfmode = PERF_MANUAL;
> + } else if (strcmp(perfpol, "auto") == 0)
> + reply.perfmode = PERF_AUTO;
> + }
>  
> + if (sysctl(cpuspeed_mib, 2, , _sz, NULL, 0) == -1) {
> + logmsg(LOG_INFO, "cannot read hw.cpuspeed");
> + cpuspeed = 0;
> + }
>   reply.cpuspeed = cpuspeed;
> - reply.perfmode = doperf;
>   reply.vno = APMD_VNO;
>   if (send(cli_fd, , sizeof(reply), 0) != sizeof(reply))
>   logmsg(LOG_INFO, "reply to client botched");
> @@ -386,6 +395,7 @@ main(int argc, char *argv[])
>   const char *errstr;
>   int kq, nchanges;
>   struct kevent ev[2];
> + int doperf = PERF_NONE;
>  
>   while ((ch = getopt(argc, argv, "aACdHLsf:t:S:z:Z:")) != -1)
>   switch(ch) {

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



apmd(8) and hw.perfpolicy quirks

2020-09-23 Thread Jeremie Courreges-Anglas


Prompted by a report from Miod: setting hw.setperf works only if the
kernel doesn't have a usable cpu_setperf implementation.  The current
apmd(8) code warns if setting hw.perfpolicy fails, but then handles
back bogus values to apm(8) clients.

The easy fix is to just query the kernel about the actual hw.setperf
value.  This fixes other incorrect apmd(8) assumptions:
- hw.setperf is initially set to "manual"
- hw.setperf can't change behind apmd's back

ok?


Note: I inlined the apmd(8)->apm(8) perfpolicy conversion for now, which
brings a question.  I find it weird that there is a special "high"
perfpolicy (effectively similar to perfpolicy=manual + setperf=100) but
no "low" perfpolicy.  Is "high" useful to anyone?


Index: apmd.c
===
RCS file: /d/cvs/src/usr.sbin/apmd/apmd.c,v
retrieving revision 1.97
diff -u -p -r1.97 apmd.c
--- apmd.c  23 Sep 2020 05:50:26 -  1.97
+++ apmd.c  23 Sep 2020 10:46:37 -
@@ -59,8 +59,6 @@
 
 int debug = 0;
 
-int doperf = PERF_NONE;
-
 extern char *__progname;
 
 void usage(void);
@@ -255,7 +253,10 @@ handle_client(int sock_fd, int ctl_fd)
socklen_t fromlen;
struct apm_command cmd;
struct apm_reply reply;
-   int cpuspeed_mib[] = {CTL_HW, HW_CPUSPEED};
+   int perfpol_mib[] = { CTL_HW, HW_PERFPOLICY };
+   char perfpol[32];
+   size_t perfpol_sz = sizeof(perfpol);
+   int cpuspeed_mib[] = { CTL_HW, HW_CPUSPEED };
int cpuspeed = 0;
size_t cpuspeed_sz = sizeof(cpuspeed);
 
@@ -290,19 +291,16 @@ handle_client(int sock_fd, int ctl_fd)
reply.newstate = HIBERNATING;
break;
case SETPERF_LOW:
-   doperf = PERF_MANUAL;
reply.newstate = NORMAL;
logmsg(LOG_NOTICE, "setting hw.perfpolicy to low");
setperfpolicy("low");
break;
case SETPERF_HIGH:
-   doperf = PERF_MANUAL;
reply.newstate = NORMAL;
logmsg(LOG_NOTICE, "setting hw.perfpolicy to high");
setperfpolicy("high");
break;
case SETPERF_AUTO:
-   doperf = PERF_AUTO;
reply.newstate = NORMAL;
logmsg(LOG_NOTICE, "setting hw.perfpolicy to auto");
setperfpolicy("auto");
@@ -312,11 +310,22 @@ handle_client(int sock_fd, int ctl_fd)
break;
}
 
-   if (sysctl(cpuspeed_mib, 2, , _sz, NULL, 0) == -1)
-   logmsg(LOG_INFO, "cannot read hw.cpuspeed");
+   reply.perfmode = PERF_NONE;
+   if (sysctl(perfpol_mib, 2, perfpol, _sz, NULL, 0) == -1)
+   logmsg(LOG_INFO, "cannot read hw.perfpolicy");
+   else {
+   if (strcmp(perfpol, "manual") == 0 ||
+   strcmp(perfpol, "high") == 0) {
+   reply.perfmode = PERF_MANUAL;
+   } else if (strcmp(perfpol, "auto") == 0)
+   reply.perfmode = PERF_AUTO;
+   }
 
+   if (sysctl(cpuspeed_mib, 2, , _sz, NULL, 0) == -1) {
+   logmsg(LOG_INFO, "cannot read hw.cpuspeed");
+   cpuspeed = 0;
+   }
reply.cpuspeed = cpuspeed;
-   reply.perfmode = doperf;
reply.vno = APMD_VNO;
if (send(cli_fd, , sizeof(reply), 0) != sizeof(reply))
logmsg(LOG_INFO, "reply to client botched");
@@ -386,6 +395,7 @@ main(int argc, char *argv[])
const char *errstr;
int kq, nchanges;
struct kevent ev[2];
+   int doperf = PERF_NONE;
 
while ((ch = getopt(argc, argv, "aACdHLsf:t:S:z:Z:")) != -1)
switch(ch) {

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: httpd(8): don't leak iov

2020-09-20 Thread Jeremie Courreges-Anglas
On Sun, Sep 20 2020, Tobias Heider  wrote:
> iov is allocated with calloc.  I think we should free it after the imsg
> is sent.
>
> ok?

ok jca@

> Index: config.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/config.c,v
> retrieving revision 1.57
> diff -u -p -r1.57 config.c
> --- config.c  8 May 2019 19:57:45 -   1.57
> +++ config.c  20 Sep 2020 13:34:07 -
> @@ -387,8 +387,10 @@ config_setserver_fcgiparams(struct httpd
>   if (proc_composev(ps, PROC_SERVER, IMSG_CFG_FCGI, iov, c) != 0) {
>   log_warn("%s: failed to compose IMSG_CFG_FCGI imsg for "
>   "`%s'", __func__, srv_conf->name);
> + free(iov);
>   return (-1);
>   }
> + free(iov);
>  
>   return (0);
>  }
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



apm(8) and apmd(8): zap "cool" running mode remnants

2020-09-20 Thread Jeremie Courreges-Anglas


apmd "cool" mode was removed in 2014, and -C was made an undocumented
compat alias for -A ("auto").

The code still contains kinda misleading references to this "cool"
running mode, the diff below zaps those.  ok?


Index: apm/apm.c
===
RCS file: /d/cvs/src/usr.sbin/apm/apm.c,v
retrieving revision 1.36
diff -u -p -r1.36 apm.c
--- apm/apm.c   28 Jun 2019 13:32:46 -  1.36
+++ apm/apm.c   20 Sep 2020 12:24:43 -
@@ -185,14 +185,10 @@ main(int argc, char *argv[])
action = HIBERNATE;
break;
case 'A':
-   if (action != NONE)
-   usage();
-   action = SETPERF_AUTO;
-   break;
case 'C':
if (action != NONE)
usage();
-   action = SETPERF_COOL;
+   action = SETPERF_AUTO;
break;
case 'H':
if (action != NONE)
@@ -277,7 +273,6 @@ main(int argc, char *argv[])
case SETPERF_LOW:
case SETPERF_HIGH:
case SETPERF_AUTO:
-   case SETPERF_COOL:
if (fd == -1)
errx(1, "cannot connect to apmd, "
"not changing performance adjustment mode");
Index: apmd/apm-proto.h
===
RCS file: /d/cvs/src/usr.sbin/apmd/apm-proto.h,v
retrieving revision 1.9
diff -u -p -r1.9 apm-proto.h
--- apmd/apm-proto.h26 Mar 2012 20:17:45 -  1.9
+++ apmd/apm-proto.h20 Sep 2020 12:28:01 -
@@ -38,7 +38,6 @@ enum apm_action {
SETPERF_LOW,
SETPERF_HIGH,
SETPERF_AUTO,
-   SETPERF_COOL
 };
 
 enum apm_state {
@@ -52,7 +51,6 @@ enum apm_perfmode {
PERF_NONE = -1,
PERF_MANUAL,
PERF_AUTO,
-   PERF_COOL
 };
 
 struct apm_command {
Index: apmd/apmd.c
===
RCS file: /d/cvs/src/usr.sbin/apmd/apmd.c,v
retrieving revision 1.96
diff -u -p -r1.96 apmd.c
--- apmd/apmd.c 13 Mar 2020 09:08:58 -  1.96
+++ apmd/apmd.c 20 Sep 2020 12:25:53 -
@@ -302,7 +302,6 @@ handle_client(int sock_fd, int ctl_fd)
setperfpolicy("high");
break;
case SETPERF_AUTO:
-   case SETPERF_COOL:
doperf = PERF_AUTO;
reply.newstate = NORMAL;
logmsg(LOG_NOTICE, "setting hw.perfpolicy to auto");
Index: apmd/apmsubr.c
===
RCS file: /d/cvs/src/usr.sbin/apmd/apmsubr.c,v
retrieving revision 1.8
diff -u -p -r1.8 apmsubr.c
--- apmd/apmsubr.c  15 Mar 2006 20:30:28 -  1.8
+++ apmd/apmsubr.c  20 Sep 2020 12:28:49 -
@@ -79,8 +79,6 @@ perf_mode(int mode)
return "manual";
case PERF_AUTO:
return "auto";
-   case PERF_COOL:
-   return "cool running";
default:
return "invalid";
}




-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: ftp: allow specifying supported protocols

2020-09-06 Thread Jeremie Courreges-Anglas
On Sun, Sep 06 2020, Theo Buehler  wrote:
> On Sun, Sep 06, 2020 at 12:55:17AM +0200, Jeremie Courreges-Anglas wrote:
>> On Sat, Sep 05 2020, Theo Buehler  wrote:
>> > I found this small diff useful more than once (admittedly for debugging).
>> > It allows specifying the protocols that may be used by ftp the same way
>> > as nc -Tprotocols works. For example:
>> >
>> > $ ftp -Sprotocols=tlsv1.2:tlsv1.1 https://example.com/file
>> >
>> > Perhaps someone else has use for it, too?
>> 
>> I think it's useful indeed.  ok jca@
>> 
>> One nit below,
>> 
>> > Index: ftp.1
>> > ===
>> > RCS file: /var/cvs/src/usr.bin/ftp/ftp.1,v
>> > retrieving revision 1.119
>> > diff -u -p -r1.119 ftp.1
>> > --- ftp.1  11 Feb 2020 18:41:39 -  1.119
>> > +++ ftp.1  5 Sep 2020 18:11:24 -
>> > @@ -261,6 +261,12 @@ Don't perform server certificate validat
>> >  Require the server to present a valid OCSP stapling in the TLS handshake.
>> >  .It Cm noverifytime
>> >  Disable validation of certificate times and OCSP validation.
>> > +.It Cm protocols Ns = Ns Ar protocol_list
>> > +Specify the supported TLS protocols that will be used by
>> > +.Nm
>> > +(see
>> > +.Xr tls_config_parse_protocols 3
>> > +for details).
>> >  .It Cm session Ns = Ns Ar /path/to/session
>> >  Specify a file to use for TLS session data.
>> >  If this file has a non-zero length, the session data will be read from 
>> > this file
>> > Index: main.c
>> > ===
>> > RCS file: /var/cvs/src/usr.bin/ftp/main.c,v
>> > retrieving revision 1.132
>> > diff -u -p -r1.132 main.c
>> > --- main.c 1 Sep 2020 12:33:48 -   1.132
>> > +++ main.c 1 Sep 2020 18:13:09 -
>> > @@ -209,6 +209,8 @@ char * const ssl_verify_opts[] = {
>> >"noverifytime",
>> >  #define SSL_SESSION   8
>> >"session",
>> > +#define SSL_PROTOCOLS 9
>> > +  "protocols",
>> >NULL
>> >  };
>> >  
>> > @@ -220,6 +222,7 @@ process_ssl_options(char *cp)
>> >  {
>> >const char *errstr;
>> >long long depth;
>> 
>> (Should probably be an int.)
>>
>> > +  uint32_t protocols;
>> 
>> Could be moved below str (smaller size on lp64, see style(9)).
>> 
>> >char *str;
>
> If we care about this, shouldn't I rather move *str up below *errstr?

Yes.  The diff below shows the overall changes I had in mind.  Please
pick it up if you like it, or just use your version.

Sorry for the bikeshed color concern, I should have brought this up
later in private (if at all).


Index: main.c
===
RCS file: /d/cvs/src/usr.bin/ftp/main.c,v
retrieving revision 1.132
diff -u -p -p -u -r1.132 main.c
--- main.c  1 Sep 2020 12:33:48 -   1.132
+++ main.c  6 Sep 2020 08:26:25 -
@@ -209,6 +209,8 @@ char * const ssl_verify_opts[] = {
"noverifytime",
 #define SSL_SESSION8
"session",
+#define SSL_PROTOCOLS  9
+   "protocols",
NULL
 };
 
@@ -219,8 +221,9 @@ static void
 process_ssl_options(char *cp)
 {
const char *errstr;
-   long long depth;
char *str;
+   int depth;
+   uint32_t protocols;
 
while (*cp) {
switch (getsubopt(, ssl_verify_opts, )) {
@@ -259,7 +262,7 @@ process_ssl_options(char *cp)
if (errstr)
errx(1, "certificate validation depth is %s",
errstr);
-   tls_config_set_verify_depth(tls_config, (int)depth);
+   tls_config_set_verify_depth(tls_config, depth);
break;
case SSL_MUSTSTAPLE:
tls_config_ocsp_require_stapling(tls_config);
@@ -278,6 +281,14 @@ process_ssl_options(char *cp)
tls_session_fd) == -1)
errx(1, "failed to set session: %s",
tls_config_error(tls_config));
+   break;
+   case SSL_PROTOCOLS:
+   if (str == NULL)
+   errx(1, "missing protocol name");
+   if (tls_config_parse_protocols(, str) != 0)
+   errx(1, "failed to parse TLS protocols");
+   if (tls_config_set_protocols(tls_config, protocols) != 
0)
+   errx(1, "failed to set TLS protocols");
break;
default:
errx(1, "unknown -S suboption `%s'",

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: ftp: allow specifying supported protocols

2020-09-05 Thread Jeremie Courreges-Anglas
On Sat, Sep 05 2020, Theo Buehler  wrote:
> I found this small diff useful more than once (admittedly for debugging).
> It allows specifying the protocols that may be used by ftp the same way
> as nc -Tprotocols works. For example:
>
> $ ftp -Sprotocols=tlsv1.2:tlsv1.1 https://example.com/file
>
> Perhaps someone else has use for it, too?

I think it's useful indeed.  ok jca@

One nit below,

> Index: ftp.1
> ===
> RCS file: /var/cvs/src/usr.bin/ftp/ftp.1,v
> retrieving revision 1.119
> diff -u -p -r1.119 ftp.1
> --- ftp.1 11 Feb 2020 18:41:39 -  1.119
> +++ ftp.1 5 Sep 2020 18:11:24 -
> @@ -261,6 +261,12 @@ Don't perform server certificate validat
>  Require the server to present a valid OCSP stapling in the TLS handshake.
>  .It Cm noverifytime
>  Disable validation of certificate times and OCSP validation.
> +.It Cm protocols Ns = Ns Ar protocol_list
> +Specify the supported TLS protocols that will be used by
> +.Nm
> +(see
> +.Xr tls_config_parse_protocols 3
> +for details).
>  .It Cm session Ns = Ns Ar /path/to/session
>  Specify a file to use for TLS session data.
>  If this file has a non-zero length, the session data will be read from this 
> file
> Index: main.c
> ===
> RCS file: /var/cvs/src/usr.bin/ftp/main.c,v
> retrieving revision 1.132
> diff -u -p -r1.132 main.c
> --- main.c1 Sep 2020 12:33:48 -   1.132
> +++ main.c1 Sep 2020 18:13:09 -
> @@ -209,6 +209,8 @@ char * const ssl_verify_opts[] = {
>   "noverifytime",
>  #define SSL_SESSION  8
>   "session",
> +#define SSL_PROTOCOLS9
> + "protocols",
>   NULL
>  };
>  
> @@ -220,6 +222,7 @@ process_ssl_options(char *cp)
>  {
>   const char *errstr;
>   long long depth;

(Should probably be an int.)

> + uint32_t protocols;

Could be moved below str (smaller size on lp64, see style(9)).

>   char *str;
>  
>   while (*cp) {
> @@ -278,6 +281,14 @@ process_ssl_options(char *cp)
>   tls_session_fd) == -1)
>   errx(1, "failed to set session: %s",
>   tls_config_error(tls_config));
> + break;
> + case SSL_PROTOCOLS:
> + if (str == NULL)
> + errx(1, "missing protocol name");
> + if (tls_config_parse_protocols(, str) != 0)
> + errx(1, "failed to parse TLS protocols");
> + if (tls_config_set_protocols(tls_config, protocols) != 
> 0)
> + errx(1, "failed to set TLS protocols");
>   break;
>   default:
>   errx(1, "unknown -S suboption `%s'",
>


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



unwind(8): use SO_REUSEADDR

2020-08-29 Thread Jeremie Courreges-Anglas
On Sat, Aug 29 2020, Stuart Henderson  wrote:
> On 2020/08/27 15:28, Florian Obser wrote:
>> all heavy lifting done by sthen in unbound
>> 
>> tests?
>
> ok with me. only tested lightly (the machine I normally use does DNS for
> other machines too so runs unbound).
>
> related, any idea what's happening here?
>
> unwind[51500]: fatal in main: could not bind to 127.0.0.1 or ::1 on port 53: 
> Address already in use
>
> unbound is listening to *:53, but shouldn't other software be able to
> listen if bound to a specific address like 127.0.0.1:53? is this a bug
> somewhere or am I just missing something about UDP?

Once *:53 is bound you need SO_REUSEADDR to loosen the checks.  ktrace
says unbound(8) uses this unconditionally.  ChangeLog entry:

- Fix #531: Set SO_REUSEADDR so that the wildcard interface and a 
  more specific interface port 53 can be used at the same time, and
  one of the daemons is unbound.

I think unwind could use the same treatment.

Note that using SO_REUSEADDR still prevents two unwind copies from
binding to 127.0.0.1:53 / [::1]:53 (for that to work you'd need
SO_REUSEPORT instead).

Thoughts?  oks?


Index: unwind.c
===
RCS file: /d/cvs/src/sbin/unwind/unwind.c,v
retrieving revision 1.47
diff -u -p -p -u -r1.47 unwind.c
--- unwind.c25 May 2020 16:52:15 -  1.47
+++ unwind.c29 Aug 2020 17:07:49 -
@@ -726,6 +726,7 @@ open_ports(void)
 {
struct addrinfo  hints, *res0;
int  udp4sock = -1, udp6sock = -1, error;
+   int  opt = 1;
 
memset(, 0, sizeof(hints));
hints.ai_family = AF_INET;
@@ -736,6 +737,9 @@ open_ports(void)
if (!error && res0) {
if ((udp4sock = socket(res0->ai_family, res0->ai_socktype,
res0->ai_protocol)) != -1) {
+   if (setsockopt(udp4sock, SOL_SOCKET, SO_REUSEADDR,
+   , sizeof(opt)) == -1)
+   log_warn("setting SO_REUSEADDR on socket");
if (bind(udp4sock, res0->ai_addr, res0->ai_addrlen)
== -1) {
close(udp4sock);
@@ -751,6 +755,9 @@ open_ports(void)
if (!error && res0) {
if ((udp6sock = socket(res0->ai_family, res0->ai_socktype,
res0->ai_protocol)) != -1) {
+   if (setsockopt(udp6sock, SOL_SOCKET, SO_REUSEADDR,
+   , sizeof(opt)) == -1)
+   log_warn("setting SO_REUSEADDR on socket");
if (bind(udp6sock, res0->ai_addr, res0->ai_addrlen)
== -1) {
close(udp6sock);


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: [Patch] Change httpd's handling of request "Host:" headers

2020-08-10 Thread Jeremie Courreges-Anglas
On Mon, Aug 10 2020, Ross L Richardson  wrote:
> Leo,
>
> On Mon, Aug 10, 2020 at 08:46:19AM +0200, Leo Unglaub wrote:
>> Hey,
>> i love your patch. The current behavour always bothered me because it caused
>> servers to display "wrong" sites as defaults for all requests missing the
>> Host header. I really like your patch and it works fine for me on my
>> servers.
>>[...]
>
> Thanks for testing.
>
> I forgot to mention that, by requiring an exact match, the patch should
> fix the port problem [see below] too.
>
> The problem:
>   $ printf "HEAD / HTTP/1.0\r\nHost: www.openbsd.org:22\r\n\r\n" \
>   | nc www.openbsd.org 80 | sed 1q
>   HTTP/1.0 200 OK

If you consider that a problem.  For example apache ignores any
client-provided port number.

  https://httpd.apache.org/docs/2.4/vhosts/details.html#namebased

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: [Patch] Change httpd's handling of request "Host:" headers

2020-08-10 Thread Jeremie Courreges-Anglas
On Sun, Aug 09 2020, Ross L Richardson  wrote:
> At present, if a request contains no "Host:" header [HTTP pre-1.1] or
> if the supplied header does not match any of the servers configured
> in httpd.conf, the request is directed to the first server.  This
> isn't documented, AFAICT.
>
> For example, if httpd.conf has just one server
>   server "www.example.com"
> then we currently get
>   $ printf "HEAD / HTTP/1.0\r\nHost: www.openbsd.org\r\n\r\n" \
>   | nc www.example.com www | sed 1q 
>   HTTP/1.0 200 OK
>
> This behaviour strikes me as wrong (or at least sub-optimal) in the
> case of non-matching "Host:" headers.  The simplistic patch below
> changes things to return a 404 status if no matching server is found.
>
> [If status code 400 (bad request) is preferred, "goto fail;"
> could be used.]
>
> Justification:
> - This seems more correct, and is consistent with the "fail closed"
>   approach.
> - There is a net gain in functionality, as use of glob/patterns
>   wildcards can easily re-establish the current behaviour.  In
>   contrast, there's no way at present to disable the implicit
>   match-anything behaviour.

The first server in my httpd config uses "root "/nonexistent".  This
results in proper 404 replies, so there is a way to disable the current
behavior.  I probably inferred this from the examples in the manpage.

My gut feeling is that the existing behavior is useful (you can
copy/paste the existing example in the manpage and serve files right
away under multiple host names) and I see no reason to break it.
Did you check whether this breaks existing mirrors?

> If this is adopted, it should be document in current.html
> A followup patch could merge this if statement with the one above it.
>
> Several other issues exist in "Host:" header handling.
>
> Ross
> --
>
> Index: server_http.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
> retrieving revision 1.140
> diff -u -p -r1.140 server_http.c
> --- server_http.c 3 Aug 2020 10:59:53 -   1.140
> +++ server_http.c 9 Aug 2020 04:37:08 -
> @@ -1200,7 +1200,7 @@ server_response(struct httpd *httpd, str
>   struct server_config*srv_conf = >srv_conf;
>   struct kv   *kv, key, *host;
>   struct str_find  sm;
> - int  portval = -1, ret;
> + int  hostmatch = 0, portval = -1, ret;
>   char*hostval, *query;
>   const char  *errstr = NULL;
>  
> @@ -1277,16 +1277,20 @@ server_response(struct httpd *httpd, str
>   /* Replace host configuration */
>   clt->clt_srv_conf = srv_conf;
>   srv_conf = NULL;
> + hostmatch = 1;
>   break;
>   }
>   }
>   }
>  
> - if (srv_conf != NULL) {
> + if (host == NULL) {
>   /* Use the actual server IP address */
>   if (server_http_host(>clt_srv_ss, hostname,
>   sizeof(hostname)) == NULL)
>   goto fail;
> + } else if (!hostmatch) {
> + server_abort_http(clt, 404, "not found");
> + return (-1);
>   } else {
>   /* Host header was valid and found */
>   if (strlcpy(hostname, host->kv_value, sizeof(hostname)) >=
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: allow TCP connections to IPv6 anycast addresses

2020-08-08 Thread Jeremie Courreges-Anglas
On Sat, Aug 08 2020, Florian Obser  wrote:
> On Fri, Aug 07, 2020 at 11:52:46PM +0200, Jeremie Courreges-Anglas wrote:
>> If you don't want to remove M_ACAST from sys/mbuf.h, can you please at
>> least change the comment?  /* obsolete */ or something.
>
> Good point, I forgot to ask about what to do with the flag.
> I think we can remove it, from what I understand %b in printf(9) works
> fine with a sparse decoding string.

Should be fine indeed.

> It compiles but I have no idea how to test it in ddb.

show mbuf addr in a function that uses an mbuf?

> OK? Better to leave out the comment?

I think the comment can be dropped along with the #define.  Userland
shouldn't be poking at this.

ok jca@

> diff --git sys/mbuf.h sys/mbuf.h
> index d52896d3be8..3ddd1b89d66 100644
> --- sys/mbuf.h
> +++ sys/mbuf.h
> @@ -190,7 +190,7 @@ struct mbuf {
>  /* mbuf pkthdr flags, also in m_flags */
>  #define M_VLANTAG0x0020  /* ether_vtag is valid */
>  #define M_LOOP   0x0040  /* packet has been sent from local 
> machine */
> -#define M_ACAST  0x0080  /* received as IPv6 anycast */
> + /* 0x0080 used to be M_ACAST */
>  #define M_BCAST  0x0100  /* sent/received as link-level 
> broadcast */
>  #define M_MCAST  0x0200  /* sent/received as link-level 
> multicast */
>  #define M_CONF   0x0400  /* payload was encrypted 
> (ESP-transport) */
> @@ -203,14 +203,13 @@ struct mbuf {
>  #ifdef _KERNEL
>  #define M_BITS \
>  ("\20\1M_EXT\2M_PKTHDR\3M_EOR\4M_EXTWR\5M_PROTO1\6M_VLANTAG\7M_LOOP" \
> -"\10M_ACAST\11M_BCAST\12M_MCAST\13M_CONF\14M_AUTH\15M_TUNNEL" \
> +"\11M_BCAST\12M_MCAST\13M_CONF\14M_AUTH\15M_TUNNEL" \
>  "\16M_ZEROIZE\17M_COMP\20M_LINK0")
>  #endif
>  
>  /* flags copied when copying m_pkthdr */
>  #define  M_COPYFLAGS 
> (M_PKTHDR|M_EOR|M_PROTO1|M_BCAST|M_MCAST|M_CONF|M_COMP|\
> -  M_AUTH|M_LOOP|M_TUNNEL|M_LINK0|M_VLANTAG|M_ACAST|\
> -  M_ZEROIZE)
> +  M_AUTH|M_LOOP|M_TUNNEL|M_LINK0|M_VLANTAG|M_ZEROIZE)
>  
>  /* Checksumming flags */
>  #define  M_IPV4_CSUM_OUT 0x0001  /* IPv4 checksum needed */

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: allow TCP connections to IPv6 anycast addresses

2020-08-07 Thread Jeremie Courreges-Anglas
On Fri, Aug 07 2020, Florian Obser  wrote:
> No longer prevent TCP connections to IPv6 anycast addresses.
>
> RFC 4291 dropped this requirement from RFC 3513:
>o  An anycast address must not be used as the source address of an
>   IPv6 packet.
>
> And from that requirement draft-itojun-ipv6-tcp-to-anycast rightly
> concluded that TCP connections must be prevented.
>
> The draft also states:
>
> The proposed method MUST be removed when one of the following events
> happens in the future:
>
> o  Restriction imposed on IPv6 anycast address is loosened, so that
>anycast address can be placed into source address field of the IPv6
>header[...]

Also worth reading: https://tools.ietf.org/html/rfc4942#section-2.1.6

> OK?

ok jca@

If you don't want to remove M_ACAST from sys/mbuf.h, can you please at
least change the comment?  /* obsolete */ or something.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: ssh(1), getrrsetbyname(3), SSHFP and DNSSEC

2020-07-29 Thread Jeremie Courreges-Anglas
On Wed, Jul 29 2020, Florian Obser  wrote:
> On Wed, Jul 29, 2020 at 03:51:55PM +0200, Jeremie Courreges-Anglas wrote:
>> So I did a few tests and read some unwind(8) code, and it *appears* safe
>> to use unwind(8) along with "options trust-ad".
>
> Yes.
>
>> 
>> First you mention fallback to DHCP-learned resolvers.  Those you should
>> probably not trust indeed, but it looks like unwind(8) attempts to use
>> them to perform its own validation.  So the value of the AD flag in
>> unwind(8)'s response should be trustworthy.  At least that's what I see
>> when I test unwind with "preference { dhcp }".
>>
>
> unwind always does its own validation or decides it can't do
> validation. In both cases you can trust the AD flag.
> The AD flag is set if and only if unwind did a successful validation.
>
> You cannot trust the RCODE (and answer) when AD is *NOT* set. That
> seems like a strange and obvious statement but it is the main
> difference to validating unbound. When you enable validation in
> unbound and someone messes with your packets you will get a SERVFAIL.
>
> You can trick unwind into believing that DNSSEC validation is not
> possible in your current network location. It will still resolve but
> it will NOT set AD.

Thanks for confirming.

> In the context of the current discussion this means that you can't
> validate SSHFPs, but you can still try to connect to your ssh server
> if you have the fingerprint in known_hosts. The later is still save
> even if people play tricks with DNS in your current location.

Yep.

>> And then there's the asr fallback, tested with "preference { stub }".
>> unwind(8) allocates its own asr context, ignoring the global
>> /etc/resolv.conf and thus "options trust-ad".  IIUC it then hands off
>
> Yes. But even if it did not it would not matter since it will clear
> AD.
>
>> the answer to libunbound which cooks its own soup.  So it looks like
>
> No, the asr fallback is there for when your local network is truly
> fucked - think last century equipment that knows DNS is udp/53 only and
> max 512 bytes. While we already lower standards considerably in unwind
> when we use libunbound compared to unbound the network still needs to
> provide some things. Working edns0 is one of them, it's near
> impossible to turn of in libunbound.
>
>> unwind needs no special code to disable/ignore "options trust-ad".
>> 
>> I have no idea how unwind/libunbound behaves when using forwarders, the
>> "accept bogus" feature, (opportunistic) DoT or other stuff I'm probably
>
> Nope, as stated above, you can trust AD.
>
>> overlooking.  But AFAICS using unwind + "options trust-ad" brings no
>> problem.  cc'ing Florian, input welcome.
>> 
>> I think the issue with trust-ad is the list of resolvers that end up in
>> resolv.conf.  I would expect people who use a resolver on localhost to
>> also have other resolvers listed in their /etc/resolv.conf, because of
>> a conscious choice (bsd.rd) or just because it should be more reliable.
>> It seems to me that the resolv.conf(5) manpage addition should cover
>> that.  Or should I make it more explicit?
>> 
>> Index: share/man/man5/resolv.conf.5
>> ===
>> RCS file: /d/cvs/src/share/man/man5/resolv.conf.5,v
>> retrieving revision 1.60
>> diff -u -p -r1.60 resolv.conf.5
>> --- share/man/man5/resolv.conf.5 25 Apr 2020 14:22:04 -  1.60
>> +++ share/man/man5/resolv.conf.5 25 Jul 2020 02:08:17 -
>> @@ -285,6 +285,15 @@ first as an absolute name before any sea
>>  .It Cm tcp
>>  Forces the use of TCP for queries.
>>  Normal behaviour is to query via UDP but fall back to TCP on failure.
>> +.It Cm trust-ad
>> +Sets the AD flag in DNS queries, and preserve the value of the AD flag
>> +in DNS replies (this flag is stripped by default).
>> +Useful when applications want to ensure that the DNS resources they
>> +look up have been signed with DNSSEC and validated by the
>> +.Ic nameserver .
>> +This option should be used only if the transport between the
>> +.Ic nameserver
>> +and the resolver is secure.
>
> The last sentence is the problem in my opinion.

Note: that sentence was adapted from getrrsetbyname(3), stripping the
example list precisely because I didn't want to be specific.  The devil
is in the details.  I'm not even sure loopback communication be
considered secure.

> trust-ad is a button
> mere mortals cannot push.

Do mere mortals care about or rely on DNSSEC? ;)

> The typical answer is: Oh, I use a vpn tunel and my nameserver is
> behind the tunnel. Does the tunel terminate on the nameserver?
> My enterprise vpn hands me 4 resolvers. They are in a different
> subnet than the vpn concentrator.

Well one of the reasons I'm proposing a knob is that I doubt we can find
a one-size-fits-all solution.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: ssh(1), getrrsetbyname(3), SSHFP and DNSSEC

2020-07-29 Thread Jeremie Courreges-Anglas
On Sun, Jul 26 2020, Jeremie Courreges-Anglas  wrote:
> On Sat, Jul 25 2020, Sebastian Benoit  wrote:

[...]

>> If you enable trust-ad on a system that moves around, e.g. your laptop, you
>> will experience failures, which is why unwind tests for this and falls back
>> to non-trusting dhcp learned resolvers in such cases. In fact it also falls
>> back to the stub resolver, i.e. our libc resolver. Which makes me think that
>> trust-ad should not be used when you run unwind (because the whole point of
>> the fallback is that dnssec does not work). But thats a documentation issue.

One important thing to keep in mind: trust-ad is not so much about being
able to do DNSSEC validation.  It's about trusting the validation done
by the resolver(s).  So if the resolver can't do validation and ensures
that AD flag is clear in the reply there is no breach of contract.

> Thanks for pointing this out.  I would expect from unwind(8) that it
> always clears the AD bit from its responses if it could not validate
> them.  Inclusing when it falls back to dynamically learned resolvers or
> the libc resolver.

So I did a few tests and read some unwind(8) code, and it *appears* safe
to use unwind(8) along with "options trust-ad".

First you mention fallback to DHCP-learned resolvers.  Those you should
probably not trust indeed, but it looks like unwind(8) attempts to use
them to perform its own validation.  So the value of the AD flag in
unwind(8)'s response should be trustworthy.  At least that's what I see
when I test unwind with "preference { dhcp }".

And then there's the asr fallback, tested with "preference { stub }".
unwind(8) allocates its own asr context, ignoring the global
/etc/resolv.conf and thus "options trust-ad".  IIUC it then hands off
the answer to libunbound which cooks its own soup.  So it looks like
unwind needs no special code to disable/ignore "options trust-ad".

I have no idea how unwind/libunbound behaves when using forwarders, the
"accept bogus" feature, (opportunistic) DoT or other stuff I'm probably
overlooking.  But AFAICS using unwind + "options trust-ad" brings no
problem.  cc'ing Florian, input welcome.

I think the issue with trust-ad is the list of resolvers that end up in
resolv.conf.  I would expect people who use a resolver on localhost to
also have other resolvers listed in their /etc/resolv.conf, because of
a conscious choice (bsd.rd) or just because it should be more reliable.
It seems to me that the resolv.conf(5) manpage addition should cover
that.  Or should I make it more explicit?

Index: share/man/man5/resolv.conf.5
===
RCS file: /d/cvs/src/share/man/man5/resolv.conf.5,v
retrieving revision 1.60
diff -u -p -r1.60 resolv.conf.5
--- share/man/man5/resolv.conf.525 Apr 2020 14:22:04 -  1.60
+++ share/man/man5/resolv.conf.525 Jul 2020 02:08:17 -
@@ -285,6 +285,15 @@ first as an absolute name before any sea
 .It Cm tcp
 Forces the use of TCP for queries.
 Normal behaviour is to query via UDP but fall back to TCP on failure.
+.It Cm trust-ad
+Sets the AD flag in DNS queries, and preserve the value of the AD flag
+in DNS replies (this flag is stripped by default).
+Useful when applications want to ensure that the DNS resources they
+look up have been signed with DNSSEC and validated by the
+.Ic nameserver .
+This option should be used only if the transport between the
+.Ic nameserver
+and the resolver is secure.
 .El
 .El
 .Pp

Lazy me would be tempted to just let asr trust 127.0.0.1 / ::1 by
default and let others deal with the edge cases, but where is the fun in
that... :)

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: ssh(1), getrrsetbyname(3), SSHFP and DNSSEC

2020-07-29 Thread Jeremie Courreges-Anglas
On Mon, Jul 27 2020, Jesper Wallin  wrote:

[...]

> I still think the RES_USE_AD option might be a useful though, for when
> you want to decide on an application-level whether to trust AD or not?

RES_TRUSTAD can also be used for this, but as the proposed documentation
points out it would be better to let the admin decide.  One
(dis)advantage of using that name is that some external applications
already grok it (eg ports/mail/postfix).

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: ssh(1), getrrsetbyname(3), SSHFP and DNSSEC

2020-07-26 Thread Jeremie Courreges-Anglas
On Sun, Jul 26 2020, Jesper Wallin  wrote:
> On Sat, Jul 25, 2020 at 02:01:06PM +0200, Jeremie Courreges-Anglas wrote:
>> 
>> For those two reasons I think the feature should be opt-in.
>
> Yeah, I agree with you.  My first approach was to have it check what
> kind of DNS record that was requested, and add the AD-flag only if type
> was SSHFP, but that felt even uglier.  I also wasn't so sure my approach
> was the right one after reading the RFCs Peter J. Philipp mentioned.

The quote from RFC6840 seems clear to me, care to share why you had some
doubts if they still exist?

> Perhaps another approach would be to make use of the currently unused
> flags argument in getrrsetbyname(3)?  This way, only getrrsetbyname(3)
> and certain requests are affected by it.

I thought about that too, but getrrsetbyname(3) isn't the only function
of interest.  There's also res_query(3) and friends, which are in more
widely use in the larger ecosystem.  I guess we could restrict AD flag
tweaking to APIs where the caller can actually access the AD flag in the
response, but the "default vs opt-in" question is still present.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: ssh(1), getrrsetbyname(3), SSHFP and DNSSEC

2020-07-26 Thread Jeremie Courreges-Anglas
On Sat, Jul 25 2020, Sebastian Benoit  wrote:
> Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2020.07.25 14:01:06 +0200:
>> On Fri, Jul 17 2020, Jesper Wallin  wrote:
>> > Hi all,
>> >
>> > I recently decided to add SSHFP records for my servers, since I never
>> > memorize or write down my key fingerprints.  I learned that if I
>> > want ssh(1) to trust these records, DNSSEC needs to be enabled for my
>> > zone.  To validate these records, ssh(1) is using getrrsetbyname(3),
>> > which checks if the AD (Authentic Data) flag is set in the response.
>> >
>> > To get a response with the AD flag set, the request itself also needs
>> > to have the AD flag set.  It turns out that getrrsetbyname(3) doesn't
>> > set this and will therefore never get a validated response, unless the
>> > resolver is configured to always send it, no matter what the client
>> > requested.
>> >
>> > It seems like unwind(8) behaves this way but it also responds with the
>> > RRSIG records, which is extra overhead and ignored by getrrsetbyname(3).
>> >
>> > This was mentioned a few years ago [0] and the solution suggested was
>> > to add the RES_USE_DNSSEC to _res.options, which also makes the resolver
>> > respond with the extra RRSIG records.
>> >
>> > Instead, by only setting the AD flag, both the request and the response
>> > has the same size as without the flag set.  The patch below will add
>> > RES_USE_AD as an option to _res.options and set it by default.
>> > This is also the default behaviour in dig(1), which I understand is a
>> > bit different, but that sure added some confusion while debugging this.
>> >
>> > This let you run unbound(8) or any other validating resolver on your
>> > local network and getrrsetbyname(3) will trust it.  Do read the CAVEATS
>> > in the manual of getrrsetbyname(3) though.
>> >
>> > As a side note, I noticed that the default value of _res.options was the
>> > same value as RES_DEFAULT, so I changed it to RES_DEFAULT instead, for
>> > the sake of consistency.
>> >
>> > Thoughts?
>> 
>> Thanks for addressing this longstanding issue.
>> 
>> I think using the AD bit in queries is a good idea. IIRC Peter J.
>> Philipp (cc'd) suggested using it but I was not thrilled because:
>> 
>> 1. the meaning of the AD bit in queries is relatively recent (2013
>>   I think[0])
>> 2. getrrsetbyname also collects signature records, and for this you need
>>   EDNS + the DO bit set.  Implementing this in was not 100% trivial,
>>   I think we had something working but Eric or I were not 100% happy
>>   with it.
>> 
>> 1. is probably not a concern, after all you're supposed to use
>> a trustworthy resolver, which should be modern and understand the
>> purpose of the AD bit in queries.
>> 
>> 2. is probably not a concern either.  I guess that all getrrsetbyname(3)
>> callers only care about the target records and the AD bit, not about the
>> signature records.  (Why would they use it for anyway?).  In the base
>> system, only ssh(1) and traceroute(8) use getrrsetbyname(3).
>> AFAIK no other system provides getrrsetbyname(3), and ISC has removed
>> getrrsetbyname and the whole lwres API in 2017[1].  So I'd say we're
>> free to improve our version of getrrsetbyname(3) as we see fit.
>
> This is a concern for the stub resolver, because edns and AD does not work
> everywhere.
> Indeed when we switched unbound to validate by default we
> learned that this is not a good idea for everyone - which lead to the
> development of unwind(8).

Do you by chance have any data regarding fallout because of the AD bit
set in queries?  I would expect it to be ignored when not supported.
EDNS and the DNSSEC DO bit is a different story indeed.

>> Now let's discuss the implementation.  There are two main things
>> I dislike with your diff:
>> - it affects all DNS queries done through libc, even if the user doesn't
>>   care at all about DNSSEC.  I suspect there's potential for fallout
>>   here, but I have no data to back this.
>> - trusting the AD bit by default looks a bit too easy.  The
>>   documentation says that people should only trust the AD bit /
>>   RRSET_VALIDATED if the communication between libc and the resolver is
>>   secure, but who actually reads the documentation?
>> 
>> For those two reasons I think the feature should be opt-in.  That's what
>> Florian Weimer did in glibc, with the implementation of RES_TRUSTAD[2][3].
>> The diff below implements the same sema

Re: ssh(1), getrrsetbyname(3), SSHFP and DNSSEC

2020-07-25 Thread Jeremie Courreges-Anglas
On Fri, Jul 17 2020, Jesper Wallin  wrote:
> Hi all,
>
> I recently decided to add SSHFP records for my servers, since I never
> memorize or write down my key fingerprints.  I learned that if I
> want ssh(1) to trust these records, DNSSEC needs to be enabled for my
> zone.  To validate these records, ssh(1) is using getrrsetbyname(3),
> which checks if the AD (Authentic Data) flag is set in the response.
>
> To get a response with the AD flag set, the request itself also needs
> to have the AD flag set.  It turns out that getrrsetbyname(3) doesn't
> set this and will therefore never get a validated response, unless the
> resolver is configured to always send it, no matter what the client
> requested.
>
> It seems like unwind(8) behaves this way but it also responds with the
> RRSIG records, which is extra overhead and ignored by getrrsetbyname(3).
>
> This was mentioned a few years ago [0] and the solution suggested was
> to add the RES_USE_DNSSEC to _res.options, which also makes the resolver
> respond with the extra RRSIG records.
>
> Instead, by only setting the AD flag, both the request and the response
> has the same size as without the flag set.  The patch below will add
> RES_USE_AD as an option to _res.options and set it by default.
> This is also the default behaviour in dig(1), which I understand is a
> bit different, but that sure added some confusion while debugging this.
>
> This let you run unbound(8) or any other validating resolver on your
> local network and getrrsetbyname(3) will trust it.  Do read the CAVEATS
> in the manual of getrrsetbyname(3) though.
>
> As a side note, I noticed that the default value of _res.options was the
> same value as RES_DEFAULT, so I changed it to RES_DEFAULT instead, for
> the sake of consistency.
>
> Thoughts?

Thanks for addressing this longstanding issue.

I think using the AD bit in queries is a good idea. IIRC Peter J.
Philipp (cc'd) suggested using it but I was not thrilled because:

1. the meaning of the AD bit in queries is relatively recent (2013
  I think[0])
2. getrrsetbyname also collects signature records, and for this you need
  EDNS + the DO bit set.  Implementing this in was not 100% trivial,
  I think we had something working but Eric or I were not 100% happy
  with it.

1. is probably not a concern, after all you're supposed to use
a trustworthy resolver, which should be modern and understand the
purpose of the AD bit in queries.

2. is probably not a concern either.  I guess that all getrrsetbyname(3)
callers only care about the target records and the AD bit, not about the
signature records.  (Why would they use it for anyway?).  In the base
system, only ssh(1) and traceroute(8) use getrrsetbyname(3).
AFAIK no other system provides getrrsetbyname(3), and ISC has removed
getrrsetbyname and the whole lwres API in 2017[1].  So I'd say we're
free to improve our version of getrrsetbyname(3) as we see fit.

Now let's discuss the implementation.  There are two main things
I dislike with your diff:
- it affects all DNS queries done through libc, even if the user doesn't
  care at all about DNSSEC.  I suspect there's potential for fallout
  here, but I have no data to back this.
- trusting the AD bit by default looks a bit too easy.  The
  documentation says that people should only trust the AD bit /
  RRSET_VALIDATED if the communication between libc and the resolver is
  secure, but who actually reads the documentation?

For those two reasons I think the feature should be opt-in.  That's what
Florian Weimer did in glibc, with the implementation of RES_TRUSTAD[2][3].
The diff below implements the same semantics:
- by default, don't send queries the AD flag, and don't trust its value
  in replies
- if "options trust-ad" is set in resolv.conf(5), set the AD flag in
  queries and allow applications to look at the AD flag in replies.

There's one more thing I'd like to check in the res_* API, but I'm
sitting on this idea since too long already, and I'm happy with my test
results so far.

Thoughts?  Comments?

[0] https://tools.ietf.org/html/rfc6840#section-5.7
[1] 
https://gitlab.isc.org/isc-projects/bind9/-/commit/8eb88aafee951859264e36c315b1289cd8c2088b
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1164339
[3] 
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=446997ff1433d33452b81dfa9e626b8dccf101a4



Index: include/resolv.h
===
RCS file: /d/cvs/src/include/resolv.h,v
retrieving revision 1.22
diff -u -p -r1.22 resolv.h
--- include/resolv.h14 Jan 2019 06:23:06 -  1.22
+++ include/resolv.h23 Jul 2020 13:28:15 -
@@ -186,6 +186,8 @@ struct __res_state_ext {
 #defineRES_INSECURE2   0x0800  /* type 2 security disabled */
 #defineRES_NOALIASES   0x1000  /* shuts off HOSTALIASES 
feature */
 #defineRES_USE_INET6   0x2000  /* use/map IPv6 in 
gethostbyname() */
+/* GNU extension: use higher bit to avoid conflict with 

ksh(1) set -o pipefail

2020-07-06 Thread Jeremie Courreges-Anglas


Requested by ajacoutot@, here's an attempt at implementing set -o
pipefail.  As pointed by sthen@ this option should be included in the
next POSIX standard:

  https://www.austingroupbugs.net/view.php?id=789

There are several ways to implement it, the diff I showed to Antoine was
based on option 2) in

  https://www.austingroupbugs.net/view.php?id=789#c4102

whereas the diff below implements option 1) described by kre@NetBSD,
which looks like the most sensible approach.

No, this doesn't add support for a PIPESTATUS array, I'm not sure we need it.

This diff includes manpage and regress bits.
Thoughts, oks?


Index: bin/ksh/jobs.c
===
RCS file: /d/cvs/src/bin/ksh/jobs.c,v
retrieving revision 1.61
diff -u -p -r1.61 jobs.c
--- bin/ksh/jobs.c  28 Jun 2019 13:34:59 -  1.61
+++ bin/ksh/jobs.c  6 Jul 2020 18:10:43 -
@@ -70,6 +70,7 @@ struct proc {
 #define JF_REMOVE  0x200   /* flagged for removal (j_jobs()/j_notify()) */
 #define JF_USETTYMODE  0x400   /* tty mode saved if process exits normally */
 #define JF_SAVEDTTYPGRP0x800   /* j->saved_ttypgrp is valid */
+#define JF_PIPEFAIL0x1000  /* pipefail on when job was started */
 
 typedef struct job Job;
 struct job {
@@ -421,6 +422,8 @@ exchild(struct op *t, int flags, volatil
 */
j->flags = (flags & XXCOM) ? JF_XXCOM :
((flags & XBGND) ? 0 : (JF_FG|JF_USETTYMODE));
+   if (Flag(FPIPEFAIL))
+   j->flags |= JF_PIPEFAIL;
timerclear(>usrtime);
timerclear(>systime);
j->state = PRUNNING;
@@ -1084,7 +1087,30 @@ j_waitj(Job *j,
 
j_usrtime = j->usrtime;
j_systime = j->systime;
-   rv = j->status;
+
+   if (j->flags & JF_PIPEFAIL) {
+   Proc *p;
+   int status;
+
+   rv = 0;
+   for (p = j->proc_list; p != NULL; p = p->next) {
+   switch (p->state) {
+   case PEXITED:
+   status = WEXITSTATUS(p->status);
+   break;
+   case PSIGNALLED:
+   status = 128 + WTERMSIG(p->status);
+   break;
+   default:
+   status = 0;
+   break;
+   }
+   if (status)
+   rv = status;
+   }
+   } else
+   rv = j->status;
+
 
if (!(flags & JW_ASYNCNOTIFY) &&
(!Flag(FMONITOR) || j->state != PSTOPPED)) {
Index: bin/ksh/ksh.1
===
RCS file: /d/cvs/src/bin/ksh/ksh.1,v
retrieving revision 1.208
diff -u -p -r1.208 ksh.1
--- bin/ksh/ksh.1   26 Nov 2019 22:49:01 -  1.208
+++ bin/ksh/ksh.1   6 Jul 2020 16:04:34 -
@@ -361,7 +361,9 @@ token to form pipelines, in which the st
 last is piped (see
 .Xr pipe 2 )
 to the standard input of the following command.
-The exit status of a pipeline is that of its last command.
+The exit status of a pipeline is that of its last command, unless the
+.Ic pipefail
+option is set.
 A pipeline may be prefixed by the
 .Ql \&!
 reserved word, which causes the exit status of the pipeline to be logically
@@ -3664,6 +3666,10 @@ See the
 and
 .Ic pwd
 commands above for more details.
+.It Ic pipefail
+The exit status of a pipeline is the exit status of the rightmost
+command in the pipeline that doesn't return 0, or 0 if all commands
+returned a 0 exit status.
 .It Ic posix
 Enable POSIX mode.
 See
Index: bin/ksh/misc.c
===
RCS file: /d/cvs/src/bin/ksh/misc.c,v
retrieving revision 1.73
diff -u -p -r1.73 misc.c
--- bin/ksh/misc.c  28 Jun 2019 13:34:59 -  1.73
+++ bin/ksh/misc.c  6 Jul 2020 16:04:34 -
@@ -147,6 +147,7 @@ const struct option sh_options[] = {
{ "notify", 'b',OF_ANY },
{ "nounset",'u',OF_ANY },
{ "physical", 0,OF_ANY }, /* non-standard */
+   { "pipefail", 0,OF_ANY }, /* non-standard */
{ "posix",0,OF_ANY }, /* non-standard */
{ "privileged", 'p',OF_ANY },
{ "restricted", 'r',OF_CMDLINE },
Index: bin/ksh/sh.h
===
RCS file: /d/cvs/src/bin/ksh/sh.h,v
retrieving revision 1.75
diff -u -p -r1.75 sh.h
--- bin/ksh/sh.h20 Feb 2019 23:59:17 -  1.75
+++ bin/ksh/sh.h6 Jul 2020 16:13:59 -
@@ -158,6 +158,7 @@ enum sh_flag {
FNOTIFY,/* -b: asynchronous job completion notification */
FNOUNSET,   /* -u: using an unset var is an error */
FPHYSICAL,  /* -o physical: don't do 

ftp(1) double free

2020-06-20 Thread Jeremie Courreges-Anglas


Small bug, but still...

naddy@ reported a double free when interrupting (^C) ftp(1) at the end
or url_get().  If that happens, the SIGINT handler longjmps and the
cleanup path is taken a second time.  To avoid this, restore the
previous SIGINT handler in each possible error path.  I chose to restore
it earlier in the successful path to avoid too much duplication.
file_get() gets the same treatment.

Note that naddy hit this because of another bug causing ftp_close()
to stall, and this depends on the server you're talking to.  You can
insert a sleep(10); call before "return (rval);" to help reproduce the
crash.

ok?


Index: fetch.c
===
RCS file: /d/cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.195
diff -u -p -p -u -r1.195 fetch.c
--- fetch.c 20 Jun 2020 09:59:48 -  1.195
+++ fetch.c 21 Jun 2020 00:12:10 -
@@ -261,6 +261,7 @@ file_get(const char *path, const char *o
for (cp = buf; len > 0; len -= wlen, cp += wlen) {
if ((wlen = write(out, cp, len)) == -1) {
warn("Writing %s", savefile);
+   signal(SIGINT, oldintr);
signal(SIGINFO, oldinti);
goto cleanup_copy;
}
@@ -274,6 +275,7 @@ file_get(const char *path, const char *o
}
}
save_errno = errno;
+   signal(SIGINT, oldintr);
signal(SIGINFO, oldinti);
if (hash && !progress && bytes > 0) {
if (bytes < mark)
@@ -288,7 +290,6 @@ file_get(const char *path, const char *o
progressmeter(1, NULL);
if (verbose)
ptransfer(0);
-   (void)signal(SIGINT, oldintr);
 
rval = 0;
 
@@ -1032,6 +1033,7 @@ noslash:
oldinti = signal(SIGINFO, psummary);
if (chunked) {
error = save_chunked(fin, tls, out, buf, buflen);
+   signal(SIGINT, oldintr);
signal(SIGINFO, oldinti);
if (error == -1)
goto cleanup_url_get;
@@ -1041,6 +1043,7 @@ noslash:
for (cp = buf; len > 0; len -= wlen, cp += wlen) {
if ((wlen = write(out, cp, len)) == -1) {
warn("Writing %s", savefile);
+   signal(SIGINT, oldintr);
signal(SIGINFO, oldinti);
goto cleanup_url_get;
}
@@ -1054,6 +1057,7 @@ noslash:
}
}
save_errno = errno;
+   signal(SIGINT, oldintr);
signal(SIGINFO, oldinti);
if (hash && !progress && bytes > 0) {
if (bytes < mark)
@@ -1080,7 +1084,6 @@ noslash:
 
if (verbose)
ptransfer(0);
-   (void)signal(SIGINT, oldintr);
 
rval = 0;
goto cleanup_url_get;


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: official ports vs DEBUG_PACKAGES

2020-05-30 Thread Jeremie Courreges-Anglas
On Sat, May 30 2020, Marc Espie  wrote:
>> - have some magic I don't know in ELF handling that would allow to either
>> tweak the default location/introduce ${WRKOBJDIR} in that debug info.
>
> Thinking some more about it, that 3rd option is possibly not that
> far-fetched
>
> we do pass most debug-info thru dwz  for shrinkage, so there's one tool
> that does peek inside dwarf debug and does compaction, I have zero idea how
> hard it is to tweak paths as well.

Take a look at -fdebug-prefix-map.

  https://reproducible-builds.org/docs/build-path/

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: net80211: fix capinfo in assoc request

2020-05-18 Thread Jeremie Courreges-Anglas
On Thu, May 14 2020, Stefan Sperling  wrote:
> The capablities info field in an association request contains an ESS bit
> which is set if the sender is an access point (there are other cases but
> they don't matter for us; see 802.11-2012 8.4.1.4 if you are interested).
>
> This bit is set when OpenBSD clients send an association request to an AP.
> This seems wrong. The ESS bit should be zero when sent by clients.
>
> Noticed while looking over packet captures for an unrelated issue.
>
> ok?

Makes sense and works for me, ok jca@

> diff 4a0fa473f5ea308b63ffd39645f73b2195291973 /usr/src
> blob - 7952471d5bb369c9bb844966425fffc892a71038
> file + sys/net80211/ieee80211_output.c
> --- sys/net80211/ieee80211_output.c
> +++ sys/net80211/ieee80211_output.c
> @@ -1384,7 +1384,7 @@ ieee80211_get_assoc_req(struct ieee80211com *ic, struc
>   return NULL;
>  
>   frm = mtod(m, u_int8_t *);
> - capinfo = IEEE80211_CAPINFO_ESS;
> + capinfo = 0;
>   if (ic->ic_flags & IEEE80211_F_WEPON)
>   capinfo |= IEEE80211_CAPINFO_PRIVACY;
>   if ((ic->ic_flags & IEEE80211_F_SHPREAMBLE) &&
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



acpi(4): battery and A/C status after resume

2020-05-17 Thread Jeremie Courreges-Anglas
On Sat, Jan 25 2020, Jeremie Courreges-Anglas  wrote:
> So I have this diff for apmd -z/-Z that uses APM_POWER_CHANGE events to
> trigger autosuspend.  It works fine except for one glitch: if I plug the
> AC cable and then resume, apmd will receive another APM_POWER_CHANGE
> event and read the power info only to find that the AC is *unplugged*.
> So apmd happily suspends my system again.  If I resume once more, the AC
> status is correctly detected and apmd(8) doesn't suspend the system again.
>
> What happens is that acpibat_notify runs because of ACPIDEV_POLL, it
> grabs battery data and sends an APM_POWER_CHANGE event to apmd.  At this
> point apmd may see out of date data from acpiac(4).
>
> acpi_sleep_task later forces a refresh of (in order) acpiac(4),
> acpibat(4) and acpisbs(4), but in my use case it's too late, the window
> with stale acpiac(4) data is too long.

Even though apmd(8) -z/-Z isn't negatively affected any more, this
problem holds.  acpibat(4) can send APM_POWER_CHANGE events to userland
before the acpi thread refreshes acpiac(4) status. You can easily check
this by running apmd -d and going through zzz cycles with A/C
plugged/unplugged.

I think we should show a consistent state to userland, even if the apm
emulation in acpi(4) is implemented using several drivers,

> The diff below refreshes AC status with notifications at DVACT_WAKEUP
> time.  Is is correct that DVACT_WAKEUP handlers will always run before
> the ACPI task queue is processed?  "No" seems unlikely but I'd rather
> ask...

The answer was "yes"...

> I hear we prefer running ACPI code in its dedicated thread but there are
> other drivers in dev/acpi that run ACPI code in DVACT_WAKEUP, so I'm
> assuming it is fine. :)

Indeed it's fine.  The acpi thread runs acpi_sleep_state() and thus the
DVACT_WAKEUP handlers.  I guess that stuff looked like pure magic to me
at that time.


The diff below teaches acpiac(4), acpibat(4) and acpisbs(4) to refresh
their state using DVACT_WAKEUP handlers instead of using the *_notify
handlers in acpi_sleep_task().  This ensures a consistent state right
after resume, and makes those drivers less special.

I'm reusing the *_refresh functions in the new handlers, so send
APM_POWER_CHANGE events from the *_notify functions instead.

Finally, at the end of acpi_sleep_task() queue an APM_POWER_CHANGE event
so that userland can look at fresh power info as soon as possible.

Thoughts?  oks?


Index: acpi.c
===
RCS file: /d/cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.385
diff -u -p -r1.385 acpi.c
--- acpi.c  14 May 2020 13:07:10 -  1.385
+++ acpi.c  17 May 2020 12:08:11 -
@@ -1942,20 +1942,11 @@ void
 acpi_sleep_task(void *arg0, int sleepmode)
 {
struct acpi_softc *sc = arg0;
-   struct acpi_ac *ac;
-   struct acpi_bat *bat;
-   struct acpi_sbs *sbs;
 
/* System goes to sleep here.. */
acpi_sleep_state(sc, sleepmode);
-
-   /* AC and battery information needs refreshing */
-   SLIST_FOREACH(ac, >sc_ac, aac_link)
-   aml_notify(ac->aac_softc->sc_devnode, 0x80);
-   SLIST_FOREACH(bat, >sc_bat, aba_link)
-   aml_notify(bat->aba_softc->sc_devnode, 0x80);
-   SLIST_FOREACH(sbs, >sc_sbs, asbs_link)
-   aml_notify(sbs->asbs_softc->sc_devnode, 0x80);
+   /* Tell userland to recheck A/C and battery status */
+   acpi_record_event(sc, APM_POWER_CHANGE);
 }
 
 #endif /* SMALL_KERNEL */
Index: acpiac.c
===
RCS file: /d/cvs/src/sys/dev/acpi/acpiac.c,v
retrieving revision 1.32
diff -u -p -r1.32 acpiac.c
--- acpiac.c9 May 2020 00:40:48 -   1.32
+++ acpiac.c9 May 2020 00:55:46 -
@@ -33,13 +33,18 @@
 
 int  acpiac_match(struct device *, void *, void *);
 void acpiac_attach(struct device *, struct device *, void *);
+int  acpiac_activate(struct device *, int);
 int  acpiac_notify(struct aml_node *, int, void *);
 
 void acpiac_refresh(void *);
 int acpiac_getpsr(struct acpiac_softc *);
 
 struct cfattach acpiac_ca = {
-   sizeof(struct acpiac_softc), acpiac_match, acpiac_attach
+   sizeof(struct acpiac_softc),
+   acpiac_match,
+   acpiac_attach,
+   NULL,
+   acpiac_activate,
 };
 
 struct cfdriver acpiac_cd = {
@@ -92,6 +97,21 @@ acpiac_attach(struct device *parent, str
acpiac_notify, sc, ACPIDEV_NOPOLL);
 }
 
+int
+acpiac_activate(struct device *self, int act)
+{
+   struct acpiac_softc *sc = (struct acpiac_softc *)self;
+
+   switch (act) {
+   case DVACT_WAKEUP:
+   acpiac_refresh(sc);
+   dnprintf(10, "A/C status: %d\n", sc->sc_ac_stat);
+   break;
+   }
+
+   return (0);
+}
+
 void
 acpiac_refresh(void *arg)

Re: acpibat(4): remaining battery power with multiple batteries

2020-05-11 Thread Jeremie Courreges-Anglas
On Mon, May 11 2020, "Theo de Raadt"  wrote:
> You sure about that?  In this code, acpi.c is collecting abstracted
> information from the 3 battery drivers.

(One A/C driver and two battery drivers.)

> Maybe one of the drivers
> isn't providing enough information?
>
> Mark Kettenis  wrote:
>
>> This wouldn't do the right thing if you have both acpibat(4) and
>> acpisbs(4), but I think that is already broken.

acpibat(4) doesn't attach if acpisbs(4) is present:

  int
  acpibat_match(struct device *parent, void *match, void *aux)
  {
struct acpi_attach_args *aa = aux;
struct cfdata   *cf = match;

if (((struct acpi_softc *)parent)->sc_havesbs)
return (0);


I guess this could be made more explicit by splitting those loops.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: acpibat(4): remaining battery power with multiple batteries

2020-05-11 Thread Jeremie Courreges-Anglas
On Fri, May 08 2020, Jeremie Courreges-Anglas  wrote:
> Overall remaining battery power is currently the average of the
> remaining power (in percents) of each battery.  This is misleading if
> your laptop uses a large external battery which drains out first, and
> a smaller internal battery (common scheme on eg thinkpad machines).
> Overall battery power decreases much faster when you switch to the
> smaller battery.  This odd behavior was reported by a friend a few weeks
> ago.
>
> The diff below attempts to fix this: compute the sum of the remaining
> power and capacity, *then* compute the overall remaining percentage.
> No regression on my thinkpad x270 with two batteries of similar
> capacity.  I don't know whether the original reporter will be able to
> test this soon.
>
> The code touches the acpisbs(4) bits, hopefully without changing the
> current behavior.  acpisbs(4) currently doesn't support multiple
> batteries.
>
> Test reports, feedback, oks welcome.

I got successful test reports from benno@ and fellow lidstah (original
reporter).  With a 6600mAh external battery and a 2200mAh internal
battery, lidstah sees an overall battery percentage at ~22% instead of
~50% when the external battery drains out.

Still looking for oks :)


Index: acpi.c
===
RCS file: /d/cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.383
diff -u -p -p -u -r1.383 acpi.c
--- acpi.c  8 May 2020 11:18:01 -   1.383
+++ acpi.c  8 May 2020 15:04:50 -
@@ -3503,7 +3503,7 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
struct acpi_sbs *sbs;
struct apm_power_info *pi = (struct apm_power_info *)data;
int bats;
-   unsigned int remaining, rem, minutes, rate;
+   unsigned int capacity, remaining, minutes, rate;
int s;
 
if (!acpi_cd.cd_ndevs || APMUNIT(dev) != 0 ||
@@ -3554,7 +3554,8 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
pi->battery_life = 0;
pi->minutes_left = 0;
bats = 0;
-   remaining = rem = 0;
+   capacity = 0;
+   remaining = 0;
minutes = 0;
rate = 0;
SLIST_FOREACH(bat, >sc_bat, aba_link) {
@@ -3565,11 +3566,9 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
continue;
 
bats++;
-   rem = (bat->aba_softc->sc_bst.bst_capacity * 100) /
-   bat->aba_softc->sc_bix.bix_last_capacity;
-   if (rem > 100)
-   rem = 100;
-   remaining += rem;
+   capacity += bat->aba_softc->sc_bix.bix_last_capacity;
+   remaining += min(bat->aba_softc->sc_bst.bst_capacity,
+   bat->aba_softc->sc_bix.bix_last_capacity);
 
if (bat->aba_softc->sc_bst.bst_rate == BST_UNKNOWN)
continue;
@@ -3587,10 +3586,9 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
continue;
 
bats++;
-   rem = sbs->asbs_softc->sc_battery.rel_charge;
-   if (rem > 100)
-   rem = 100;
-   remaining += rem;
+   capacity += 100;
+   remaining += min(100,
+   sbs->asbs_softc->sc_battery.rel_charge);
 
if (sbs->asbs_softc->sc_battery.run_time ==
ACPISBS_VALUE_UNKNOWN)
@@ -3613,7 +3611,7 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
pi->minutes_left = 60 * minutes / rate;
 
/* running on battery */
-   pi->battery_life = remaining / bats;
+   pi->battery_life = remaining * 100 / capacity;
if (pi->battery_life > 50)
pi->battery_state = APM_BATT_HIGH;
else if (pi->battery_life > 25)

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



acpiac(4): no need to look at _STA

2020-05-08 Thread Jeremie Courreges-Anglas



acpiac(4) obtains the AC status using _PSR.  _STA is queried too but
nothing is done with the result.  AFAICS ACPI 6.3 doesn't say anything
about a relationship between _STA and _PSR.

Diff below removes the unused _STA query and renames the surrounding
plumbing.

Thoughts, oks?


Index: acpiac.c
===
RCS file: /d/cvs/src/sys/dev/acpi/acpiac.c,v
retrieving revision 1.31
diff -u -p -p -u -r1.31 acpiac.c
--- acpiac.c1 Jul 2018 19:40:49 -   1.31
+++ acpiac.c8 May 2020 17:10:18 -
@@ -36,7 +36,7 @@ void acpiac_attach(struct device *, stru
 int  acpiac_notify(struct aml_node *, int, void *);
 
 void acpiac_refresh(void *);
-int acpiac_getsta(struct acpiac_softc *);
+int acpiac_getpsr(struct acpiac_softc *);
 
 struct cfattach acpiac_ca = {
sizeof(struct acpiac_softc), acpiac_match, acpiac_attach
@@ -70,7 +70,7 @@ acpiac_attach(struct device *parent, str
sc->sc_acpi = (struct acpi_softc *)parent;
sc->sc_devnode = aa->aaa_node;
 
-   acpiac_getsta(sc);
+   acpiac_getpsr(sc);
printf(": AC unit ");
if (sc->sc_ac_stat == PSR_ONLINE)
printf("online\n");
@@ -97,27 +97,23 @@ acpiac_refresh(void *arg)
 {
struct acpiac_softc *sc = arg;
 
-   acpiac_getsta(sc);
+   acpiac_getpsr(sc);
sc->sc_sens[0].value = sc->sc_ac_stat;
acpi_record_event(sc->sc_acpi, APM_POWER_CHANGE);
 }
 
 int
-acpiac_getsta(struct acpiac_softc *sc)
+acpiac_getpsr(struct acpiac_softc *sc)
 {
-   int64_t sta;
+   int64_t psr;
 
-   if (aml_evalname(sc->sc_acpi, sc->sc_devnode, "_STA", 0, NULL, NULL)) {
-   dnprintf(10, "%s: no _STA\n",
-   DEVNAME(sc));
-   }
-
-   if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "_PSR", 0, NULL, 
)) {
+   if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "_PSR", 0, NULL, 
)) {
dnprintf(10, "%s: no _PSR\n",
DEVNAME(sc));
return (1);
}
-   sc->sc_ac_stat = sta;
+   sc->sc_ac_stat = psr;
+
return (0);
 }
 

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



acpibat(4): remaining battery power with multiple batteries

2020-05-08 Thread Jeremie Courreges-Anglas


Overall remaining battery power is currently the average of the
remaining power (in percents) of each battery.  This is misleading if
your laptop uses a large external battery which drains out first, and
a smaller internal battery (common scheme on eg thinkpad machines).
Overall battery power decreases much faster when you switch to the
smaller battery.  This odd behavior was reported by a friend a few weeks
ago.

The diff below attempts to fix this: compute the sum of the remaining
power and capacity, *then* compute the overall remaining percentage.
No regression on my thinkpad x270 with two batteries of similar
capacity.  I don't know whether the original reporter will be able to
test this soon.

The code touches the acpisbs(4) bits, hopefully without changing the
current behavior.  acpisbs(4) currently doesn't support multiple
batteries.

Test reports, feedback, oks welcome.


Index: acpi.c
===
RCS file: /d/cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.383
diff -u -p -p -u -r1.383 acpi.c
--- acpi.c  8 May 2020 11:18:01 -   1.383
+++ acpi.c  8 May 2020 15:04:50 -
@@ -3503,7 +3503,7 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
struct acpi_sbs *sbs;
struct apm_power_info *pi = (struct apm_power_info *)data;
int bats;
-   unsigned int remaining, rem, minutes, rate;
+   unsigned int capacity, remaining, minutes, rate;
int s;
 
if (!acpi_cd.cd_ndevs || APMUNIT(dev) != 0 ||
@@ -3554,7 +3554,8 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
pi->battery_life = 0;
pi->minutes_left = 0;
bats = 0;
-   remaining = rem = 0;
+   capacity = 0;
+   remaining = 0;
minutes = 0;
rate = 0;
SLIST_FOREACH(bat, >sc_bat, aba_link) {
@@ -3565,11 +3566,9 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
continue;
 
bats++;
-   rem = (bat->aba_softc->sc_bst.bst_capacity * 100) /
-   bat->aba_softc->sc_bix.bix_last_capacity;
-   if (rem > 100)
-   rem = 100;
-   remaining += rem;
+   capacity += bat->aba_softc->sc_bix.bix_last_capacity;
+   remaining += min(bat->aba_softc->sc_bst.bst_capacity,
+   bat->aba_softc->sc_bix.bix_last_capacity);
 
if (bat->aba_softc->sc_bst.bst_rate == BST_UNKNOWN)
continue;
@@ -3587,10 +3586,9 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
continue;
 
bats++;
-   rem = sbs->asbs_softc->sc_battery.rel_charge;
-   if (rem > 100)
-   rem = 100;
-   remaining += rem;
+   capacity += 100;
+   remaining += min(100,
+   sbs->asbs_softc->sc_battery.rel_charge);
 
if (sbs->asbs_softc->sc_battery.run_time ==
ACPISBS_VALUE_UNKNOWN)
@@ -3613,7 +3611,7 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
pi->minutes_left = 60 * minutes / rate;
 
/* running on battery */
-   pi->battery_life = remaining / bats;
+   pi->battery_life = remaining * 100 / capacity;
if (pi->battery_life > 50)
pi->battery_state = APM_BATT_HIGH;
else if (pi->battery_life > 25)

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: ksh: Use typedef for function pointer

2020-05-08 Thread Jeremie Courreges-Anglas
On Thu, May 07 2020, Michael Forney  wrote:
> I originally submitted this patch as a portability fix to Brian
> Callahan's oksh, but he suggested I submit it here instead.

Out of curiosity, do you run (o)ksh on machines where this matters?

> Conversion of function pointer to void pointer is not allowed in
> ISO C, though POSIX requires it for dlsym(). However, here we are
> also comparing function pointer to void pointer with the == operator
> without using a cast, which is a constraint error[0].
>
> Rather than add a cast, we can just use a typedef here for the
> function pointer type, avoiding any C extensions, and adding a bit
> of type-safety.

Aside from the increased portability, the code doesn't look worse, and
fewer uses of void * is nice.  I'll commit this soon if I don't hear
objections (oks also welcome, obviously).

> [0] https://port70.net/~nsz/c/c11/n1570.html#6.5.9p2
> ---
>  bin/ksh/emacs.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/bin/ksh/emacs.c b/bin/ksh/emacs.c
> index aa2cceb657d..b63735956a3 100644
> --- a/bin/ksh/emacs.c
> +++ b/bin/ksh/emacs.c
> @@ -41,8 +41,10 @@ static Areaaedit;
>  #define  KEOL1   /* ^M, ^J */
>  #define  KINTR   2   /* ^G, ^C */
>  
> +typedef int (*kb_func)(int);
> +
>  struct   x_ftab {
> - int (*xf_func)(int c);
> + kb_func xf_func;
>   const char  *xf_name;
>   short   xf_flags;
>  };
> @@ -861,7 +863,7 @@ x_eot_del(int c)
>   return (x_del_char(c));
>  }
>  
> -static void *
> +static kb_func
>  kb_find_hist_func(char c)
>  {
>   struct kb_entry *k;
> @@ -1315,7 +1317,7 @@ kb_del(struct kb_entry *k)
>  }
>  
>  static struct kb_entry *
> -kb_add_string(void *func, void *args, char *str)
> +kb_add_string(kb_func func, void *args, char *str)
>  {
>   unsigned intele, count;
>   struct kb_entry *k;
> @@ -1350,7 +1352,7 @@ kb_add_string(void *func, void *args, char *str)
>  }
>  
>  static struct kb_entry *
> -kb_add(void *func, ...)
> +kb_add(kb_func func, ...)
>  {
>   va_list ap;
>   unsigned char   ch;

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: ld.so and ldconfig manpage nits

2020-05-08 Thread Jeremie Courreges-Anglas
On Fri, May 08 2020, Miod Vallat  wrote:
> This ensures consistent spelling of set-{user,group}-ID, and also
> mentions LD_DEBUG is ignored by ld.so for such binaries.

Committed, thanks!

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



  1   2   3   4   5   6   7   8   >