Re: __cxa_thread_atexit

[Philip Guenther]

On Mon, 4 Dec 2017, Mark Kettenis wrote:
> The ld.so bits have been committed last week.  So here is a new version 
> of the diff.  This version exports __cxa_thread_atexit_impl such that 
> gcc picks up our implementation.  __cxa_thread_atexit becomes a weak 
> alias such that static linking succeeds.  I rebuilt the gcc 4.9 port 
> with this diff and verified that it does indeed run the new code.

Per our discussion on the trail to the Lower Elk lake overlook, I think 
you should leave out the #ifndef NO_PIC/#endif around the call to dlctl() 
in __cxa_thread_atexit_impl(): NO_PIC is never defined in libc and we 
don't really have an interest in optimizing for a future arch that doesn't 
support shared libs.

Other than that: ok guenther@

Philip

Re: dc(1); fix 0Z

[kshe]

On Sun, 03 Dec 2017 12:25:15 +, Philippe Meunier wrote:
> kshe wrote:
> >Also, the manual defines the length of a number as its number of digits,
> >so perhaps it should be precised that zero is considered to have no
> >digits, which might not be obvious to everyone.
>
> Am I the only who thinks this is not just not obvious, but actually wrong?

If the number `002' is said to have only one digit because the zeros in
the left are not significant, then likewise the number `000', which
hence only has insignificant digits, can in perfect coherence be
considered to have no digits at all.

Another way to see why this makes sense is by defining the number of
digits in base b of an integer n by

intlog_b(n) + 1 := floor(log_b(n)) + 1

and noticing that the very natural recursive expression of such integer
logarithm

intlog_b(n+1) = | intlog_b(n) + 1   if n+1 is a power of b
| intlog_b(n)   otherwise

can be made to hold for n = 0 if and only if one sets intlog_b(0) = -1
by convention, which indeed leads to the conclusion that zero must have
zero digits as per the definition above.  Any other convention for the
value of intlog_b(0) would not preserve this fundamental invariant of
the integer logarithm, thus being nothing but arbitrary, and as such of
little practical value.

Regards,

kshe

Re: ddb: show panic on page fault

[Mark Kettenis]

> Date: Mon, 4 Dec 2017 11:24:36 +0200
> From: Paul Irofti 
> 
> On Sun, Nov 05, 2017 at 02:48:59AM +0200, Paul Irofti wrote:
> > On Sun, Nov 05, 2017 at 01:43:35AM +0100, Mark Kettenis wrote:
> > > > Date: Sat, 4 Nov 2017 18:51:34 +0100
> > > > From: Martin Pieuchot 
> > > > 
> > > > On 04/11/17(Sat) 17:20, Paul Irofti wrote:
> > > > > Hi,
> > > > > 
> > > > > Someone, somewhere (perhaps on bugs@?) said they would like to see
> > > > > something useful when typing show panic on a page fault'd kernel. That
> > > > > struck very close to home so I went ahead and did it.
> > > > > 
> > > > > The following diff shows the uvm_fault and the first trace entry in an
> > > > > attempt to mimic a real show panic. The uvm_fault entry is extra.
> > > > > 
> > > > > Currently I only wrote support for amd64 but I can add support for
> > > > > other architectures if you guys like it.
> > > > > 
> > > > > Thoughts?
> > > > 
> > > > I think you should just change the printf("uvm_fault...) into a panic.
> > > 
> > > No.  That makes it a lot harder to investigate the faulting instruction.
> > > 
> > > I think Paul's idea makes sense; might need a bit of polishing though.
> > 
> > Good, we now have a direction. I am all ears about polishing the current 
> > diff.
> > The construct is the same as that used for panicstr.
> 
> Ping! Should I commit this as is for you to polish later?

Please send the diff again.  It dropped from my cache ;).

Re: pf neighbor discovery hop limit

[Alexander Bluhm]

On Mon, Dec 04, 2017 at 08:23:26PM +, Job Snijders wrote:
> On Mon, Dec 04, 2017 at 02:55:16PM +0100, Alexander Bluhm wrote:
> > RFC 4861 requires that all neighbor discovery packets have 255 in
> > their IPv6 header hop limit field.  Let pf drop neighbor solicitation,
> > neighbor advertisement, router solicitation, router advertisement,
> > and redirect ICMP6 packets that do not comply.  This enforces that
> > bogus packets cannot be routed when pf is enabled.
> > 
> > ok?
> 
> Wouldn't this be a duplicate of "if (ip6->ip6_hlim != 255)" checks done
> in sys/netinet6/{icmp6,nd6_nbr,nd6_rtr}.c ?

These checks are never done for forwarded packets.  They protect
our own stack.  pf is there to protect the network behind the
firewall.

bluhm

Re: iked: parse more than one proposal

[Patrick Wildt]

On Mon, Dec 04, 2017 at 09:23:17PM +0100, Patrick Wildt wrote:
> Hi,
> 
> this diff changes our SA payload parser to parse more than the first
> proposal.  This allows us to select one of the peer's proposals (and not
> only the first).  The xforms parser calls itself recursively without
> limits, which I'm not sure is a good idea.  This diff uses a do {} while
> for the proposal parser instead.  I'm not sure this is great, but I
> think it's better than the recursive way.  I'd like to change the xforms
> parser to do the same later on.
> 
> ok?
> 
> Patrick

Updated diff, because I had committed something in the meantime.  Should
apply cleanly to -current.

diff --git a/sbin/iked/ikev2_pld.c b/sbin/iked/ikev2_pld.c
index f3e21c3a41c..fb599d1c080 100644
--- a/sbin/iked/ikev2_pld.c
+++ b/sbin/iked/ikev2_pld.c
@@ -326,10 +326,6 @@ ikev2_validate_sa(struct iked_message *msg, size_t offset, 
size_t left,
return (0);
 }
 
-/*
- * NB: This function parses both the SA header and the first proposal.
- * Additional proposals are ignored.
- */
 int
 ikev2_pld_sa(struct iked *env, struct ikev2_payload *pld,
 struct iked_message *msg, size_t offset, size_t left)
@@ -342,95 +338,97 @@ ikev2_pld_sa(struct iked *env, struct ikev2_payload *pld,
struct iked_proposals   *props;
size_t   total;
 
-   if (ikev2_validate_sa(msg, offset, left, ))
-   return (-1);
+   do {
+   if (ikev2_validate_sa(msg, offset, left, ))
+   return (-1);
 
-   if (sap.sap_more)
-   log_debug("%s: more than one proposal specified", __func__);
+   /* Assumed size of the first proposals, including SPI if 
present. */
+   total = (betoh16(sap.sap_length) - sizeof(sap));
 
-   /* Assumed size of the first proposals, including SPI if present. */
-   total = (betoh16(sap.sap_length) - sizeof(sap));
+   props = >msg_parent->msg_proposals;
 
-   props = >msg_parent->msg_proposals;
+   offset += sizeof(sap);
+   left -= sizeof(sap);
+
+   if (sap.sap_spisize) {
+   if (left < sap.sap_spisize) {
+   log_debug("%s: malformed payload: SPI larger 
than "
+   "actual payload (%zu < %d)", __func__, left,
+   sap.sap_spisize);
+   return (-1);
+   }
+   if (total < sap.sap_spisize) {
+   log_debug("%s: malformed payload: SPI larger 
than "
+   "proposal (%zu < %d)", __func__, total,
+   sap.sap_spisize);
+   return (-1);
+   }
+   switch (sap.sap_spisize) {
+   case 4:
+   memcpy(, msgbuf + offset, 4);
+   spi = betoh32(spi32);
+   break;
+   case 8:
+   memcpy(, msgbuf + offset, 8);
+   spi = betoh64(spi64);
+   break;
+   default:
+   log_debug("%s: unsupported SPI size %d",
+   __func__, sap.sap_spisize);
+   return (-1);
+   }
 
-   offset += sizeof(sap);
-   left -= sizeof(sap);
+   offset += sap.sap_spisize;
+   left -= sap.sap_spisize;
 
-   if (sap.sap_spisize) {
-   if (left < sap.sap_spisize) {
-   log_debug("%s: malformed payload: SPI larger than "
-   "actual payload (%zu < %d)", __func__, left,
-   sap.sap_spisize);
-   return (-1);
-   }
-   if (total < sap.sap_spisize) {
-   log_debug("%s: malformed payload: SPI larger than "
-   "proposal (%zu < %d)", __func__, total,
-   sap.sap_spisize);
-   return (-1);
+   /* Assumed size of the proposal, now without SPI. */
+   total -= sap.sap_spisize;
}
-   switch (sap.sap_spisize) {
-   case 4:
-   memcpy(, msgbuf + offset, 4);
-   spi = betoh32(spi32);
-   break;
-   case 8:
-   memcpy(, msgbuf + offset, 8);
-   spi = betoh64(spi64);
-   break;
-   default:
-   log_debug("%s: unsupported SPI size %d",
-   __func__, sap.sap_spisize);
+
+   /*
+* As we verified sanity of packet headers, 

Re: pf neighbor discovery hop limit

[Job Snijders]

On Mon, Dec 04, 2017 at 02:55:16PM +0100, Alexander Bluhm wrote:
> RFC 4861 requires that all neighbor discovery packets have 255 in
> their IPv6 header hop limit field.  Let pf drop neighbor solicitation,
> neighbor advertisement, router solicitation, router advertisement,
> and redirect ICMP6 packets that do not comply.  This enforces that
> bogus packets cannot be routed when pf is enabled.
> 
> ok?

Wouldn't this be a duplicate of "if (ip6->ip6_hlim != 255)" checks done
in sys/netinet6/{icmp6,nd6_nbr,nd6_rtr}.c ?

Kind regards,

Job

iked: parse more than one proposal

[Patrick Wildt]

Hi,

this diff changes our SA payload parser to parse more than the first
proposal.  This allows us to select one of the peer's proposals (and not
only the first).  The xforms parser calls itself recursively without
limits, which I'm not sure is a good idea.  This diff uses a do {} while
for the proposal parser instead.  I'm not sure this is great, but I
think it's better than the recursive way.  I'd like to change the xforms
parser to do the same later on.

ok?

Patrick

diff --git a/sbin/iked/ikev2_pld.c b/sbin/iked/ikev2_pld.c
index f3e21c3a41c..fb599d1c080 100644
--- a/sbin/iked/ikev2_pld.c
+++ b/sbin/iked/ikev2_pld.c
@@ -326,10 +326,6 @@ ikev2_validate_sa(struct iked_message *msg, size_t offset, 
size_t left,
return (0);
 }
 
-/*
- * NB: This function parses both the SA header and the first proposal.
- * Additional proposals are ignored.
- */
 int
 ikev2_pld_sa(struct iked *env, struct ikev2_payload *pld,
 struct iked_message *msg, size_t offset, size_t left)
@@ -342,100 +338,102 @@ ikev2_pld_sa(struct iked *env, struct ikev2_payload 
*pld,
struct iked_proposals   *props;
size_t   total;
 
-   if (ikev2_validate_sa(msg, offset, left, ))
-   return (-1);
+   do {
+   if (ikev2_validate_sa(msg, offset, left, ))
+   return (-1);
 
-   if (sap.sap_more)
-   log_debug("%s: more than one proposal specified", __func__);
+   /* Assumed size of the first proposals, including SPI if 
present. */
+   total = (betoh16(sap.sap_length) - sizeof(sap));
 
-   /* Assumed size of the first proposals, including SPI if present. */
-   total = (betoh16(sap.sap_length) - sizeof(sap));
+   props = >msg_parent->msg_proposals;
 
-   props = >msg_parent->msg_proposals;
+   offset += sizeof(sap);
+   left -= sizeof(sap);
+
+   if (sap.sap_spisize) {
+   if (left < sap.sap_spisize) {
+   log_debug("%s: malformed payload: SPI larger 
than "
+   "actual payload (%zu < %d)", __func__, left,
+   sap.sap_spisize);
+   return (-1);
+   }
+   if (total < sap.sap_spisize) {
+   log_debug("%s: malformed payload: SPI larger 
than "
+   "proposal (%zu < %d)", __func__, total,
+   sap.sap_spisize);
+   return (-1);
+   }
+   if (total < sap.sap_spisize) {
+   log_debug("%s: malformed payload: SPI too large 
"
+   "(%zu < %d)", __func__, total, 
sap.sap_spisize);
+   return (-1);
+   }
+   switch (sap.sap_spisize) {
+   case 4:
+   memcpy(, msgbuf + offset, 4);
+   spi = betoh32(spi32);
+   break;
+   case 8:
+   memcpy(, msgbuf + offset, 8);
+   spi = betoh64(spi64);
+   break;
+   default:
+   log_debug("%s: unsupported SPI size %d",
+   __func__, sap.sap_spisize);
+   return (-1);
+   }
 
-   offset += sizeof(sap);
-   left -= sizeof(sap);
+   offset += sap.sap_spisize;
+   left -= sap.sap_spisize;
 
-   if (sap.sap_spisize) {
-   if (left < sap.sap_spisize) {
-   log_debug("%s: malformed payload: SPI larger than "
-   "actual payload (%zu < %d)", __func__, left,
-   sap.sap_spisize);
-   return (-1);
-   }
-   if (total < sap.sap_spisize) {
-   log_debug("%s: malformed payload: SPI larger than "
-   "proposal (%zu < %d)", __func__, total,
-   sap.sap_spisize);
-   return (-1);
+   /* Assumed size of the proposal, now without SPI. */
+   total -= sap.sap_spisize;
}
-   if (total < sap.sap_spisize) {
-   log_debug("%s: malformed payload: SPI too large "
-   "(%zu < %d)", __func__, total, sap.sap_spisize);
-   return (-1);
-   }
-   switch (sap.sap_spisize) {
-   case 4:
-   memcpy(, msgbuf + offset, 4);
-   spi = betoh32(spi32);
-   break;
-   case 

__cxa_thread_atexit

[Mark Kettenis]

The ld.so bits have been committed last week.  So here is a new
version of the diff.  This version exports __cxa_thread_atexit_impl
such that gcc picks up our implementation.  __cxa_thread_atexit
becomes a weak alias such that static linking succeeds.  I rebuilt the
gcc 4.9 port with this diff and verified that it does indeed run the
new code.

ok?  anybody who wants to ride the libc minor bump?


Index: lib/libc/Symbols.list
===
RCS file: /cvs/src/lib/libc/Symbols.list,v
retrieving revision 1.61
diff -u -p -r1.61 Symbols.list
--- lib/libc/Symbols.list   4 Nov 2017 22:53:57 -   1.61
+++ lib/libc/Symbols.list   4 Dec 2017 19:04:51 -
@@ -1466,6 +1466,8 @@ random
 /* stdlib */
 _Exit
 __cxa_atexit
+__cxa_thread_atexit
+__cxa_thread_atexit_impl
 __cxa_finalize
 __isthreaded
 a64l
Index: lib/libc/shlib_version
===
RCS file: /cvs/src/lib/libc/shlib_version,v
retrieving revision 1.195
diff -u -p -r1.195 shlib_version
--- lib/libc/shlib_version  4 Nov 2017 22:53:57 -   1.195
+++ lib/libc/shlib_version  4 Dec 2017 19:04:51 -
@@ -1,4 +1,4 @@
 major=92
-minor=0
+minor=1
 # note: If changes were made to include/thread_private.h or if system
 # calls were added/changed then librthread/shlib_version also be updated.
Index: lib/libc/include/thread_private.h
===
RCS file: /cvs/src/lib/libc/include/thread_private.h,v
retrieving revision 1.32
diff -u -p -r1.32 thread_private.h
--- lib/libc/include/thread_private.h   4 Nov 2017 22:53:57 -   1.32
+++ lib/libc/include/thread_private.h   4 Dec 2017 19:04:52 -
@@ -394,6 +394,7 @@ void_spinunlock(volatile _atomic_lock_t
 void   _rthread_debug(int, const char *, ...)
__attribute__((__format__ (printf, 2, 3)));
 pid_t  _thread_dofork(pid_t (*_sys_fork)(void));
+void   _thread_finalize(void);
 
 /*
  * Threading syscalls not declared in system headers
Index: lib/libc/stdlib/atexit.c
===
RCS file: /cvs/src/lib/libc/stdlib/atexit.c,v
retrieving revision 1.24
diff -u -p -r1.24 atexit.c
--- lib/libc/stdlib/atexit.c10 Nov 2015 04:14:03 -  1.24
+++ lib/libc/stdlib/atexit.c4 Dec 2017 19:04:52 -
@@ -31,12 +31,24 @@
 
 #include 
 #include 
+#include 
+#include 
+#pragma weak _DYNAMIC
 #include 
 #include 
 #include 
 #include "atexit.h"
 #include "atfork.h"
 #include "thread_private.h"
+#include "tib.h"
+
+typeof(dlctl) dlctl asm("_dlctl") __attribute__((weak));
+
+struct thread_atexit_fn {
+   void (*func)(void *);
+   void *arg;
+   struct thread_atexit_fn *next;
+};
 
 struct atexit *__atexit;
 static int restartloop;
@@ -121,6 +133,45 @@ atexit(void (*fn)(void))
 }
 DEF_STRONG(atexit);
 
+__weak_alias(__cxa_thread_atexit, __cxa_thread_atexit_impl);
+
+int
+__cxa_thread_atexit_impl(void (*func)(void *), void *arg, void *dso)
+{
+   struct thread_atexit_fn *fnp;
+   struct tib *tib = TIB_GET();
+
+   fnp = calloc(1, sizeof(struct thread_atexit_fn));
+   if (fnp == NULL)
+   return -1;
+
+#ifndef NO_PIC
+   if (_DYNAMIC)
+   dlctl(NULL, DL_REFERENCE, dso);
+#endif
+
+   fnp->func = func;
+   fnp->arg = arg;
+   fnp->next = tib->tib_atexit;
+   tib->tib_atexit = fnp;
+
+   return 0;
+}
+DEF_STRONG(__cxa_thread_atexit_impl);
+
+void
+_thread_finalize(void)
+{
+   struct tib *tib = TIB_GET();
+
+   while (tib->tib_atexit) {
+   struct thread_atexit_fn *fnp = tib->tib_atexit;
+   tib->tib_atexit = fnp->next;
+   fnp->func(fnp->arg);
+   free(fnp);
+   }
+}
+
 /*
  * Call all handlers registered with __cxa_atexit() for the shared
  * object owning 'dso'.
@@ -133,6 +184,9 @@ __cxa_finalize(void *dso)
struct atexit_fn fn;
int n, pgsize = getpagesize();
static int call_depth;
+
+   if (dso == NULL)
+   _thread_finalize();
 
_ATEXIT_LOCK();
call_depth++;
Index: lib/libc/stdlib/atexit.h
===
RCS file: /cvs/src/lib/libc/stdlib/atexit.h,v
retrieving revision 1.10
diff -u -p -r1.10 atexit.h
--- lib/libc/stdlib/atexit.h25 Oct 2015 18:01:24 -  1.10
+++ lib/libc/stdlib/atexit.h4 Dec 2017 19:04:52 -
@@ -46,7 +46,9 @@ extern struct atexit *__atexit;   /* poin
 __END_HIDDEN_DECLS
 
 int__cxa_atexit(void (*)(void *), void *, void *);
+int__cxa_thread_atexit(void (*)(void *), void *, void *);
 void   __cxa_finalize(void *);
 
 PROTO_NORMAL(__cxa_atexit);
+PROTO_STD_DEPRECATED(__cxa_thread_atexit);
 PROTO_NORMAL(__cxa_finalize);
Index: lib/libc/thread/rthread.c
===
RCS file: /cvs/src/lib/libc/thread/rthread.c,v

Re: ddb(4) userland trace and SMAP

[Mike Larkin]

On Mon, Dec 04, 2017 at 12:24:00PM +0100, Martin Pieuchot wrote:
> Since SMAP is enabled ddb(4)'s 'trace /u' and 'trace /p' for a userland
> processes result, as expected, in page faults.
> 
> Diff below disable SMAP for the duration of the command.  This allows us
> to see any possible frame corruption.
> 
> ok?
> 

This looks ok to me.

-ml

> Index: arch/amd64/amd64/db_trace.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/db_trace.c,v
> retrieving revision 1.36
> diff -u -p -r1.36 db_trace.c
> --- arch/amd64/amd64/db_trace.c   3 Nov 2017 11:29:46 -   1.36
> +++ arch/amd64/amd64/db_trace.c   4 Dec 2017 10:42:42 -
> @@ -169,6 +169,7 @@ db_stack_trace_print(db_expr_t addr, boo
>   struct callframe *frame, *lastframe;
>   unsigned long   *argp, *arg0;
>   db_addr_t   callpc;
> + unsigned intcr4save;
>   int is_trap = 0;
>   boolean_t   kernel_only = TRUE;
>   boolean_t   trace_proc = FALSE;
> @@ -185,6 +186,10 @@ db_stack_trace_print(db_expr_t addr, boo
>   }
>   }
>  
> + cr4save = rcr4();
> + if (cr4save & CR4_SMAP)
> + lcr4(cr4save & ~CR4_SMAP);
> +
>   if (!have_addr) {
>   frame = (struct callframe *)ddb_regs.tf_rbp;
>   callpc = (db_addr_t)ddb_regs.tf_rip;
> @@ -193,7 +198,7 @@ db_stack_trace_print(db_expr_t addr, boo
>   struct proc *p = tfind((pid_t)addr);
>   if (p == NULL) {
>   (*pr) ("not found\n");
> - return;
> + goto out;
>   }
>   frame = (struct callframe *)p->p_addr->u_pcb.pcb_rbp;
>   } else {
> @@ -212,8 +217,13 @@ db_stack_trace_print(db_expr_t addr, boo
>   db_expr_t   offset;
>   Elf_Sym *   sym;
>  
> - sym = db_search_symbol(callpc, DB_STGY_ANY, );
> - db_symbol_values(sym, , NULL);
> + if (INKERNEL(frame)) {
> + sym = db_search_symbol(callpc, DB_STGY_ANY, );
> + db_symbol_values(sym, , NULL);
> + } else {
> + sym = NULL;
> + name = NULL;
> + }
>  
>   if (lastframe == 0 && sym == NULL) {
>   /* Symbol not found, peek at code */
> @@ -332,6 +342,9 @@ db_stack_trace_print(db_expr_t addr, boo
>   db_printsym(callpc, DB_STGY_XTRN, pr);
>   (*pr)(":\n");
>   }
> +
> +out:
> + lcr4(cr4save);
>  }
>  
>  void
> Index: arch/i386/i386/db_trace.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/db_trace.c,v
> retrieving revision 1.31
> diff -u -p -r1.31 db_trace.c
> --- arch/i386/i386/db_trace.c 3 Nov 2017 11:29:46 -   1.31
> +++ arch/i386/i386/db_trace.c 4 Dec 2017 11:18:38 -
> @@ -184,9 +184,9 @@ db_stack_trace_print(db_expr_t addr, boo
>   struct callframe *frame, *lastframe;
>   int *argp, *arg0;
>   db_addr_t   callpc;
> + unsigned intcr4save;
>   int is_trap = 0;
>   boolean_t   kernel_only = TRUE;
> - boolean_t   trace_thread = FALSE;
>   boolean_t   trace_proc = FALSE;
>  
>   {
> @@ -194,8 +194,6 @@ db_stack_trace_print(db_expr_t addr, boo
>   char c;
>  
>   while ((c = *cp++) != 0) {
> - if (c == 't')
> - trace_thread = TRUE;
>   if (c == 'p')
>   trace_proc = TRUE;
>   if (c == 'u')
> @@ -206,16 +204,18 @@ db_stack_trace_print(db_expr_t addr, boo
>   if (count == -1)
>   count = 65535;
>  
> + cr4save = rcr4();
> + if (cr4save & CR4_SMAP)
> + lcr4(cr4save & ~CR4_SMAP);
> +
>   if (!have_addr) {
>   frame = (struct callframe *)ddb_regs.tf_ebp;
>   callpc = (db_addr_t)ddb_regs.tf_eip;
> - } else if (trace_thread) {
> - (*pr) ("%s: can't trace thread\n", __func__);
>   } else if (trace_proc) {
>   struct proc *p = tfind((pid_t)addr);
>   if (p == NULL) {
>   (*pr) ("not found\n");
> - return;
> + goto out;
>   }
>   frame = (struct callframe *)p->p_addr->u_pcb.pcb_ebp;
>   callpc = (db_addr_t)
> @@ -233,8 +233,13 @@ db_stack_trace_print(db_expr_t addr, boo
>   db_expr_t   offset;
>   Elf_Sym *sym;
>  
> - sym = db_search_symbol(callpc, DB_STGY_ANY, );
> - db_symbol_values(sym, , NULL);
> + if (INKERNEL(frame)) {
> + sym = db_search_symbol(callpc, DB_STGY_ANY, );
> + 

Re: pf neighbor discovery hop limit

[Alexandr Nedvedicky]

Hello,


On Mon, Dec 04, 2017 at 02:55:16PM +0100, Alexander Bluhm wrote:
> Hi,
> 
> RFC 4861 requires that all neighbor discovery packets have 255 in
> their IPv6 header hop limit field.  Let pf drop neighbor solicitation,
> neighbor advertisement, router solicitation, router advertisement,
> and redirect ICMP6 packets that do not comply.  This enforces that
> bogus packets cannot be routed when pf is enabled.
> 
> ok?

yes please.

OK sashan

Re: mess with regression tests

[Alexander Bluhm]

On Mon, Dec 04, 2017 at 04:56:49PM +0100, Sebastian Benoit wrote:
> > connected to the Makefile in a source directory, tests looks broken.
> > 
> > - lib/libexpat/tests/
> 
> (2), but regress/lib/libexpat exists

I update the libexpat tests together with libexpat sources, so they
reside in src/lib/libexpat.  In regress/lib/libexpat I have placed
bsd.regress.mk compatible scripts that run them regularly.

I would recomment this also for other tests imported from upstream.

bluhm

Re: Reported problem: postfix, libressl 2.6.x, DHE-RSA-AES256-SHA

[Giovanni Bechis]

On 12/04/17 17:39, Giovanni Bechis wrote:
> On 12/04/17 17:27, Joel Sing wrote:
>> On Monday 04 December 2017 13:19:41 Giovanni Bechis wrote:
>>> On 11/10/17 17:46, Joel Sing wrote:
>>> [...]
>>>
 I suspect this is going to be difficult to track down without being able
 to see what is on the wire (tcpdump or 'smtpd_tls_loglevel = 3' in
 postfix) or being able to reproduce/trigger TLS sessions from the client.
>>>
>>> postfix log file with 'smtpd_tls_loglevel = 3' attached.
>>>  Thanks & Cheers
>>>   Giovanni
>>
>> Looking at this more closely, it is actually a different problem from the
>> originally reported issue (wrong version number):
>>
>> Dec  4 13:09:30 thor postfix/smtpd[91646]: connect from 
>> sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: setting up TLS connection from 
>> sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: 
>> sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]: TLS cipher list 
>> "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:before/accept 
>> initialization
>> ...
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 read client 
>> hello B
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write server 
>> hello A
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write 
>> certificate A
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write key 
>> exchange A
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write server 
>> done A
>> ...
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 flush data
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 read client 
>> certificate A
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: read from 4F66840F900 
>> [4F6048AA003] (5 bytes => -1 (0x))
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: read from 4F66840F900 
>> [4F6048AA003] (5 bytes => 5 (0x5))
>> Dec  4 13:09:31 thor postfix/smtpd[91646]:  15 03 03 00 02   
>> .
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: read from 4F66840F900 
>> [4F6048AA008] (2 bytes => 2 (0x2))
>> Dec  4 13:09:31 thor postfix/smtpd[91646]:  02 2e
>> ..
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL3 alert read:fatal:certificate 
>> unknown
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:failed in SSLv3 read 
>> client key exchange A
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept error from 
>> sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]: 0
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: warning: TLS library problem: 
>> error:14037416:SSL routines:ACCEPT_SR_KEY_EXCH:sslv3 alert certificate 
>> unknown:/usr/src/lib/libssl/ssl_pkt.c:1205:SSL alert number 46:
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: lost connection after STARTTLS 
>> from sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]
>> Dec  4 13:09:31 thor postfix/smtpd[91646]: disconnect from 
>> sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42] ehlo=1 starttls=0/1 
>> commands=1/2
>>
>> In this case the client hello has been received and the server
>> hello/certificate/key exchange/done has been sent, before the other side
>> responds with a "certificate unknown" alert - this suggests that the TLS
>> client is actually expecting to do some form of certificate verification
>> and this is failing. 
>>
> I have both problems on my logs.
>  
first problem seems fixed with your patch, "certificate unknown" still exists.

>> Was this working prior to OpenBSD 6.2?
>>
> yep, it started failing after 6.2 upgrade.
> Anyway I will rebuild libssl and come back soon.
>  Cheers
>   Giovanni
> 

Re: Reported problem: postfix, libressl 2.6.x, DHE-RSA-AES256-SHA

[Giovanni Bechis]

On 12/04/17 17:27, Joel Sing wrote:
> On Monday 04 December 2017 13:19:41 Giovanni Bechis wrote:
>> On 11/10/17 17:46, Joel Sing wrote:
>> [...]
>>
>>> I suspect this is going to be difficult to track down without being able
>>> to see what is on the wire (tcpdump or 'smtpd_tls_loglevel = 3' in
>>> postfix) or being able to reproduce/trigger TLS sessions from the client.
>>
>> postfix log file with 'smtpd_tls_loglevel = 3' attached.
>>  Thanks & Cheers
>>   Giovanni
> 
> Looking at this more closely, it is actually a different problem from the
> originally reported issue (wrong version number):
> 
> Dec  4 13:09:30 thor postfix/smtpd[91646]: connect from 
> sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]
> Dec  4 13:09:31 thor postfix/smtpd[91646]: setting up TLS connection from 
> sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]
> Dec  4 13:09:31 thor postfix/smtpd[91646]: 
> sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]: TLS cipher list 
> "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:before/accept 
> initialization
> ...
> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 read client hello 
> B
> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write server 
> hello A
> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write certificate 
> A
> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write key 
> exchange A
> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write server done 
> A
> ...
> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 flush data
> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 read client 
> certificate A
> Dec  4 13:09:31 thor postfix/smtpd[91646]: read from 4F66840F900 
> [4F6048AA003] (5 bytes => -1 (0x))
> Dec  4 13:09:31 thor postfix/smtpd[91646]: read from 4F66840F900 
> [4F6048AA003] (5 bytes => 5 (0x5))
> Dec  4 13:09:31 thor postfix/smtpd[91646]:  15 03 03 00 02
>.
> Dec  4 13:09:31 thor postfix/smtpd[91646]: read from 4F66840F900 
> [4F6048AA008] (2 bytes => 2 (0x2))
> Dec  4 13:09:31 thor postfix/smtpd[91646]:  02 2e 
>..
> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL3 alert read:fatal:certificate 
> unknown
> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:failed in SSLv3 read 
> client key exchange A
> Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept error from 
> sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]: 0
> Dec  4 13:09:31 thor postfix/smtpd[91646]: warning: TLS library problem: 
> error:14037416:SSL routines:ACCEPT_SR_KEY_EXCH:sslv3 alert certificate 
> unknown:/usr/src/lib/libssl/ssl_pkt.c:1205:SSL alert number 46:
> Dec  4 13:09:31 thor postfix/smtpd[91646]: lost connection after STARTTLS 
> from sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]
> Dec  4 13:09:31 thor postfix/smtpd[91646]: disconnect from 
> sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42] ehlo=1 starttls=0/1 
> commands=1/2
> 
> In this case the client hello has been received and the server
> hello/certificate/key exchange/done has been sent, before the other side
> responds with a "certificate unknown" alert - this suggests that the TLS
> client is actually expecting to do some form of certificate verification
> and this is failing. 
>
I have both problems on my logs.
 
> Was this working prior to OpenBSD 6.2?
> 
yep, it started failing after 6.2 upgrade.
Anyway I will rebuild libssl and come back soon.
 Cheers
  Giovanni

Re: Reported problem: postfix, libressl 2.6.x, DHE-RSA-AES256-SHA

[Joel Sing]

On Monday 04 December 2017 13:19:41 Giovanni Bechis wrote:
> On 11/10/17 17:46, Joel Sing wrote:
> [...]
> 
> > I suspect this is going to be difficult to track down without being able
> > to see what is on the wire (tcpdump or 'smtpd_tls_loglevel = 3' in
> > postfix) or being able to reproduce/trigger TLS sessions from the client.
> 
> postfix log file with 'smtpd_tls_loglevel = 3' attached.
>  Thanks & Cheers
>   Giovanni

Looking at this more closely, it is actually a different problem from the
originally reported issue (wrong version number):

Dec  4 13:09:30 thor postfix/smtpd[91646]: connect from 
sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]
Dec  4 13:09:31 thor postfix/smtpd[91646]: setting up TLS connection from 
sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]
Dec  4 13:09:31 thor postfix/smtpd[91646]: 
sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]: TLS cipher list 
"aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:before/accept 
initialization
...
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 read client hello B
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write server hello A
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write certificate A
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write key exchange A
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write server done A
...
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 flush data
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 read client 
certificate A
Dec  4 13:09:31 thor postfix/smtpd[91646]: read from 4F66840F900 [4F6048AA003] 
(5 bytes => -1 (0x))
Dec  4 13:09:31 thor postfix/smtpd[91646]: read from 4F66840F900 [4F6048AA003] 
(5 bytes => 5 (0x5))
Dec  4 13:09:31 thor postfix/smtpd[91646]:  15 03 03 00 02  
 .
Dec  4 13:09:31 thor postfix/smtpd[91646]: read from 4F66840F900 [4F6048AA008] 
(2 bytes => 2 (0x2))
Dec  4 13:09:31 thor postfix/smtpd[91646]:  02 2e   
 ..
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL3 alert read:fatal:certificate 
unknown
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:failed in SSLv3 read 
client key exchange A
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept error from 
sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]: 0
Dec  4 13:09:31 thor postfix/smtpd[91646]: warning: TLS library problem: 
error:14037416:SSL routines:ACCEPT_SR_KEY_EXCH:sslv3 alert certificate 
unknown:/usr/src/lib/libssl/ssl_pkt.c:1205:SSL alert number 46:
Dec  4 13:09:31 thor postfix/smtpd[91646]: lost connection after STARTTLS from 
sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]
Dec  4 13:09:31 thor postfix/smtpd[91646]: disconnect from 
sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42] ehlo=1 starttls=0/1 
commands=1/2

In this case the client hello has been received and the server
hello/certificate/key exchange/done has been sent, before the other side
responds with a "certificate unknown" alert - this suggests that the TLS
client is actually expecting to do some form of certificate verification
and this is failing. 

Was this working prior to OpenBSD 6.2?

Re: pf neighbor discovery hop limit

[Sebastian Benoit]

Alexander Bluhm(alexander.bl...@gmx.net) on 2017.12.04 14:55:16 +0100:
> Hi,
> 
> RFC 4861 requires that all neighbor discovery packets have 255 in
> their IPv6 header hop limit field.  Let pf drop neighbor solicitation,
> neighbor advertisement, router solicitation, router advertisement,
> and redirect ICMP6 packets that do not comply.  This enforces that
> bogus packets cannot be routed when pf is enabled.
> 
> ok?


ok benno@

we also check this in relevant spots in netinet6/ as far as i can see.

> bluhm
> 
> Index: net/pf.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/pf.c,v
> retrieving revision 1.1049
> diff -u -p -r1.1049 pf.c
> --- net/pf.c  1 Dec 2017 10:33:33 -   1.1049
> +++ net/pf.c  4 Dec 2017 13:53:21 -
> @@ -6602,6 +6602,14 @@ pf_setup_pdesc(struct pf_pdesc *pd, sa_f
>   case ND_NEIGHBOR_SOLICIT:
>   case ND_NEIGHBOR_ADVERT:
>   icmp_hlen = sizeof(struct nd_neighbor_solicit);
> + /* FALLTHROUGH */
> + case ND_ROUTER_SOLICIT:
> + case ND_ROUTER_ADVERT:
> + case ND_REDIRECT:
> + if (pd->ttl != 255) {
> + REASON_SET(reason, PFRES_NORM);
> + return (PF_DROP);
> + }
>   break;
>   }
>   if (icmp_hlen > sizeof(struct icmp6_hdr) &&
> 

Re: mess with regression tests

[Sebastian Benoit]

Sergey Bronnikov(serg...@bronevichok.ru) on 2017.12.02 15:31:21 +0300:
> Hello,
> 
> openbsd has a regression testuite in a base tree. Testset for each
> component is in a separate directory, Makefiles for each testsuite uses
> bsd.regress.mk framework and connected to the root Makefile. So it is
> easy to run overall testsuite with 'make regress'.
> 
> But tests for some utilities are placed with sources and not linked to
> Makefiles. Looks like it is dead, unusable code and broken tests.

mostly two reasons:

(1) probably old like you describe.

(2) imported code, updated regularly. Removing them
makes updates harder.

> It means that no one never run these tests.
> I went through these abandoned tests:
> 
> - bin/ed/test

(1)
 
> connected to the Makefile in a source directory, tests looks broken.
> 
> - lib/libexpat/tests/

(2), but regress/lib/libexpat exists

> tests requires external unit testing framework (check).
> 
> - usr.bin/sed/TEST

(1), but regress/usr.bin/sed/ exists
 
> directory contains several tests, but there no infrustructure to run
> them and files with expected results. Moreover the same tests are
> present in regress/usr.bin/sed dir.
> 
> - gnu/usr.bin/binutils/gdb/testsuite

(2)
 
> test suite requires dejagnu package from ports, it is not connected to
> the Makefile in sources and tests have many fails (about a couple of
> hundreds).
> 
> - usr.bin/m4/TEST

(2), but regress/usr.bin/m4/ exists

 
> dir contains examples of m4 files not tests,
> Makefile is absent.
> 
> Similar situation with these tests:
> 
> - gnu/usr.bin/gcc/gcc/testsuite

(2), even if we dont update it anymore

> - usr.bin/ctags/test
> - lib/libssl/test

previously (2)

> - lib/libkeynote/testsuite
> 
> Are there real reasons to keep these tests separately?

the ones marked (2) should probably be kept, removing them makes the diff to
upstream larger without any gain.

For all of them, you are invited to submit new tests based on the regress/
framework or update existing ones if there are any.

Re: Reported problem: postfix, libressl 2.6.x, DHE-RSA-AES256-SHA

[Joel Sing]

On Monday 04 December 2017 15:54:35 Giovanni Bechis wrote:
> On 12/04/17 13:19, Giovanni Bechis wrote:
> > On 11/10/17 17:46, Joel Sing wrote:
> > [...]
> > 
> >> I suspect this is going to be difficult to track down without being able
> >> to see what is on the wire (tcpdump or 'smtpd_tls_loglevel = 3' in
> >> postfix) or being able to reproduce/trigger TLS sessions from the
> >> client.
> > 
> > postfix log file with 'smtpd_tls_loglevel = 3' attached.
> > 
> >  Thanks & Cheers
> >  
> >   Giovanni
> 
> dmesg(8) attached, running postfix-3.2.2 on 6.2, latest postfix version does
> not fix the problem. Giovanni

Thanks - Eric Elena was able to provide a packet capture, resulting in an 
issue being found and fixed in libssl. This has already been committed to -
current and the backport should hopefully be committed to 6.2 soon:

https://marc.info/?l=libressl=151188863421496=2

Re: Reported problem: postfix, libressl 2.6.x, DHE-RSA-AES256-SHA

[Giovanni Bechis]

On 12/04/17 13:19, Giovanni Bechis wrote:
> On 11/10/17 17:46, Joel Sing wrote:
> [...]
>> I suspect this is going to be difficult to track down without being able to 
>> see
>> what is on the wire (tcpdump or 'smtpd_tls_loglevel = 3' in postfix) or being
>> able to reproduce/trigger TLS sessions from the client.
>>
> postfix log file with 'smtpd_tls_loglevel = 3' attached.
>  Thanks & Cheers
>   Giovanni
> 
dmesg(8) attached, running postfix-3.2.2 on 6.2, latest postfix version does 
not fix the problem.
 Giovanni
Nov 27 22:37:17 thor /bsd: OpenBSD 6.2 (GENERIC) #132: Tue Oct  3 21:18:21 MDT 2017
Nov 27 22:37:17 thor /bsd: dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
Nov 27 22:37:17 thor /bsd: real mem = 4278124544 (4079MB)
Nov 27 22:37:17 thor /bsd: avail mem = 4141531136 (3949MB)
Nov 27 22:37:17 thor /bsd: mpath0 at root
Nov 27 22:37:17 thor /bsd: scsibus0 at mpath0: 256 targets
Nov 27 22:37:17 thor /bsd: mainbus0 at root
Nov 27 22:37:17 thor /bsd: bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (556 entries)
Nov 27 22:37:17 thor /bsd: bios0: vendor Phoenix Technologies LTD version "6.00" date 09/21/2015
Nov 27 22:37:17 thor /bsd: bios0: VMware, Inc. VMware Virtual Platform
Nov 27 22:37:17 thor /bsd: acpi0 at bios0: rev 2
Nov 27 22:37:17 thor /bsd: acpi0: sleep states S0 S1 S4 S5
Nov 27 22:37:17 thor /bsd: acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
Nov 27 22:37:17 thor /bsd: acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) S1F0(S3) PE50(S3) [...]
Nov 27 22:37:17 thor /bsd: acpitimer0 at acpi0: 3579545 Hz, 24 bits
Nov 27 22:37:17 thor /bsd: acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
Nov 27 22:37:17 thor /bsd: cpu0 at mainbus0: apid 0 (boot processor)
Nov 27 22:37:17 thor /bsd: cpu0: AMD Opteron(tm) Processor 4386, 3100.69 MHz
Nov 27 22:37:17 thor /bsd: cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,F16C,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,XOP,FMA4,TBM,ITSC,BMI1
Nov 27 22:37:17 thor /bsd: cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 6MB 64b/line 64-way L3 cache
Nov 27 22:37:17 thor /bsd: cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
Nov 27 22:37:17 thor /bsd: cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
Nov 27 22:37:17 thor /bsd: cpu0: TSC frequency 3100692370 Hz
Nov 27 22:37:17 thor /bsd: mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
Nov 27 22:37:17 thor /bsd: cpu0: apic clock running at 65MHz
Nov 27 22:37:17 thor /bsd: ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
Nov 27 22:37:17 thor /bsd: acpimcfg0 at acpi0 addr 0xf000, bus 0-127
Nov 27 22:37:17 thor /bsd: acpihpet0 at acpi0: 14318179 Hz
Nov 27 22:37:17 thor /bsd: acpiprt0 at acpi0: bus 0 (PCI0)
Nov 27 22:37:17 thor /bsd: acpicpu0 at acpi0: C1(@1 halt!)
Nov 27 22:37:17 thor /bsd: "PNP0001" at acpi0 not configured
Nov 27 22:37:17 thor /bsd: "PNP0F13" at acpi0 not configured
Nov 27 22:37:17 thor /bsd: "PNP0A05" at acpi0 not configured
Nov 27 22:37:17 thor /bsd: "PNP0700" at acpi0 not configured
Nov 27 22:37:17 thor /bsd: acpiac0 at acpi0: AC unit online
Nov 27 22:37:17 thor /bsd: pvbus0 at mainbus0: VMware
Nov 27 22:37:17 thor /bsd: vmt0 at pvbus0
Nov 27 22:37:17 thor /bsd: pci0 at mainbus0 bus 0
Nov 27 22:37:17 thor /bsd: pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01
Nov 27 22:37:17 thor /bsd: ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01
Nov 27 22:37:17 thor /bsd: pci1 at ppb0 bus 1
Nov 27 22:37:17 thor /bsd: pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08
Nov 27 22:37:17 thor /bsd: pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility
Nov 27 22:37:17 thor /bsd: pciide0: channel 0 disabled (no drives)
Nov 27 22:37:17 thor /bsd: atapiscsi0 at pciide0 channel 1 drive 0
Nov 27 22:37:17 thor /bsd: scsibus1 at atapiscsi0: 2 targets
Nov 27 22:37:17 thor /bsd: cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom removable
Nov 27 22:37:17 thor /bsd: cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
Nov 27 22:37:17 thor /bsd: piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x08: SMBus disabled
Nov 27 22:37:17 thor /bsd: "VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured
Nov 27 22:37:17 thor /bsd: vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00
Nov 27 22:37:17 thor /bsd: wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
Nov 27 22:37:17 thor /bsd: wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
Nov 27 22:37:17 thor /bsd: mpi0 at pci0 dev 16 function 0 "Symbios Logic 53c1030" rev 0x01: apic 1 int 17

sb_flags vs sb_flagsintr

[Martin Pieuchot]

Diff below change the usage of `sb_flags' and `sb_flagsintr'.  The
former will be protected by the socket lock while the latter will
be using atomic operations.

- SB_SPLICE and SB_WAIT are always manipulated with solock() held, so
  move them to sb_flags.
- SB_SEL is also in the same case, although we might want to move it
  to sb_flagsintr later.
- SB_KNOTE remains the only bit set on sb_flagsintr.  Using atomic
  operation in this case should prevent us from sleeping in kevent(2)
  filters.

The diff below also includes some KERNEL_LOCK()/UNLOCK() dances around
selwakeup() and csignal().  These are currently no-op but mark which
functions need to be fixed to unlock the socket layer.

fifo_poll() was missing a solock/unlock dance, it is also included
in the diff below.

ok?

Index: kern/uipc_socket.c
===
RCS file: /cvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.209
diff -u -p -r1.209 uipc_socket.c
--- kern/uipc_socket.c  23 Nov 2017 13:45:46 -  1.209
+++ kern/uipc_socket.c  4 Dec 2017 14:26:24 -
@@ -1054,9 +1054,9 @@ sorflush(struct socket *so)
aso.so_rcv = *sb;
memset(sb, 0, sizeof (*sb));
/* XXX - the memset stomps all over so_rcv */
-   if (aso.so_rcv.sb_flags & SB_KNOTE) {
+   if (aso.so_rcv.sb_flagsintr & SB_KNOTE) {
sb->sb_sel.si_note = aso.so_rcv.sb_sel.si_note;
-   sb->sb_flags = SB_KNOTE;
+   sb->sb_flagsintr = SB_KNOTE;
}
if (pr->pr_flags & PR_RIGHTS && pr->pr_domain->dom_dispose)
(*pr->pr_domain->dom_dispose)(aso.so_rcv.sb_mb);
@@ -1178,8 +1178,8 @@ sosplice(struct socket *so, int fd, off_
 * we sleep, the socket buffers are not marked as spliced yet.
 */
if (somove(so, M_WAIT)) {
-   so->so_rcv.sb_flagsintr |= SB_SPLICE;
-   sosp->so_snd.sb_flagsintr |= SB_SPLICE;
+   so->so_rcv.sb_flags |= SB_SPLICE;
+   sosp->so_snd.sb_flags |= SB_SPLICE;
}
 
  release:
@@ -1196,8 +1196,8 @@ sounsplice(struct socket *so, struct soc
 
task_del(sosplice_taskq, >so_splicetask);
timeout_del(>so_idleto);
-   sosp->so_snd.sb_flagsintr &= ~SB_SPLICE;
-   so->so_rcv.sb_flagsintr &= ~SB_SPLICE;
+   sosp->so_snd.sb_flags &= ~SB_SPLICE;
+   so->so_rcv.sb_flags &= ~SB_SPLICE;
so->so_sp->ssp_socket = sosp->so_sp->ssp_soback = NULL;
if (wakeup && soreadable(so))
sorwakeup(so);
@@ -1210,7 +1210,7 @@ soidle(void *arg)
int s;
 
s = solock(so);
-   if (so->so_rcv.sb_flagsintr & SB_SPLICE) {
+   if (so->so_rcv.sb_flags & SB_SPLICE) {
so->so_error = ETIMEDOUT;
sounsplice(so, so->so_sp->ssp_socket, 1);
}
@@ -1224,7 +1224,7 @@ sotask(void *arg)
int s;
 
s = solock(so);
-   if (so->so_rcv.sb_flagsintr & SB_SPLICE) {
+   if (so->so_rcv.sb_flags & SB_SPLICE) {
/*
 * We may not sleep here as sofree() and unsplice() may be
 * called from softnet interrupt context.  This would remove
@@ -1527,7 +1527,7 @@ sorwakeup(struct socket *so)
soassertlocked(so);
 
 #ifdef SOCKET_SPLICE
-   if (so->so_rcv.sb_flagsintr & SB_SPLICE) {
+   if (so->so_rcv.sb_flags & SB_SPLICE) {
/*
 * TCP has a sendbuffer that can handle multiple packets
 * at once.  So queue the stream a bit to accumulate data.
@@ -1555,7 +1555,7 @@ sowwakeup(struct socket *so)
soassertlocked(so);
 
 #ifdef SOCKET_SPLICE
-   if (so->so_snd.sb_flagsintr & SB_SPLICE)
+   if (so->so_snd.sb_flags & SB_SPLICE)
task_add(sosplice_taskq, >so_sp->ssp_soback->so_splicetask);
 #endif
sowakeup(so, >so_snd);
@@ -1871,9 +1871,10 @@ sogetopt(struct socket *so, int level, i
 void
 sohasoutofband(struct socket *so)
 {
-   KERNEL_ASSERT_LOCKED();
+   KERNEL_LOCK();
csignal(so->so_pgid, SIGURG, so->so_siguid, so->so_sigeuid);
selwakeup(>so_rcv.sb_sel);
+   KERNEL_UNLOCK();
 }
 
 int
@@ -1901,7 +1902,7 @@ soo_kqfilter(struct file *fp, struct kno
}
 
SLIST_INSERT_HEAD(>sb_sel.si_note, kn, kn_selnext);
-   sb->sb_flags |= SB_KNOTE;
+   sb->sb_flagsintr |= SB_KNOTE;
 
return (0);
 }
@@ -1915,7 +1916,7 @@ filt_sordetach(struct knote *kn)
 
SLIST_REMOVE(>so_rcv.sb_sel.si_note, kn, knote, kn_selnext);
if (SLIST_EMPTY(>so_rcv.sb_sel.si_note))
-   so->so_rcv.sb_flags &= ~SB_KNOTE;
+   so->so_rcv.sb_flagsintr &= ~SB_KNOTE;
 }
 
 int
@@ -1958,7 +1959,7 @@ filt_sowdetach(struct knote *kn)
 
SLIST_REMOVE(>so_snd.sb_sel.si_note, kn, knote, kn_selnext);
if (SLIST_EMPTY(>so_snd.sb_sel.si_note))
-   so->so_snd.sb_flags &= ~SB_KNOTE;
+   so->so_snd.sb_flagsintr &= ~SB_KNOTE;
 }
 
 int
Index: kern/sys_socket.c

pf neighbor discovery hop limit

[Alexander Bluhm]

Hi,

RFC 4861 requires that all neighbor discovery packets have 255 in
their IPv6 header hop limit field.  Let pf drop neighbor solicitation,
neighbor advertisement, router solicitation, router advertisement,
and redirect ICMP6 packets that do not comply.  This enforces that
bogus packets cannot be routed when pf is enabled.

ok?

bluhm

Index: net/pf.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/pf.c,v
retrieving revision 1.1049
diff -u -p -r1.1049 pf.c
--- net/pf.c1 Dec 2017 10:33:33 -   1.1049
+++ net/pf.c4 Dec 2017 13:53:21 -
@@ -6602,6 +6602,14 @@ pf_setup_pdesc(struct pf_pdesc *pd, sa_f
case ND_NEIGHBOR_SOLICIT:
case ND_NEIGHBOR_ADVERT:
icmp_hlen = sizeof(struct nd_neighbor_solicit);
+   /* FALLTHROUGH */
+   case ND_ROUTER_SOLICIT:
+   case ND_ROUTER_ADVERT:
+   case ND_REDIRECT:
+   if (pd->ttl != 255) {
+   REASON_SET(reason, PFRES_NORM);
+   return (PF_DROP);
+   }
break;
}
if (icmp_hlen > sizeof(struct icmp6_hdr) &&

Re: [patch] upon install of new operating system version, do not set root password to empty string

[Stefan Sperling]

On Sun, Dec 03, 2017 at 08:31:34AM +, Robert Peichaer wrote:
> This is the exact code, that is already in install.sub.
> So I don't understand this proposal.
> 
> -- 
> -=[rpe]=-

It's a joke diff only Mac users would have the capacity to understand.
See https://mobile.twitter.com/lemiorhan/status/935578694541770752

Re: [patch] upon install of new operating system version, do not set root password to empty string

[Rodrigo Mosconi]

2017-11-28 21:59 GMT-02:00 Ian Sutton :

> This is a highly theoretical and experimental mitigation which stops the
> root password on newly upgraded/installed systems from being an empty
> string. The thinking is that by not shipping an operating system with a
> known root password, certain classes of attacks involving logging into
> the root account might be avoided. I would like some feedback from the
> cryptography team as well as NIST finalists in order to better ascertain
> the implications of this behaviour.
>


I could install a system with empty root password, but with a ssh key

Re: Reported problem: postfix, libressl 2.6.x, DHE-RSA-AES256-SHA

[Giovanni Bechis]

On 11/10/17 17:46, Joel Sing wrote:
[...]
> I suspect this is going to be difficult to track down without being able to 
> see
> what is on the wire (tcpdump or 'smtpd_tls_loglevel = 3' in postfix) or being
> able to reproduce/trigger TLS sessions from the client.
> 
postfix log file with 'smtpd_tls_loglevel = 3' attached.
 Thanks & Cheers
  Giovanni
Dec  4 13:09:30 thor postfix/smtpd[91646]: connect from sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]
Dec  4 13:09:31 thor postfix/smtpd[91646]: setting up TLS connection from sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]
Dec  4 13:09:31 thor postfix/smtpd[91646]: sonic301-3.consmr.mail.bf2.yahoo.com[74.6.129.42]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:before/accept initialization
Dec  4 13:09:31 thor postfix/smtpd[91646]: read from 4F66840F900 [4F6048AA003] (5 bytes => -1 (0x))
Dec  4 13:09:31 thor postfix/smtpd[91646]: read from 4F66840F900 [4F6048AA003] (5 bytes => 5 (0x5))
Dec  4 13:09:31 thor postfix/smtpd[91646]:  16 03 03 00 8c   .
Dec  4 13:09:31 thor postfix/smtpd[91646]: read from 4F66840F900 [4F6048AA008] (140 bytes => 140 (0x8C))
Dec  4 13:09:31 thor postfix/smtpd[91646]:  01 00 00 88 03 03 5a 25|3a fb e2 b6 65 2b 26 2f  ..Z% :...e+&/
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0010 c4 71 53 e7 8f ea 47 a6|b9 e7 9b fb b2 83 12 1d  .qS...G. 
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0020 17 6c a2 ef b9 d1 00 00|1a c0 2f c0 30 c0 27 c0  .l.. ../.0.'.
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0030 28 c0 13 c0 14 c0 12 00|9c 00 9d 00 3c 00 3d 00  (... <.=.
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0040 2f 00 35 01 00 00 45 00|0a 00 16 00 14 00 17 00  /.5...E. 
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0050 18 00 19 00 09 00 0a 00|0b 00 0c 00 0d 00 0e 00   
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0060 16 00 0b 00 02 01 00 00|0d 00 1c 00 1a 06 03 06   
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0070 01 05 03 05 01 04 03 04|01 04 02 03 03 03 01 03   
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0080 02 02 03 02 01 02 02 ff|01 00 01  ...
Dec  4 13:09:31 thor postfix/smtpd[91646]: 008b - 
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 read client hello B
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write server hello A
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write certificate A
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write key exchange A
Dec  4 13:09:31 thor postfix/smtpd[91646]: SSL_accept:SSLv3 write server done A
Dec  4 13:09:31 thor postfix/smtpd[91646]: write to 4F66840F900 [4F67DA56000] (2106 bytes => 2106 (0x83A))
Dec  4 13:09:31 thor postfix/smtpd[91646]:  16 03 03 00 57 02 00 00|53 03 03 60 08 7d a5 74  W... S..`.}.t
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0010 47 f0 d6 ff 70 41 6c 84|14 5b a5 86 16 e2 a6 dd  G...pAl. .[..
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0020 42 30 22 44 8e 24 d5 fb|e4 f9 35 20 c8 d4 7b ce  B0"D.$.. ..5 ..{.
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0030 b1 3f f0 43 ee 20 fe 87|5e 5b 5b 8c 5d 97 65 b2  .?.C. .. ^[[.].e.
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0040 f5 ae a0 ef 92 bb fb f7|eb a4 bb 6d c0 2f 00 00   ...m./..
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0050 0b ff 01 00 01 00 00 0b|00 02 01 00 16 03 03 05   
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0060 7e 0b 00 05 7a 00 05 77|00 05 74 30 82 05 70 30  ~...z..w ..t0..p0
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0070 82 03 58 02 09 00 cf aa|ac f2 1d 5a 90 23 30 0d  ..X. ...Z.#0.
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0080 06 09 2a 86 48 86 f7 0d|01 01 0b 05 00 30 7a 31  ..*.H... .0z1
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0090 0b 30 09 06 03 55 04 06|13 02 49 54 31 0e 30 0c  .0...U.. ..IT1.0.
Dec  4 13:09:31 thor postfix/smtpd[91646]: 00a0 06 03 55 04 08 0c 05 49|74 61 6c 79 31 0d 30 0b  ..UI taly1.0.
Dec  4 13:09:31 thor postfix/smtpd[91646]: 00b0 06 03 55 04 07 0c 04 4a|65 73 69 31 13 30 11 06  ..UJ esi1.0..
Dec  4 13:09:31 thor postfix/smtpd[91646]: 00c0 03 55 04 0a 0c 0a 53 4e|42 20 53 2e 72 2e 6c 2e  .USN B S.r.l.
Dec  4 13:09:31 thor postfix/smtpd[91646]: 00d0 31 15 30 13 06 03 55 04|03 0c 0c 73 6d 74 70 73  1.0...U. ...smtps
Dec  4 13:09:31 thor postfix/smtpd[91646]: 00e0 2e 73 6e 62 2e 69 74 31|20 30 1e 06 09 2a 86 48  .snb.it1  0...*.H
Dec  4 13:09:31 thor postfix/smtpd[91646]: 00f0 86 f7 0d 01 09 01 16 11|70 6f 73 74 6d 61 73 74   postmast
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0100 65 72 40 73 6e 62 2e 69|74 30 1e 17 0d 31 35 30  er@snb.i t0...150
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0110 39 32 34 31 34 32 38 34|39 5a 17 0d 32 35 30 39  92414284 9Z..2509
Dec  4 13:09:31 thor postfix/smtpd[91646]: 0120 32 31 31 34 32 38 34 39|5a 30 7a 31 0b 30 09 06  

ddb(4) userland trace and SMAP

[Martin Pieuchot]

Since SMAP is enabled ddb(4)'s 'trace /u' and 'trace /p' for a userland
processes result, as expected, in page faults.

Diff below disable SMAP for the duration of the command.  This allows us
to see any possible frame corruption.

ok?

Index: arch/amd64/amd64/db_trace.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/db_trace.c,v
retrieving revision 1.36
diff -u -p -r1.36 db_trace.c
--- arch/amd64/amd64/db_trace.c 3 Nov 2017 11:29:46 -   1.36
+++ arch/amd64/amd64/db_trace.c 4 Dec 2017 10:42:42 -
@@ -169,6 +169,7 @@ db_stack_trace_print(db_expr_t addr, boo
struct callframe *frame, *lastframe;
unsigned long   *argp, *arg0;
db_addr_t   callpc;
+   unsigned intcr4save;
int is_trap = 0;
boolean_t   kernel_only = TRUE;
boolean_t   trace_proc = FALSE;
@@ -185,6 +186,10 @@ db_stack_trace_print(db_expr_t addr, boo
}
}
 
+   cr4save = rcr4();
+   if (cr4save & CR4_SMAP)
+   lcr4(cr4save & ~CR4_SMAP);
+
if (!have_addr) {
frame = (struct callframe *)ddb_regs.tf_rbp;
callpc = (db_addr_t)ddb_regs.tf_rip;
@@ -193,7 +198,7 @@ db_stack_trace_print(db_expr_t addr, boo
struct proc *p = tfind((pid_t)addr);
if (p == NULL) {
(*pr) ("not found\n");
-   return;
+   goto out;
}
frame = (struct callframe *)p->p_addr->u_pcb.pcb_rbp;
} else {
@@ -212,8 +217,13 @@ db_stack_trace_print(db_expr_t addr, boo
db_expr_t   offset;
Elf_Sym *   sym;
 
-   sym = db_search_symbol(callpc, DB_STGY_ANY, );
-   db_symbol_values(sym, , NULL);
+   if (INKERNEL(frame)) {
+   sym = db_search_symbol(callpc, DB_STGY_ANY, );
+   db_symbol_values(sym, , NULL);
+   } else {
+   sym = NULL;
+   name = NULL;
+   }
 
if (lastframe == 0 && sym == NULL) {
/* Symbol not found, peek at code */
@@ -332,6 +342,9 @@ db_stack_trace_print(db_expr_t addr, boo
db_printsym(callpc, DB_STGY_XTRN, pr);
(*pr)(":\n");
}
+
+out:
+   lcr4(cr4save);
 }
 
 void
Index: arch/i386/i386/db_trace.c
===
RCS file: /cvs/src/sys/arch/i386/i386/db_trace.c,v
retrieving revision 1.31
diff -u -p -r1.31 db_trace.c
--- arch/i386/i386/db_trace.c   3 Nov 2017 11:29:46 -   1.31
+++ arch/i386/i386/db_trace.c   4 Dec 2017 11:18:38 -
@@ -184,9 +184,9 @@ db_stack_trace_print(db_expr_t addr, boo
struct callframe *frame, *lastframe;
int *argp, *arg0;
db_addr_t   callpc;
+   unsigned intcr4save;
int is_trap = 0;
boolean_t   kernel_only = TRUE;
-   boolean_t   trace_thread = FALSE;
boolean_t   trace_proc = FALSE;
 
{
@@ -194,8 +194,6 @@ db_stack_trace_print(db_expr_t addr, boo
char c;
 
while ((c = *cp++) != 0) {
-   if (c == 't')
-   trace_thread = TRUE;
if (c == 'p')
trace_proc = TRUE;
if (c == 'u')
@@ -206,16 +204,18 @@ db_stack_trace_print(db_expr_t addr, boo
if (count == -1)
count = 65535;
 
+   cr4save = rcr4();
+   if (cr4save & CR4_SMAP)
+   lcr4(cr4save & ~CR4_SMAP);
+
if (!have_addr) {
frame = (struct callframe *)ddb_regs.tf_ebp;
callpc = (db_addr_t)ddb_regs.tf_eip;
-   } else if (trace_thread) {
-   (*pr) ("%s: can't trace thread\n", __func__);
} else if (trace_proc) {
struct proc *p = tfind((pid_t)addr);
if (p == NULL) {
(*pr) ("not found\n");
-   return;
+   goto out;
}
frame = (struct callframe *)p->p_addr->u_pcb.pcb_ebp;
callpc = (db_addr_t)
@@ -233,8 +233,13 @@ db_stack_trace_print(db_expr_t addr, boo
db_expr_t   offset;
Elf_Sym *sym;
 
-   sym = db_search_symbol(callpc, DB_STGY_ANY, );
-   db_symbol_values(sym, , NULL);
+   if (INKERNEL(frame)) {
+   sym = db_search_symbol(callpc, DB_STGY_ANY, );
+   db_symbol_values(sym, , NULL);
+   } else {
+   sym = NULL;
+   name = NULL;
+   }
 
if (lastframe == 0 && sym == NULL) {
  

dc(1): global context

[kshe]

Hi,

Separately allocating a new BN_CTX every time one is needed seems to be
missing the point of this object, which is meant to be shared across as
many function calls as possible.  At the cost of a slight increase in
average memory consumption, enabling such sharing by declaring a single
global context and using it everywhere yields a significant performance
gain, especially in the case of long sequences of simple and repetitive
operations, which can become up to 60% faster.

$ echo 1 >script
$ jot -b 1/ 1048576 >>script

$ time dc script
0m03.20s real 0m03.20s user 0m00.00s system
$ time ./dc script
0m01.25s real 0m01.25s user 0m00.00s system

Index: bcode.c
===
RCS file: /cvs/src/usr.bin/dc/bcode.c,v
retrieving revision 1.58
diff -u -p -r1.58 bcode.c
--- bcode.c 2 Dec 2017 12:43:18 -   1.58
+++ bcode.c 3 Dec 2017 07:06:47 -
@@ -133,6 +133,8 @@ struct jump_entry {
opcode_function f;
 };
 
+static BN_CTX *ctx;
+
 static opcode_function jump_table[UCHAR_MAX + 1];
 
 static const struct jump_entry jump_table_data[] = {
@@ -226,6 +228,9 @@ init_bmachine(bool extended_registers)
 {
int i;
 
+   ctx = BN_CTX_new();
+   bn_checkp(ctx);
+
bmachine.extended_regs = extended_registers;
bmachine.reg_array_size = bmachine.extended_regs ?
REG_ARRAY_SIZE_BIG : REG_ARRAY_SIZE_SMALL;
@@ -361,14 +366,11 @@ scale_number(BIGNUM *n, int s)
(void)BN_div_word(n, factors[abs_scale]);
} else {
BIGNUM *a, *p;
-   BN_CTX *ctx;
 
a = BN_new();
bn_checkp(a);
p = BN_new();
bn_checkp(p);
-   ctx = BN_CTX_new();
-   bn_checkp(ctx);
 
bn_check(BN_set_word(a, 10));
bn_check(BN_set_word(p, abs_scale));
@@ -377,7 +379,6 @@ scale_number(BIGNUM *n, int s)
bn_check(BN_mul(n, n, a, ctx));
else
bn_check(BN_div(n, NULL, n, a, ctx));
-   BN_CTX_free(ctx);
BN_free(a);
BN_free(p);
}
@@ -399,20 +400,16 @@ split_number(const struct number *n, BIG
bn_check(BN_set_word(f, rem));
} else {
BIGNUM *a, *p;
-   BN_CTX *ctx;
 
a = BN_new();
bn_checkp(a);
p = BN_new();
bn_checkp(p);
-   ctx = BN_CTX_new();
-   bn_checkp(ctx);
 
bn_check(BN_set_word(a, 10));
bn_check(BN_set_word(p, n->scale));
bn_check(BN_exp(a, a, p, ctx));
bn_check(BN_div(i, f, n->number, a, ctx));
-   BN_CTX_free(ctx);
BN_free(a);
BN_free(p);
}
@@ -699,7 +696,6 @@ static u_int
 count_digits(const struct number *n)
 {
BIGNUM  *int_part, *a, *p;
-   BN_CTX  *ctx;
uintd;
const uint64_t  c = 1292913986; /* floor(2^32 * log_10(2)) */
int bits;
@@ -724,8 +720,6 @@ count_digits(const struct number *n)
 
/* If close to a possible rounding error fix if needed */
if (d != (c * (bits - 1)) >> 32) {
-   ctx = BN_CTX_new();
-   bn_checkp(ctx);
a = BN_new();
bn_checkp(a);
p = BN_new();
@@ -738,7 +732,6 @@ count_digits(const struct number *n)
if (BN_ucmp(int_part, a) >= 0)
d++;
 
-   BN_CTX_free(ctx);
BN_free(a);
BN_free(p);
} else
@@ -1039,17 +1032,12 @@ bsub(void)
 void
 bmul_number(struct number *r, struct number *a, struct number *b, u_int scale)
 {
-   BN_CTX  *ctx;
-
/* Create copies of the scales, since r might be equal to a or b */
u_int ascale = a->scale;
u_int bscale = b->scale;
u_int rscale = ascale + bscale;
 
-   ctx = BN_CTX_new();
-   bn_checkp(ctx);
bn_check(BN_mul(r->number, a->number, b->number, ctx));
-   BN_CTX_free(ctx);
 
r->scale = rscale;
if (rscale > bmachine.scale && rscale > ascale && rscale > bscale)
@@ -1085,7 +1073,6 @@ bdiv(void)
struct number   *a, *b;
struct number   *r;
u_int   scale;
-   BN_CTX  *ctx;
 
a = pop_number();
if (a == NULL)
@@ -1106,10 +1093,7 @@ bdiv(void)
normalize(a, scale);
normalize(b, scale + r->scale);
 
-   ctx = BN_CTX_new();
-   bn_checkp(ctx);
bn_check(BN_div(r->number, NULL, b->number, a->number, ctx));
-   

Re: ddb: show panic on page fault

[Paul Irofti]

On Sun, Nov 05, 2017 at 02:48:59AM +0200, Paul Irofti wrote:
> On Sun, Nov 05, 2017 at 01:43:35AM +0100, Mark Kettenis wrote:
> > > Date: Sat, 4 Nov 2017 18:51:34 +0100
> > > From: Martin Pieuchot 
> > > 
> > > On 04/11/17(Sat) 17:20, Paul Irofti wrote:
> > > > Hi,
> > > > 
> > > > Someone, somewhere (perhaps on bugs@?) said they would like to see
> > > > something useful when typing show panic on a page fault'd kernel. That
> > > > struck very close to home so I went ahead and did it.
> > > > 
> > > > The following diff shows the uvm_fault and the first trace entry in an
> > > > attempt to mimic a real show panic. The uvm_fault entry is extra.
> > > > 
> > > > Currently I only wrote support for amd64 but I can add support for
> > > > other architectures if you guys like it.
> > > > 
> > > > Thoughts?
> > > 
> > > I think you should just change the printf("uvm_fault...) into a panic.
> > 
> > No.  That makes it a lot harder to investigate the faulting instruction.
> > 
> > I think Paul's idea makes sense; might need a bit of polishing though.
> 
> Good, we now have a direction. I am all ears about polishing the current diff.
> The construct is the same as that used for panicstr.

Ping! Should I commit this as is for you to polish later?