svn commit: r335466 - releng/11.1/sys/x86/xen

[Gordon Tetlow]

Author: gordon
Date: Thu Jun 21 05:18:08 2018
New Revision: 335466
URL: https://svnweb.freebsd.org/changeset/base/335466

Log:
  Fix TLB shootdown for Xen based guests. [EN-18:07.pmap]
  
  Approved by:  so
  Security: FreeBSD-EN-18:07.pmap

Modified:
  releng/11.1/sys/x86/xen/xen_apic.c

Modified: releng/11.1/sys/x86/xen/xen_apic.c
==
--- releng/11.1/sys/x86/xen/xen_apic.c  Thu Jun 21 05:17:13 2018
(r335465)
+++ releng/11.1/sys/x86/xen/xen_apic.c  Thu Jun 21 05:18:08 2018
(r335466)
@@ -41,6 +41,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -439,6 +440,46 @@ xen_invltlb_pcid(void *arg)
invltlb_pcid_handler();
return (FILTER_HANDLED);
 }
+
+static int
+xen_invltlb_invpcid_pti(void *arg)
+{
+
+   invltlb_invpcid_pti_handler();
+   return (FILTER_HANDLED);
+}
+
+static int
+xen_invlpg_invpcid_handler(void *arg)
+{
+
+   invlpg_invpcid_handler();
+   return (FILTER_HANDLED);
+}
+
+static int
+xen_invlpg_pcid_handler(void *arg)
+{
+
+   invlpg_pcid_handler();
+   return (FILTER_HANDLED);
+}
+
+static int
+xen_invlrng_invpcid_handler(void *arg)
+{
+
+   invlrng_invpcid_handler();
+   return (FILTER_HANDLED);
+}
+
+static int
+xen_invlrng_pcid_handler(void *arg)
+{
+
+   invlrng_pcid_handler();
+   return (FILTER_HANDLED);
+}
 #endif
 
 static int
@@ -529,8 +570,18 @@ xen_setup_cpus(void)
 
 #ifdef __amd64__
if (pmap_pcid_enabled) {
-   xen_ipis[IPI_TO_IDX(IPI_INVLTLB)].filter = invpcid_works ?
-   xen_invltlb_invpcid : xen_invltlb_pcid;
+   if (pti)
+   xen_ipis[IPI_TO_IDX(IPI_INVLTLB)].filter =
+   invpcid_works ? xen_invltlb_invpcid_pti :
+   xen_invltlb_pcid;
+   else
+   xen_ipis[IPI_TO_IDX(IPI_INVLTLB)].filter =
+   invpcid_works ? xen_invltlb_invpcid :
+   xen_invltlb_pcid;
+   xen_ipis[IPI_TO_IDX(IPI_INVLPG)].filter = invpcid_works ?
+   xen_invlpg_invpcid_handler : xen_invlpg_pcid_handler;
+   xen_ipis[IPI_TO_IDX(IPI_INVLRNG)].filter = invpcid_works ?
+   xen_invlrng_invpcid_handler : xen_invlrng_pcid_handler;
}
 #endif
CPU_FOREACH(i)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335465 - in releng/11.1: . sys/amd64/amd64 sys/conf sys/i386/i386 sys/i386/isa

[Gordon Tetlow]

Author: gordon
Date: Thu Jun 21 05:17:13 2018
New Revision: 335465
URL: https://svnweb.freebsd.org/changeset/base/335465

Log:
  Fix Lazy FPU information disclosure. [SA-18:07.lazyfpu]
  
  Bump newvers.sh and UPDATING for today's patches.
  
  Approved by:  so
  Security: CVE-2018-3665
  Security: FreeBSD-SA-18:07.lazyfpu
  Sponsored by: The FreeBSD Foundation

Modified:
  releng/11.1/UPDATING
  releng/11.1/sys/amd64/amd64/cpu_switch.S
  releng/11.1/sys/amd64/amd64/fpu.c
  releng/11.1/sys/conf/newvers.sh
  releng/11.1/sys/i386/i386/swtch.s
  releng/11.1/sys/i386/isa/npx.c

Modified: releng/11.1/UPDATING
==
--- releng/11.1/UPDATINGThu Jun 21 02:15:50 2018(r335464)
+++ releng/11.1/UPDATINGThu Jun 21 05:17:13 2018(r335465)
@@ -16,6 +16,13 @@ from older versions of FreeBSD, try WITHOUT_CLANG and 
 the tip of head, and then rebuild without this option. The bootstrap process
 from older version of current across the gcc/clang cutover is a bit fragile.
 
+20180621   p11 FreeBSD-SA-18:07.lazyfpu
+   FreeBSD-EN-18:07.pmap
+
+   Fix Lazy FPU information disclosure. [SA-18:07.lazyfpu]
+
+   Fix TLB shootdown for Xen based guests. [EN-18:07.pmap]
+
 20180508   p10 FreeBSD-SA-18:06.debugreg
FreeBSD-EN-18:05.mem
FreeBSD-EN-18:06.tzdata

Modified: releng/11.1/sys/amd64/amd64/cpu_switch.S
==
--- releng/11.1/sys/amd64/amd64/cpu_switch.SThu Jun 21 02:15:50 2018
(r335464)
+++ releng/11.1/sys/amd64/amd64/cpu_switch.SThu Jun 21 05:17:13 2018
(r335465)
@@ -105,10 +105,10 @@ done_store_dr:
 
/* have we used fp, and need a save? */
cmpq%rdi,PCPU(FPCURTHREAD)
-   jne 3f
+   jne 2f
movqPCB_SAVEFPU(%r8),%r8
clts
-   cmpl$0,use_xsave
+   cmpl$0,use_xsave(%rip)
jne 1f
fxsave  (%r8)
jmp 2f
@@ -120,12 +120,7 @@ ctx_switch_xsave:
/* This is patched to xsaveopt if supported, see fpuinit_bsp1() */
xsave   (%r8)
movq%rcx,%rdx
-2: smsw%ax
-   orb $CR0_TS,%al
-   lmsw%ax
-   xorl%eax,%eax
-   movq%rax,PCPU(FPCURTHREAD)
-3:
+2:
/* Save is done.  Now fire up new thread. Leave old vmspace. */
movq%rsi,%r12
movq%rdi,%r13
@@ -212,6 +207,8 @@ done_load_dr:
movqPCB_RBX(%r8),%rbx
movqPCB_RIP(%r8),%rax
movq%rax,(%rsp)
+   movqPCPU(CURTHREAD),%rdi
+   callfpu_activate_sw
ret
 
/*

Modified: releng/11.1/sys/amd64/amd64/fpu.c
==
--- releng/11.1/sys/amd64/amd64/fpu.c   Thu Jun 21 02:15:50 2018
(r335464)
+++ releng/11.1/sys/amd64/amd64/fpu.c   Thu Jun 21 05:17:13 2018
(r335465)
@@ -139,6 +139,11 @@ static voidfpu_clean_state(void);
 SYSCTL_INT(_hw, HW_FLOATINGPT, floatingpoint, CTLFLAG_RD,
 SYSCTL_NULL_INT_PTR, 1, "Floating point instructions executed in 
hardware");
 
+int lazy_fpu_switch = 0;
+SYSCTL_INT(_hw, OID_AUTO, lazy_fpu_switch, CTLFLAG_RWTUN | CTLFLAG_NOFETCH,
+_fpu_switch, 0,
+"Lazily load FPU context after context switch");
+
 int use_xsave; /* non-static for cpu_switch.S */
 uint64_t xsave_mask;   /* the same */
 static uma_zone_t fpu_save_area_zone;
@@ -204,6 +209,7 @@ fpuinit_bsp1(void)
u_int cp[4];
uint64_t xsave_mask_user;
 
+   TUNABLE_INT_FETCH("hw.lazy_fpu_switch", _fpu_switch);
if ((cpu_feature2 & CPUID2_XSAVE) != 0) {
use_xsave = 1;
TUNABLE_INT_FETCH("hw.use_xsave", _xsave);
@@ -611,6 +617,45 @@ fputrap_sse(void)
return (fpetable[(mxcsr & (~mxcsr >> 7)) & 0x3f]);
 }
 
+static void
+restore_fpu_curthread(struct thread *td)
+{
+   struct pcb *pcb;
+
+   /*
+* Record new context early in case frstor causes a trap.
+*/
+   PCPU_SET(fpcurthread, td);
+
+   stop_emulating();
+   fpu_clean_state();
+   pcb = td->td_pcb;
+
+   if ((pcb->pcb_flags & PCB_FPUINITDONE) == 0) {
+   /*
+* This is the first time this thread has used the FPU or
+* the PCB doesn't contain a clean FPU state.  Explicitly
+* load an initial state.
+*
+* We prefer to restore the state from the actual save
+* area in PCB instead of directly loading from
+* fpu_initialstate, to ignite the XSAVEOPT
+* tracking engine.
+*/
+   bcopy(fpu_initialstate, pcb->pcb_save,
+   cpu_max_ext_state_size);
+   fpurestore(pcb->pcb_save);
+   if (pcb->pcb_initial_fpucw != 

svn commit: r335464 - head

[Ed Maste]

Author: emaste
Date: Thu Jun 21 02:15:50 2018
New Revision: 335464
URL: https://svnweb.freebsd.org/changeset/base/335464

Log:
  Makefile.inc1: rename build metadata file to toolchain-metadata.mk
  
  The metadata file contains more than just compiler metadata.
  
  Discussed with:   bdrewery

Modified:
  head/Makefile.inc1

Modified: head/Makefile.inc1
==
--- head/Makefile.inc1  Thu Jun 21 01:22:35 2018(r335463)
+++ head/Makefile.inc1  Thu Jun 21 02:15:50 2018(r335464)
@@ -92,8 +92,8 @@ MK_GCC_BOOTSTRAP= no
 # running CC from bsd.compiler.mk.
 .if make(installworld) || make(install) || make(distributeworld) || \
 make(stageworld)
-.-include "${OBJTOP}/compiler-metadata.mk"
-.if !defined(_LOADED_COMPILER_METADATA)
+.-include "${OBJTOP}/toolchain-metadata.mk"
+.if !defined(_LOADED_TOOLCHAIN_METADATA)
 .error A build is required first.  You may have the wrong MAKEOBJDIRPREFIX set.
 .endif
 .endif
@@ -311,7 +311,7 @@ test-system-${_t}: .PHONY
 
 # Store some compiler metadata for use in installworld where we don't
 # want to invoke CC at all.
-_COMPILER_METADATA_VARS=   COMPILER_VERSION \
+_TOOLCHAIN_METADATA_VARS=  COMPILER_VERSION \
COMPILER_TYPE \
COMPILER_FEATURES \
COMPILER_FREEBSD_VERSION \
@@ -319,17 +319,17 @@ _COMPILER_METADATA_VARS=  COMPILER_VERSION \
LINKER_FEATURES \
LINKER_TYPE \
LINKER_FREEBSD_VERSION
-compiler-metadata.mk: .PHONY .META
+toolchain-metadata.mk: .PHONY .META
@: > ${.TARGET}
-   @echo ".info Using cached compiler metadata from build at $$(hostname) 
on $$(date)" \
+   @echo ".info Using cached toolchain metadata from build at $$(hostname) 
on $$(date)" \
> ${.TARGET}
-   @echo "_LOADED_COMPILER_METADATA=t" >> ${.TARGET}
-.for v in ${_COMPILER_METADATA_VARS}
+   @echo "_LOADED_TOOLCHAIN_METADATA=t" >> ${.TARGET}
+.for v in ${_TOOLCHAIN_METADATA_VARS}
@echo "${v}=${${v}}" >> ${.TARGET}
@echo "X_${v}=${X_${v}}" >> ${.TARGET}
 .endfor
-   @echo ".export ${_COMPILER_METADATA_VARS}" >> ${.TARGET}
-   @echo ".export ${_COMPILER_METADATA_VARS:C,^,X_,}" >> ${.TARGET}
+   @echo ".export ${_TOOLCHAIN_METADATA_VARS}" >> ${.TARGET}
+   @echo ".export ${_TOOLCHAIN_METADATA_VARS:C,^,X_,}" >> ${.TARGET}
 
 
 # We must do lib/ and libexec/ before bin/ in case of a mid-install error to
@@ -1015,7 +1015,7 @@ _cross-tools:
@echo "--"
@echo ">>> stage 3: cross tools"
@echo "--"
-   @rm -f ${OBJTOP}/compiler-metadata.mk
+   @rm -f ${OBJTOP}/toolchain-metadata.mk
${_+_}cd ${.CURDIR}; ${XMAKE} cross-tools
${_+_}cd ${.CURDIR}; ${XMAKE} kernel-tools
 _build-metadata:
@@ -1023,7 +1023,7 @@ _build-metadata:
@echo "--"
@echo ">>> stage 3.1: recording build metadata"
@echo "--"
-   ${_+_}cd ${.CURDIR}; ${WMAKE} compiler-metadata.mk
+   ${_+_}cd ${.CURDIR}; ${WMAKE} toolchain-metadata.mk
${_+_}cd ${.CURDIR}; ${WMAKE} host-osreldate.h
 _includes:
@echo
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335454 - head/usr.bin/ar

[Ed Maste]

On 20 June 2018 at 20:48, Rodney W. Grimes
 wrote:
>
> My claim still stands, the commit message and reality do not match,
> Ed claimed that he was switching to 2-clause FreeBSD license, yet
> it does not appear to actually do that.

The commit message could have been more clear indeed.

> Does SPDX have rules for dual tagging a file?  I seem to recall that
> there was some way to do that at least.

It does (using license1 AND/OR license2), but in this case one of the
licenses is a subset of the other.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335454 - head/usr.bin/ar

[Rodney W. Grimes]

> On 20/06/2018 17:42, Rodney W. Grimes wrote:
> >> Author: emaste
> >> Date: Wed Jun 20 18:43:17 2018
> >> New Revision: 335454
> >> URL: https://svnweb.freebsd.org/changeset/base/335454
> >>
> >> Log:
> >>usr.bin/ar: use standard 2-Clause FreeBSD license
> >>
> >>Many licenses on ar files contained small variations from the standard
> >>FreeBSD license text. To avoid license proliferation switch to the usual
> >>2-clause FreeBSD license after obtaining permission from all copyright
> >>holders.
> >>
> >>Approved by:jkoshy, kaiw, kientzle
> >>Sponsored by:   The FreeBSD Foundation
> >>Differential Revision:  https://reviews.freebsd.org/D14561
> >>
> >> Modified:
> >>head/usr.bin/ar/ar.c
> >>head/usr.bin/ar/read.c
> >>head/usr.bin/ar/util.c
> >>
> >> Modified: head/usr.bin/ar/ar.c
> >> ==
> >> --- head/usr.bin/ar/ar.c   Wed Jun 20 17:37:55 2018(r335453)
> >> +++ head/usr.bin/ar/ar.c   Wed Jun 20 18:43:17 2018(r335454)
> >> @@ -1,4 +1,6 @@
> >>   /*-
> >> + * SPDX-License-Identifier: BSD-3-Clause
> >> + *
> > I think there may be an error above, commit message says 2 clause,
> > license below appears to be 2 clause, yet above we have 3?
> Look at all the file: there are two licenses there.

My claim still stands, the commit message and reality do not match,
Ed claimed that he was switching to 2-clause FreeBSD license, yet
it does not appear to actually do that.  It further claims that
he obtained permission from ALL copyright holders, which also appears
to not be true, or he could of removed the 3 clause.

The dual license is an even bigger can of worms, as then technically this
file is neither BSD-2-Clause nor BSD-3-Clause, but some hybrid that has
to be treated specially.

Does SPDX have rules for dual tagging a file?  I seem to recall that
there was some way to do that at least.

I am unclear as to it even be legal or valid to have added the 2
clause license on top of the BSD 3 clause license.

> Pedro.

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335454 - head/usr.bin/ar

[Pedro Giffuni]

On 20/06/2018 17:42, Rodney W. Grimes wrote:

Author: emaste
Date: Wed Jun 20 18:43:17 2018
New Revision: 335454
URL: https://svnweb.freebsd.org/changeset/base/335454

Log:
   usr.bin/ar: use standard 2-Clause FreeBSD license
   
   Many licenses on ar files contained small variations from the standard

   FreeBSD license text. To avoid license proliferation switch to the usual
   2-clause FreeBSD license after obtaining permission from all copyright
   holders.
   
   Approved by:	jkoshy, kaiw, kientzle

   Sponsored by:The FreeBSD Foundation
   Differential Revision:   https://reviews.freebsd.org/D14561

Modified:
   head/usr.bin/ar/ar.c
   head/usr.bin/ar/read.c
   head/usr.bin/ar/util.c

Modified: head/usr.bin/ar/ar.c
==
--- head/usr.bin/ar/ar.cWed Jun 20 17:37:55 2018(r335453)
+++ head/usr.bin/ar/ar.cWed Jun 20 18:43:17 2018(r335454)
@@ -1,4 +1,6 @@
  /*-
+ * SPDX-License-Identifier: BSD-3-Clause
+ *

I think there may be an error above, commit message says 2 clause,
license below appears to be 2 clause, yet above we have 3?

Look at all the file: there are two licenses there.

Pedro.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335454 - head/usr.bin/ar

[Rodney W. Grimes]

> Author: emaste
> Date: Wed Jun 20 18:43:17 2018
> New Revision: 335454
> URL: https://svnweb.freebsd.org/changeset/base/335454
> 
> Log:
>   usr.bin/ar: use standard 2-Clause FreeBSD license
>   
>   Many licenses on ar files contained small variations from the standard
>   FreeBSD license text. To avoid license proliferation switch to the usual
>   2-clause FreeBSD license after obtaining permission from all copyright
>   holders.
>   
>   Approved by:jkoshy, kaiw, kientzle
>   Sponsored by:   The FreeBSD Foundation
>   Differential Revision:  https://reviews.freebsd.org/D14561
> 
> Modified:
>   head/usr.bin/ar/ar.c
>   head/usr.bin/ar/read.c
>   head/usr.bin/ar/util.c
> 
> Modified: head/usr.bin/ar/ar.c
> ==
> --- head/usr.bin/ar/ar.c  Wed Jun 20 17:37:55 2018(r335453)
> +++ head/usr.bin/ar/ar.c  Wed Jun 20 18:43:17 2018(r335454)
> @@ -1,4 +1,6 @@
>  /*-
> + * SPDX-License-Identifier: BSD-3-Clause
> + *

I think there may be an error above, commit message says 2 clause,
license below appears to be 2 clause, yet above we have 3?

>   * Copyright (c) 2007 Kai Wang
>   * Copyright (c) 2007 Tim Kientzle
>   * Copyright (c) 2007 Joseph Koshy
> @@ -8,22 +10,22 @@
>   * modification, are permitted provided that the following conditions
>   * are met:
>   * 1. Redistributions of source code must retain the above copyright
> - *notice, this list of conditions and the following disclaimer
> - *in this position and unchanged.
> + *notice, this list of conditions and the following disclaimer.
>   * 2. Redistributions in binary form must reproduce the above copyright
>   *notice, this list of conditions and the following disclaimer in the
>   *documentation and/or other materials provided with the distribution.
>   *
> - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) ``AS IS'' AND ANY EXPRESS OR
> - * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
> - * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
> - * IN NO EVENT SHALL THE AUTHOR(S) BE LIABLE FOR ANY DIRECT, INDIRECT,
> - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> + * SUCH DAMAGE.
>   */
>  
>  /*-
> 
> Modified: head/usr.bin/ar/read.c
> ==
> --- head/usr.bin/ar/read.cWed Jun 20 17:37:55 2018(r335453)
> +++ head/usr.bin/ar/read.cWed Jun 20 18:43:17 2018(r335454)
> @@ -1,4 +1,6 @@
>  /*-
> + * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
> + *
>   * Copyright (c) 2007 Kai Wang
>   * Copyright (c) 2007 Tim Kientzle
>   * All rights reserved.
> @@ -7,22 +9,22 @@
>   * modification, are permitted provided that the following conditions
>   * are met:
>   * 1. Redistributions of source code must retain the above copyright
> - *notice, this list of conditions and the following disclaimer
> - *in this position and unchanged.
> + *notice, this list of conditions and the following disclaimer.
>   * 2. Redistributions in binary form must reproduce the above copyright
>   *notice, this list of conditions and the following disclaimer in the
>   *documentation and/or other materials provided with the distribution.
>   *
> - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) ``AS IS'' AND ANY EXPRESS OR
> - * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
> - * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
> - * IN NO EVENT SHALL THE AUTHOR(S) BE LIABLE FOR ANY DIRECT, INDIRECT,
> - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> - * DATA, OR 

svn commit: r335462 - head/sys/dev/ixl

[Eric Joyner]

Author: erj
Date: Wed Jun 20 22:16:46 2018
New Revision: 335462
URL: https://svnweb.freebsd.org/changeset/base/335462

Log:
  ixl(4): Fix gcc build errors
  
  By removing redundant function declarations.
  
  Reported by:  ci.freebsd.org via Mark Millard 
  MFC after:1 month

Modified:
  head/sys/dev/ixl/ixl.h
  head/sys/dev/ixl/ixl_pf.h

Modified: head/sys/dev/ixl/ixl.h
==
--- head/sys/dev/ixl/ixl.h  Wed Jun 20 20:04:20 2018(r335461)
+++ head/sys/dev/ixl/ixl.h  Wed Jun 20 22:16:46 2018(r335462)
@@ -542,7 +542,6 @@ extern const uint8_t ixl_bcast_addr[ETHER_ADDR_LEN];
 
 /* Common function prototypes between PF/VF driver */
 voidixl_init_tx_ring(struct ixl_vsi *vsi, struct ixl_tx_queue 
*que);
-voidixl_set_queue_rx_itr(struct ixl_rx_queue *que);
 voidixl_get_default_rss_key(u32 *);
 const char *   i40e_vc_stat_str(struct i40e_hw *hw,
 enum virtchnl_status_code stat_err);

Modified: head/sys/dev/ixl/ixl_pf.h
==
--- head/sys/dev/ixl/ixl_pf.h   Wed Jun 20 20:04:20 2018(r335461)
+++ head/sys/dev/ixl/ixl_pf.h   Wed Jun 20 22:16:46 2018(r335462)
@@ -401,7 +401,5 @@ s32 ixl_write_i2c_byte_aq(struct ixl_pf *pf, u8 byte_o
 
 intixl_get_fw_lldp_status(struct ixl_pf *pf);
 intixl_attach_get_link_status(struct ixl_pf *);
-u64ixl_max_aq_speed_to_value(u8);
-void   ixl_handle_vflr(void *, int);
 
 #endif /* _IXL_PF_H_ */
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Stephen Kiernan]

(Apologies to cem@ for the duplicate in his inbox, Gmail decided to not
reply-all in my reply.)

On Wed, Jun 20, 2018 at 1:07 PM, Conrad Meyer  wrote:

> Hi Jon,
>
> On Wed, Jun 20, 2018 at 11:58 AM, Jonathan Anderson
>  wrote:
> > On 20 Jun 2018, at 15:32, Jonathan T. Looney wrote:
> >> My reasoning
> >> was fairly simple: when a review has been open for over a year with no
> >> action, it seems like the submitter should be able to commit it without
> >> waiting for more review, if they are confident in their change. I stand
> by
> >> that (and, in fact, would substitute something shorter for "over a
> year").
>
> For this as a question of general process, I think "it depends."  For
> minor fixes?  Of course!  Less than one year.  For minor improvements
> or enhancements?  Also yes, also probably less than 1yr.  For large
> features like this, I think the answer is more nuanced.
>
> Sometimes being in a review for a year means the reviewers are
> overloaded and don't have time.  In that case, maybe they shouldn't
> block progress.  Sometimes being in review for a year just means the
> right reviewers haven't been found.  I think that was more the case
> here.
>
> I would suggest anyone submitting a large feature and not getting
> feedback in a reasonable timeframe to solicit feedback from a wider
> audience much sooner than one year, and also indicate intention to
> merge the unreviewed change with some time window (1-2 weeks?) on
> giving feedback or at least asking for more time to review.
>

That was the problem. I soliticted feedback many times over at least 3
years.
The first set was in my GitHub branch and I had discussed with various
people starting at BSDCan 3 or 4 years ago.

I had even sent an early version of the changes to rwatson (whom I had
previously worked with at TIS/NAI/McAfee) and was provided some
feedback based on a cursory look over of the code, which was integrated
into the branch.

At MeetBSD 2016, I also discussed the code with some people and that
was when it was suggested that I create an account of Phabricator and
put the code up for review. Some members of core and/or the Foundation
had suggested who to talk to get reviews and I had also spoken with
rwatson again to see if he had any suggestions.

Once the code had landed in review, I also talked with people during
vBSDcon last year in an effort to try to find out who else should put eyes
on it. I even talked about it during one of the BoF sessions and pointed
out both my GitHub branch and the set of reviews on Phabricator, which
is when there started to get some additional feedback and/or watchers
on the review.

Also, after I had received my commit bit and the reviews were still
collecting
dust in Phabricator, on numberous occassions I solicited feedback or
suggestions on who to contact on the IRC channel.

I'm guessing that people had not looked at the reviews before suggesting
who to talk to or they did not realize the areas of interest that the
changes
might cover.

I think this experience illustrates the need for some better way for someone
contributing to be able to find out who the correct parties are that need
to be
contacted.

It was 3+ year struggle for me to find people to put eyes on the code and it
was not just a fire it off and wait forever thing. One can only listen to
crickets
in response for requests for help for so long.

-Steve
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Simon J. Gerraty]

Conrad Meyer  wrote:
> The signing of manifests does not exist in the patch series committed.

Nor will it, the singing of manifests is a build thing.

But as I mentioned earlier I think the loader verification code can be
leveraged for a verifying userland veriexec tool similar to that in
Junos.

> (If NetBSD does something broken, that is not an excuse to copy it.)

How about we backout the veriexecctl tool - which is the only bit your
comments apply to - and which we do not use.

All the signing etc discussion is orthogonal to the kernel part.

> > A veriexec loader that leverages signed manifests requires some signing
> > infra.  That's a big topic all by itself.
> 
> It *may* require that.  However, even without that, admins could
> reasonably manage their own PKI in some fashion, independent of

There still needs to be a tool that they can use.
The work I've done on the loader should make this simple since it
provides for OpenPGP signatures as well as X.509 based certs.

> FreeBSD's infra.  But it requires the support code to verify
> signatures, as in the "verify" part of veriexec, which is wholly
> absent.

Yes.  As above, reverting the veriexecctl tool would be fine,
I'll commit a proper verifying tool along with the loader bits.
I have to do some tweaking of one of my libs first.

> Again — this is a discussion for arch or phabricator, with the series
> reverted first.

For code that's off by default why is reverting a requirement?

> many other glaring performance problems.  If you care about MAC
> performance in a secure algorithm in 2018, perhaps look at any of
> these great options:
> 
> * SHA-3 (Keccak)
> * Blake2-b
> * Poly1305-{AES,Salsa,ChaCha}

The framework allows folk to add any hashes they like.
For us, anything which is not NIST approved is of little interest.
Obviously many people have the luxury of not haveing to bow to NIST,
so again the framework provides.

> FreeBSD has had this code for 0 years.  It's a novel feature here.
> There is no reason to introduce SHA-1 in novel security features in
> 2018.

As mentioned earlier (in this thread? hard to say), no reason it needs
to be enabled by default.

FreeBSD.org if they are going to sign the packages they ship, need to
make a decision about the hashes they want to support.

> And no, upstreaming the signature verification code is completely
> orthogonal to implementing signing infrastructure.

Not really since one dictates the other.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Simon J. Gerraty]

Xin LI  wrote:
> I do agree with others that SHA-1 support should not be included

It can certainly be disabled by default.

> (unless I have missed something, but I think firmware integrity check
> counts as a "Digital signature" verification, according to SP 800-131A

A "Digital signature" verification is an accepted form of firmware
integrity check, but a simple hash (inlcuding SHA-1) is also acceptible.
We of course perform both - and the Digital signature does *not* use
SHA-1, it has been deprecated for that purpose for some years now.

> "9 Hash algorithms", SHA-1 verification should only be used for legacy
> usage, which does not apply on FreeBSD because this is new feature).

I've managed to get out of having to memorize all those SP's, so will
check with one of the pour souls who still does - as to whether we are
claiming "legacy" status...

> But even that, given the code only impacts systems that have it
> explicitly compiled in, it's reasonable to give the committer more
> time to make further improvements rather than reverting it as a whole
> as this would give the code more exposure.

Indeed - thanks
--sjg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335456 - head/share/man/man7

[Ian Lepore]

On Wed, 2018-06-20 at 22:54 +0300, Konstantin Belousov wrote:
> On Wed, Jun 20, 2018 at 07:16:51PM +, Edward Tomasz Napierala wrote:
> > 
> > Author: trasz
> > Date: Wed Jun 20 19:16:51 2018
> > New Revision: 335456
> > URL: https://svnweb.freebsd.org/changeset/base/335456
> > 
> > Log:
> >   Improve wording.
> >   
> >   MFC after:2 weeks
> > 
> > Modified:
> >   head/share/man/man7/development.7
> > 
> > Modified: head/share/man/man7/development.7
> > ==
> > --- head/share/man/man7/development.7   Wed Jun 20 18:51:38 2018
> > (r335455)
> > +++ head/share/man/man7/development.7   Wed Jun 20 19:16:51 2018
> > (r335456)
> > @@ -24,7 +24,7 @@
> >  .\"
> >  .\" $FreeBSD$
> >  .\"
> > -.Dd May 11, 2018
> > +.Dd June 20, 2018
> >  .Dt DEVELOPMENT 7
> >  .Os
> >  .Sh NAME
> > @@ -81,7 +81,7 @@ Build instructions can be found in
> >  .Xr build 7
> >  and
> >  .Xr release 7 .
> > -Kernel APIs are usually documented, use
> > +Kernel APIs are documented in section 9 manual pages; use
> Kernel API is an oxymoron.  Section 9 describes Kernel Programming
> Interfaces, the A from Application is not needed.  We usually abbreviate
> it as KPI.

This is the manpage a new developer is going to look at, and if you
throw an abbreviation like KPI at them and they search for what it
means, they're going to find "Key Performance Indicator" and nothing
about kernels. This might be a good place to introduce and define that
acronym, maybe something like "Kernel programming interfaces (KPIs) are
documented...".

-- Ian
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Conrad Meyer]

Hi Jon,

On Wed, Jun 20, 2018 at 11:58 AM, Jonathan Anderson
 wrote:
> On 20 Jun 2018, at 15:32, Jonathan T. Looney wrote:
>> My reasoning
>> was fairly simple: when a review has been open for over a year with no
>> action, it seems like the submitter should be able to commit it without
>> waiting for more review, if they are confident in their change. I stand by
>> that (and, in fact, would substitute something shorter for "over a year").

For this as a question of general process, I think "it depends."  For
minor fixes?  Of course!  Less than one year.  For minor improvements
or enhancements?  Also yes, also probably less than 1yr.  For large
features like this, I think the answer is more nuanced.

Sometimes being in a review for a year means the reviewers are
overloaded and don't have time.  In that case, maybe they shouldn't
block progress.  Sometimes being in review for a year just means the
right reviewers haven't been found.  I think that was more the case
here.

I would suggest anyone submitting a large feature and not getting
feedback in a reasonable timeframe to solicit feedback from a wider
audience much sooner than one year, and also indicate intention to
merge the unreviewed change with some time window (1-2 weeks?) on
giving feedback or at least asking for more time to review.

> So: is there a strong reason why a backout-and-re-commit approach is
> superior to iterating on the code in-tree?

Yeah:

> Any disputed change must be backed out pending resolution of the dispute
> if requested by a maintainer. Security related changes may override a
> maintainer's wishes at the Security Officer's discretion.
>
> This may be hard to swallow in times of conflict (when each side is
> convinced that they are in the right, of course) but a version control
> system makes it unnecessary to have an ongoing dispute raging when it is
> far easier to simply reverse the disputed change, get everyone calmed
> down again and then try to figure out what is the best way to proceed.
> If the change turns out to be the best thing after all, it can be easily
> brought back. If it turns out not to be, then the users did not have to
> live with the bogus change in the tree while everyone was busily
> debating its merits. People very rarely call for back-outs in the
> repository since discussion generally exposes bad or controversial
> changes before the commit even happens, but on such rare occasions the
> back-out should be done without argument so that we can get immediately
> on to the topic of figuring out whether it was bogus or not.

In particular, SHA1 was never the primary reason the backout was
requested, just one design smell in the aggregate.  This change
introduces a security feature that doesn't provide the security
guarantees it claims to.  That should be a major red flag.

All the best,
Conrad
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335461 - in head/sys: kern sys

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 20:04:20 2018
New Revision: 335461
URL: https://svnweb.freebsd.org/changeset/base/335461

Log:
  Permit the kernel environment to set an array of numeric values for a single
  sysctl(9) node.
  
  Reviewed by:  kib@, imp@, jhb@
  Differential Revision:https://reviews.freebsd.org/D15802
  MFC after:1 week
  Sponsored by: Mellanox Technologies

Modified:
  head/sys/kern/kern_environment.c
  head/sys/kern/kern_sysctl.c
  head/sys/sys/systm.h

Modified: head/sys/kern/kern_environment.c
==
--- head/sys/kern/kern_environment.cWed Jun 20 19:45:04 2018
(r335460)
+++ head/sys/kern/kern_environment.cWed Jun 20 20:04:20 2018
(r335461)
@@ -53,6 +53,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -514,6 +515,141 @@ getenv_string(const char *name, char *data, int size)
strlcpy(data, cp, size);
}
return (cp != NULL);
+}
+
+/*
+ * Return an array of integers at the given type size and signedness.
+ */
+int
+getenv_array(const char *name, void *pdata, int size, int *psize,
+int type_size, bool allow_signed)
+{
+   char buf[KENV_MNAMELEN + 1 + KENV_MVALLEN + 1];
+   uint8_t shift;
+   int64_t value;
+   int64_t old;
+   char *end;
+   char *ptr;
+   int n;
+
+   if (getenv_string(name, buf, sizeof(buf)) == 0)
+   return (0);
+
+   /* get maximum number of elements */
+   size /= type_size;
+
+   n = 0;
+
+   for (ptr = buf; *ptr != 0; ) {
+
+   value = strtoq(ptr, , 0);
+
+   /* check if signed numbers are allowed */
+   if (value < 0 && !allow_signed)
+   goto error;
+
+   /* check for invalid value */
+   if (ptr == end)
+   goto error;
+   
+   /* check for valid suffix */
+   switch (*end) {
+   case 't':
+   case 'T':
+   shift = 40;
+   end++;
+   break;
+   case 'g':
+   case 'G':
+   shift = 30;
+   end++;
+   break;
+   case 'm':
+   case 'M':
+   shift = 20;
+   end++;
+   break;
+   case 'k':
+   case 'K':
+   shift = 10;
+   end++;
+   break;
+   case ' ':
+   case '\t':
+   case ',':
+   case 0:
+   shift = 0;
+   break;
+   default:
+   /* garbage after numeric value */
+   goto error;
+   }
+
+   /* skip till next value, if any */
+   while (*end == '\t' || *end == ',' || *end == ' ')
+   end++;
+
+   /* update pointer */
+   ptr = end;
+
+   /* apply shift */
+   old = value;
+   value <<= shift;
+
+   /* overflow check */
+   if ((value >> shift) != old)
+   goto error;
+
+   /* check for buffer overflow */
+   if (n >= size)
+   goto error;
+
+   /* store value according to type size */
+   switch (type_size) {
+   case 1:
+   if (allow_signed) {
+   if (value < SCHAR_MIN || value > SCHAR_MAX)
+   goto error;
+   } else {
+   if (value < 0 || value > UCHAR_MAX)
+   goto error;
+   }
+   ((uint8_t *)pdata)[n] = (uint8_t)value;
+   break;
+   case 2:
+   if (allow_signed) {
+   if (value < SHRT_MIN || value > SHRT_MAX)
+   goto error;
+   } else {
+   if (value < 0 || value > USHRT_MAX)
+   goto error;
+   }
+   ((uint16_t *)pdata)[n] = (uint16_t)value;
+   break;
+   case 4:
+   if (allow_signed) {
+   if (value < INT_MIN || value > INT_MAX)
+   goto error;
+   } else {
+   if (value > UINT_MAX)
+   goto error;
+   }
+   ((uint32_t *)pdata)[n] = (uint32_t)value;
+   

Re: svn commit: r335456 - head/share/man/man7

[Konstantin Belousov]

On Wed, Jun 20, 2018 at 07:16:51PM +, Edward Tomasz Napierala wrote:
> Author: trasz
> Date: Wed Jun 20 19:16:51 2018
> New Revision: 335456
> URL: https://svnweb.freebsd.org/changeset/base/335456
> 
> Log:
>   Improve wording.
>   
>   MFC after:  2 weeks
> 
> Modified:
>   head/share/man/man7/development.7
> 
> Modified: head/share/man/man7/development.7
> ==
> --- head/share/man/man7/development.7 Wed Jun 20 18:51:38 2018
> (r335455)
> +++ head/share/man/man7/development.7 Wed Jun 20 19:16:51 2018
> (r335456)
> @@ -24,7 +24,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd May 11, 2018
> +.Dd June 20, 2018
>  .Dt DEVELOPMENT 7
>  .Os
>  .Sh NAME
> @@ -81,7 +81,7 @@ Build instructions can be found in
>  .Xr build 7
>  and
>  .Xr release 7 .
> -Kernel APIs are usually documented, use
> +Kernel APIs are documented in section 9 manual pages; use
Kernel API is an oxymoron.  Section 9 describes Kernel Programming
Interfaces, the A from Application is not needed.  We usually abbreviate
it as KPI.

Kernel API are syscalls, if anything.
>  .Ql "apropos -s 9 ''"
>  for a list.
>  Regression test suite is described in
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335460 - head

[Bryan Drewery]

Author: bdrewery
Date: Wed Jun 20 19:45:04 2018
New Revision: 335460
URL: https://svnweb.freebsd.org/changeset/base/335460

Log:
  Only look for NOTES as needed.
  
  Sponsored by: Dell EMC

Modified:
  head/Makefile

Modified: head/Makefile
==
--- head/Makefile   Wed Jun 20 19:40:54 2018(r335459)
+++ head/Makefile   Wed Jun 20 19:45:04 2018(r335460)
@@ -573,13 +573,13 @@ universe_${target}_${target_arch}: universe_${target}_
 universe_${target}_done: universe_${target}_kernels .PHONY
 universe_${target}_kernels: universe_${target}_worlds .PHONY
 universe_${target}_kernels: universe_${target}_prologue .MAKE .PHONY
-.if exists(${KERNSRCDIR}/${target}/conf/NOTES)
-   @(cd ${KERNSRCDIR}/${target}/conf && env __MAKE_CONF=/dev/null \
+   @if [ -e "${KERNSRCDIR}/${target}/conf/NOTES" ]; then \
+ (cd ${KERNSRCDIR}/${target}/conf && env __MAKE_CONF=/dev/null \
${SUB_MAKE} LINT \
> ${.CURDIR}/_.${target}.makeLINT 2>&1 || \
(echo "${target} 'make LINT' failed," \
-   "check _.${target}.makeLINT for details"| ${MAKEFAIL}))
-.endif
+   "check _.${target}.makeLINT for details"| ${MAKEFAIL})); \
+   fi
@cd ${.CURDIR}; ${SUB_MAKE} ${.MAKEFLAGS} TARGET=${target} \
universe_kernels
 .endif # !MAKE_JUST_WORLDS
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335459 - head/usr.sbin/acpi/acpidump

[Ed Maste]

Author: emaste
Date: Wed Jun 20 19:40:54 2018
New Revision: 335459
URL: https://svnweb.freebsd.org/changeset/base/335459

Log:
  acpidump.8: include NFIT in the man page list of tables
  
  Was missed in r321298.
  
  Reported by:  Ben Widawsky (in review D15931)
  MFC after:1 week

Modified:
  head/usr.sbin/acpi/acpidump/acpidump.8

Modified: head/usr.sbin/acpi/acpidump/acpidump.8
==
--- head/usr.sbin/acpi/acpidump/acpidump.8  Wed Jun 20 19:23:56 2018
(r335458)
+++ head/usr.sbin/acpi/acpidump/acpidump.8  Wed Jun 20 19:40:54 2018
(r335459)
@@ -29,7 +29,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd February 14, 2005
+.Dd June 20, 2018
 .Dt ACPIDUMP 8
 .Os
 .Sh NAME
@@ -105,6 +105,7 @@ utility dumps contents of the following tables:
 .It HPET
 .It MADT
 .It MCFG
+.It NFIT
 .It RSD PTR
 .It RSDT
 .It WDDT
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335458 - head/sys/kern

[Kyle Evans]

Author: kevans
Date: Wed Jun 20 19:23:56 2018
New Revision: 335458
URL: https://svnweb.freebsd.org/changeset/base/335458

Log:
  Add debug.verbose_sysinit tunable for VERBOSE_SYSINIT
  
  VERBOSE_SYSINIT is currently an all-or-nothing option. debug.verbose_sysinit
  adds an option to have the code compiled in but quiet by default so that
  getting this information from a device in the field doesn't necessarily
  require distributing a recompiled kernel.
  
  Its default is VERBOSE_SYSINIT's value as defined in the kernconf. As such,
  the default behavior for simply omitting or including this option is
  unchanged.
  
  MFC after:1 week

Modified:
  head/sys/kern/init_main.c

Modified: head/sys/kern/init_main.c
==
--- head/sys/kern/init_main.c   Wed Jun 20 19:22:33 2018(r335457)
+++ head/sys/kern/init_main.c   Wed Jun 20 19:23:56 2018(r335458)
@@ -119,6 +119,18 @@ intbootverbose = BOOTVERBOSE;
 SYSCTL_INT(_debug, OID_AUTO, bootverbose, CTLFLAG_RW, , 0,
"Control the output of verbose kernel messages");
 
+#ifdef VERBOSE_SYSINIT
+/*
+ * We'll use the defined value of VERBOSE_SYSINIT from the kernel config to
+ * dictate the default VERBOSE_SYSINIT behavior.  Significant values for this
+ * option and associated tunable are:
+ * - 0, 'compiled in but silent by default'
+ * - 1, 'compiled in but verbose by default' (default)
+ */
+intverbose_sysinit = VERBOSE_SYSINIT;
+TUNABLE_INT("debug.verbose_sysinit", _sysinit);
+#endif
+
 #ifdef INVARIANTS
 FEATURE(invariants, "Kernel compiled with INVARIANTS, may affect performance");
 #endif
@@ -268,7 +280,7 @@ restart:
continue;
 
 #if defined(VERBOSE_SYSINIT)
-   if ((*sipp)->subsystem > last) {
+   if ((*sipp)->subsystem > last && verbose_sysinit != 0) {
verbose = 1;
last = (*sipp)->subsystem;
printf("subsystem %x\n", last);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335457 - head

[John Baldwin]

Author: jhb
Date: Wed Jun 20 19:22:33 2018
New Revision: 335457
URL: https://svnweb.freebsd.org/changeset/base/335457

Log:
  Correct path to removed asf(8) binary.

Modified:
  head/ObsoleteFiles.inc

Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.inc  Wed Jun 20 19:16:51 2018(r335456)
+++ head/ObsoleteFiles.inc  Wed Jun 20 19:22:33 2018(r335457)
@@ -39,7 +39,7 @@
 # done
 
 # 20180615: asf(8) removed
-OLD_FILES+=usr/bin/asf
+OLD_FILES+=usr/sbin/asf
 OLD_FILES+=usr/share/man/man8/asf.8.gz
 # 20180609: obsolete libc++ files missed from the 5.0.0 import
 OLD_FILES+=usr/include/c++/v1/__refstring
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335456 - head/share/man/man7

[Edward Tomasz Napierala]

Author: trasz
Date: Wed Jun 20 19:16:51 2018
New Revision: 335456
URL: https://svnweb.freebsd.org/changeset/base/335456

Log:
  Improve wording.
  
  MFC after:2 weeks

Modified:
  head/share/man/man7/development.7

Modified: head/share/man/man7/development.7
==
--- head/share/man/man7/development.7   Wed Jun 20 18:51:38 2018
(r335455)
+++ head/share/man/man7/development.7   Wed Jun 20 19:16:51 2018
(r335456)
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd May 11, 2018
+.Dd June 20, 2018
 .Dt DEVELOPMENT 7
 .Os
 .Sh NAME
@@ -81,7 +81,7 @@ Build instructions can be found in
 .Xr build 7
 and
 .Xr release 7 .
-Kernel APIs are usually documented, use
+Kernel APIs are documented in section 9 manual pages; use
 .Ql "apropos -s 9 ''"
 for a list.
 Regression test suite is described in
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Jonathan Anderson]

On 20 Jun 2018, at 15:32, Jonathan T. Looney wrote:

On Wed, Jun 20, 2018 at 9:49 AM Stephen Kiernan 


wrote:
And I was working on those sets of changes, when work and family 
didn't
steal away time. I was told that some discussion happened at BSDCan 
this
year in such that veriexec should go in as-is so it would be there, 
which

is why

the commit happened (given the review was approved to land back in

January.)

I will readily admit that I was probably the source of this. My 
reasoning

was fairly simple: when a review has been open for over a year with no
action, it seems like the submitter should be able to commit it 
without
waiting for more review, if they are confident in their change. I 
stand by
that (and, in fact, would substitute something shorter for "over a 
year").


([...] I wasn't intending to push Steve to commit
this before he was ready.)


I suspect I was part of that push, and while it's provoked some 
discussion I still think it was the right course of action. Simon and I 
chatted about these changes at BSDCan (starting with my apologies for 
not doing the asked-for review two years ago!) and I suggested that, 
since the changes had been accepted in Phabricator in January and nobody 
had raised any objections since then (see: D85{61,62,75}), it would 
probably be better to commit and iterate than to continue waiting for an 
unspecified number of additional reviews that might never come. Now that 
the code has landed it's sparked some lively discussion about potential 
improvements, but that's a much better situation than the silence Steve 
heard for a long time in Phabricator.


So: is there a strong reason why a backout-and-re-commit approach is 
superior to iterating on the code in-tree? SHA-1 doesn't give me the 
warm fuzzies either, but I don't see why the whole framework has to be 
backed out rather than just receive incremental improvements, e.g., 
disabling or removing SHA-1 while keeping it easy for downstream 
consumers to re-enable/re-add whatever algorithms their customers want.



Jon
--
jonat...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335455 - in stable/10/sys: amd64/amd64 i386/i386 i386/isa

[Konstantin Belousov]

Author: kib
Date: Wed Jun 20 18:51:38 2018
New Revision: 335455
URL: https://svnweb.freebsd.org/changeset/base/335455

Log:
  MFC r335072, r335089, r335131, r335132:
  Enable eager FPU context switch on i386 and amd64.
  
  CVE:  CVE-2018-3665
  Tested by:emaste (smoke boot)

Modified:
  stable/10/sys/amd64/amd64/cpu_switch.S
  stable/10/sys/amd64/amd64/fpu.c
  stable/10/sys/i386/i386/swtch.s
  stable/10/sys/i386/isa/npx.c
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/sys/amd64/amd64/cpu_switch.S
==
--- stable/10/sys/amd64/amd64/cpu_switch.S  Wed Jun 20 18:43:17 2018
(r335454)
+++ stable/10/sys/amd64/amd64/cpu_switch.S  Wed Jun 20 18:51:38 2018
(r335455)
@@ -111,10 +111,10 @@ done_store_dr:
 
/* have we used fp, and need a save? */
cmpq%rdi,PCPU(FPCURTHREAD)
-   jne 3f
+   jne 2f
movqPCB_SAVEFPU(%r8),%r8
clts
-   cmpl$0,use_xsave
+   cmpl$0,use_xsave(%rip)
jne 1f
fxsave  (%r8)
jmp 2f
@@ -126,12 +126,7 @@ ctx_switch_xsave:
/* This is patched to xsaveopt if supported, see fpuinit_bsp1() */
xsave   (%r8)
movq%rcx,%rdx
-2: smsw%ax
-   orb $CR0_TS,%al
-   lmsw%ax
-   xorl%eax,%eax
-   movq%rax,PCPU(FPCURTHREAD)
-3:
+2:
 
/* Save is done.  Now fire up new thread. Leave old vmspace. */
movqTD_PCB(%rsi),%r8
@@ -255,6 +250,8 @@ done_load_dr:
movqPCB_RBX(%r8),%rbx
movqPCB_RIP(%r8),%rax
movq%rax,(%rsp)
+   movqPCPU(CURTHREAD),%rdi
+   callfpu_activate_sw
ret
 
/*

Modified: stable/10/sys/amd64/amd64/fpu.c
==
--- stable/10/sys/amd64/amd64/fpu.c Wed Jun 20 18:43:17 2018
(r335454)
+++ stable/10/sys/amd64/amd64/fpu.c Wed Jun 20 18:51:38 2018
(r335455)
@@ -139,6 +139,11 @@ static voidfpu_clean_state(void);
 SYSCTL_INT(_hw, HW_FLOATINGPT, floatingpoint, CTLFLAG_RD,
 SYSCTL_NULL_INT_PTR, 1, "Floating point instructions executed in 
hardware");
 
+int lazy_fpu_switch = 0;
+SYSCTL_INT(_hw, OID_AUTO, lazy_fpu_switch, CTLFLAG_RWTUN | CTLFLAG_NOFETCH,
+_fpu_switch, 0,
+"Lazily load FPU context after context switch");
+
 int use_xsave; /* non-static for cpu_switch.S */
 uint64_t xsave_mask;   /* the same */
 static uma_zone_t fpu_save_area_zone;
@@ -204,6 +209,7 @@ fpuinit_bsp1(void)
u_int cp[4];
uint64_t xsave_mask_user;
 
+   TUNABLE_INT_FETCH("hw.lazy_fpu_switch", _fpu_switch);
if ((cpu_feature2 & CPUID2_XSAVE) != 0) {
use_xsave = 1;
TUNABLE_INT_FETCH("hw.use_xsave", _xsave);
@@ -611,6 +617,45 @@ fputrap_sse(void)
return (fpetable[(mxcsr & (~mxcsr >> 7)) & 0x3f]);
 }
 
+static void
+restore_fpu_curthread(struct thread *td)
+{
+   struct pcb *pcb;
+
+   /*
+* Record new context early in case frstor causes a trap.
+*/
+   PCPU_SET(fpcurthread, td);
+
+   stop_emulating();
+   fpu_clean_state();
+   pcb = td->td_pcb;
+
+   if ((pcb->pcb_flags & PCB_FPUINITDONE) == 0) {
+   /*
+* This is the first time this thread has used the FPU or
+* the PCB doesn't contain a clean FPU state.  Explicitly
+* load an initial state.
+*
+* We prefer to restore the state from the actual save
+* area in PCB instead of directly loading from
+* fpu_initialstate, to ignite the XSAVEOPT
+* tracking engine.
+*/
+   bcopy(fpu_initialstate, pcb->pcb_save,
+   cpu_max_ext_state_size);
+   fpurestore(pcb->pcb_save);
+   if (pcb->pcb_initial_fpucw != __INITIAL_FPUCW__)
+   fldcw(pcb->pcb_initial_fpucw);
+   if (PCB_USER_FPU(pcb))
+   set_pcb_flags(pcb, PCB_FPUINITDONE |
+   PCB_USERFPUINITDONE);
+   else
+   set_pcb_flags(pcb, PCB_FPUINITDONE);
+   } else
+   fpurestore(pcb->pcb_save);
+}
+
 /*
  * Device Not Available (DNA, #NM) exception handler.
  *
@@ -621,7 +666,9 @@ fputrap_sse(void)
 void
 fpudna(void)
 {
+   struct thread *td;
 
+   td = curthread;
/*
 * This handler is entered with interrupts enabled, so context
 * switches may occur before critical_enter() is executed.  If
@@ -633,49 +680,38 @@ fpudna(void)
 */
critical_enter();
 
-   if (PCPU_GET(fpcurthread) == curthread) {
-   printf("fpudna: fpcurthread == curthread\n");
+   if (__predict_false(PCPU_GET(fpcurthread) == td)) {
+   /*
+* Some 

svn commit: r335454 - head/usr.bin/ar

[Ed Maste]

Author: emaste
Date: Wed Jun 20 18:43:17 2018
New Revision: 335454
URL: https://svnweb.freebsd.org/changeset/base/335454

Log:
  usr.bin/ar: use standard 2-Clause FreeBSD license
  
  Many licenses on ar files contained small variations from the standard
  FreeBSD license text. To avoid license proliferation switch to the usual
  2-clause FreeBSD license after obtaining permission from all copyright
  holders.
  
  Approved by:  jkoshy, kaiw, kientzle
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D14561

Modified:
  head/usr.bin/ar/ar.c
  head/usr.bin/ar/read.c
  head/usr.bin/ar/util.c

Modified: head/usr.bin/ar/ar.c
==
--- head/usr.bin/ar/ar.cWed Jun 20 17:37:55 2018(r335453)
+++ head/usr.bin/ar/ar.cWed Jun 20 18:43:17 2018(r335454)
@@ -1,4 +1,6 @@
 /*-
+ * SPDX-License-Identifier: BSD-3-Clause
+ *
  * Copyright (c) 2007 Kai Wang
  * Copyright (c) 2007 Tim Kientzle
  * Copyright (c) 2007 Joseph Koshy
@@ -8,22 +10,22 @@
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer
- *in this position and unchanged.
+ *notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *notice, this list of conditions and the following disclaimer in the
  *documentation and/or other materials provided with the distribution.
  *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) ``AS IS'' AND ANY EXPRESS OR
- * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
- * IN NO EVENT SHALL THE AUTHOR(S) BE LIABLE FOR ANY DIRECT, INDIRECT,
- * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
  */
 
 /*-

Modified: head/usr.bin/ar/read.c
==
--- head/usr.bin/ar/read.c  Wed Jun 20 17:37:55 2018(r335453)
+++ head/usr.bin/ar/read.c  Wed Jun 20 18:43:17 2018(r335454)
@@ -1,4 +1,6 @@
 /*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
  * Copyright (c) 2007 Kai Wang
  * Copyright (c) 2007 Tim Kientzle
  * All rights reserved.
@@ -7,22 +9,22 @@
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer
- *in this position and unchanged.
+ *notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *notice, this list of conditions and the following disclaimer in the
  *documentation and/or other materials provided with the distribution.
  *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) ``AS IS'' AND ANY EXPRESS OR
- * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
- * IN NO EVENT SHALL THE AUTHOR(S) BE LIABLE FOR ANY DIRECT, INDIRECT,
- * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR 

Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Wed, 20 Jun 2018 19:03:15 +0300
Konstantin Belousov  schrieb:

> On Wed, Jun 20, 2018 at 09:43:31AM -0600, Ian Lepore wrote:
> > On Wed, 2018-06-20 at 12:22 +0300, Konstantin Belousov wrote:  
> > > On Tue, Jun 19, 2018 at 08:34:18PM -0400, Allan Jude wrote:  
> > > > 
> > > > On 2018-06-17 07:32, Eugene Grosbein wrote:  
> > > > > 
> > > > > 17.06.2018 10:18, Allan Jude wrote:
> > > > >   
> > > > > > 
> > > > > > Author: allanjude
> > > > > > Date: Sun Jun 17 03:18:56 2018
> > > > > > New Revision: 335276
> > > > > > URL: https://svnweb.freebsd.org/changeset/base/335276
> > > > > > 
> > > > > > Log:
> > > > > >   gptboot, zfsboot, gptzfsboot: Enable the video and serial 
> > > > > > consoles early
> > > > > >   
> > > > > >   Normally the serial console is not enabled until /boot.config is 
> > > > > > read and
> > > > > >   we know how the serial console should be configured.  Initialize 
> > > > > > the
> > > > > >   consoles early in 'dual' mode (serial & keyboard) with a default 
> > > > > > serial
> > > > > >   rate of 115200. Then serial is re-initialized once the disk is 
> > > > > > decrypted
> > > > > >   and the /boot.config file can be read.
> > > > > >   
> > > > > >   This allows the GELIBoot passphrase to be provided via the serial 
> > > > > > console.
> > > > > >   
> > > > > >   PR:   221526
> > > > > >   Requested by: many
> > > > > >   Reviewed by:  imp
> > > > > >   Sponsored by: Klara Systems
> > > > > >   Differential Revision:https://reviews.freebsd.org/D15862  
> > > > > I had several cases when booting FreeBSD/amd64 with motherboard 
> > > > > having no
> > > > > serial ports hang hard early at boot unless I rebuilt boot media 
> > > > > configuring it
> > > > > to NOT try accessing missing serial ports. I even could reproduce 
> > > > > that with
> > > > > VirtualBox machine configured with no serial ports (not same as 
> > > > > existing bug
> > > > > inactive serial port).
> > > > > 
> > > > > Should there be some way to disable this serial ports configuration 
> > > > > at compile
> > > > > time?
> > > > > 
> > > > > 
> > > > >   
> > > > I think what we'll do it compile it both ways, and use the non-serial
> > > > one by default, because it is safer. Then you can just use
> > > > 'gptboot-serial' if you want serial support.
> > > > 
> > > > This will likely make Warner a bit sad, since we are just finally
> > > > getting around to reducing the number of different bootcode files.  
> > > I think we should follow the hardware trends there and apply a policy
> > > where new features are not added to the CSM boot. All modern machines
> > > can be booted in UEFI mode, and if some modern machine cannot, then we
> > > need it fixed.  We should encourage users to make new installs boot by
> > > UEFI.
> > > 
> > > The feature from the commit is only relevant for machines that require
> > > CSM boot or do not have UEFI option at all, am I right ? With the policy
> > > applied, an additional CSM-boot bootblock would be not shipped.
> > >   
> > 
> > I think it is far too early to say that the code for booting without
> > efi is abandonware. I have half a dozen x86 boxes in use here, and only
> > one of them is even able to boot efi, and its default resolution in efi
> > mode confuses the kvm switch it's connected to, so even on that I have
> > to use legacy bios boot.  
> I do not propose to abandon bios boot, or even to declare it legacy
> with the proper meaning. I mean that CSM is disappearing on the newest
> platforms, and should become only used on old machines or i386.  With that
> attitude, adding a features for it, esp. by the cost of the user confusion,
> is not worth the efforts.  It still should be maintained for the foreseable
> future.
> 
> If the machines where you get the trouble is newer than say 5 years, 
> then they should boot with UEFI.  If not, the problem in loader.efi
> needs to be fixed.
> ___
> svn-src-h...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


I'm a bit confused right now. I lived under the impression that the PCengines 
APU 2C is a
very common piece of hardware amongst FreeBSD users and developers:

 https://www.pcengines.ch/apu2c4.htm

This piece of hardware is still non-UEFI, although coreboot seems to support 
UEFI. So,
in the "opensource market", there is still pretty recent hadware around with 
non-UEFI
capabilities. 

I was wondering why the APU wasn't able to boot with an early enabled serial 
console,
although this piece of hardware is serial-console only and we use "tip" to 
connect.

The kernel I use is is customised - so if there is a prerequisite to have 
compiled in,
please let me know.

Regards,
Oliver

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder "Ubermittlung meiner Daten f"ur
Werbezwecke oder 

Re: svn commit: r335278 - head/bin/pwd

[John Baldwin]

On 6/18/18 10:26 PM, Eitan Adler wrote:
> On 18 June 2018 at 10:57, John Baldwin  wrote:
>> On 6/16/18 10:14 PM, Eitan Adler wrote:
>>> Author: eadler
>>> Date: Sun Jun 17 05:14:50 2018
>>> New Revision: 335278
>>> URL: https://svnweb.freebsd.org/changeset/base/335278
>>>
>>> Log:
>>>   pwd: mark usage as dead
>>
>> You keep committing changes like this and ignoring e-mails about them.
> 
> I replied both the first time and this time. I may have
> (accidentally?) ignored similar emails though. The question I have is
> other than the mild code churn what's the harm?
> 
>> What broken compiler are you using that doesn't properly inherit __dead2
>> from the call to exit()?
> 
> In this case, scan-build50 was getting annoyed.

In this case, someone in a private reply suggested that marking
usage 'static' is probably the better fix than marking it __dead2.
If that change satisfies scan-build then I think that is a better
approach.

Also, the proper place for __dead2 if you were going to use it would
be on the prototype, not the definition.  That is, if usage() were
intended to be an exported function like abort() or exit(), then you
want to mark the prototype in the header as __dead2 so that the
compiler will understand that those functions don't return.  However,
that annotation is only useful on the prototype, not the definition.

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Xin LI]

On Wed, Jun 20, 2018 at 10:58 AM Jonathan T. Looney  wrote:
>
> On Tue, Jun 19, 2018 at 8:34 PM Conrad Meyer  wrote:
>>
>> Please revert this patchset.  It's not ready.
>
>
> I'm not sure I understand the need to revert the patches. They may need some 
> refinement, but they also do provide some functionality upon which you can 
> build the tooling that Simon discussed.
>
> Unless I missed something, this feature only impacts the system when it is 
> specifically compiled in. In cases like that, I think its reasonable to give 
> the committer some time to refine them in place prior to the code 
> slush/freeze, at which point we can decide what to do.

+1 for all points.

I do agree with others that SHA-1 support should not be included
(unless I have missed something, but I think firmware integrity check
counts as a "Digital signature" verification, according to SP 800-131A
"9 Hash algorithms", SHA-1 verification should only be used for legacy
usage, which does not apply on FreeBSD because this is new feature).
But even that, given the code only impacts systems that have it
explicitly compiled in, it's reasonable to give the committer more
time to make further improvements rather than reverting it as a whole
as this would give the code more exposure.

Cheers,
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Jonathan T. Looney]

On Wed, Jun 20, 2018 at 9:49 AM Stephen Kiernan 
wrote:
> And I was working on those sets of changes, when work and family didn't
> steal away time. I was told that some discussion happened at BSDCan this
> year in such that veriexec should go in as-is so it would be there, which
is why
> the commit happened (given the review was approved to land back in
January.)

I will readily admit that I was probably the source of this. My reasoning
was fairly simple: when a review has been open for over a year with no
action, it seems like the submitter should be able to commit it without
waiting for more review, if they are confident in their change. I stand by
that (and, in fact, would substitute something shorter for "over a year").

(Of course, if the submitter has other reasons for delaying the commit,
that's their prerogative, and I wasn't intending to push Steve to commit
this before he was ready.)

Jonathan
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Jonathan T. Looney]

On Tue, Jun 19, 2018 at 8:34 PM Conrad Meyer  wrote:

> Please revert this patchset.  It's not ready.
>

I'm not sure I understand the need to revert the patches. They may need
some refinement, but they also do provide some functionality upon which you
can build the tooling that Simon discussed.

Unless I missed something, this feature only impacts the system when it is
specifically compiled in. In cases like that, I think its reasonable to
give the committer some time to refine them in place prior to the code
slush/freeze, at which point we can decide what to do.

Jonathan
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Conrad Meyer]

Hi Simon,

Jonathan points out some of my comments were more acerbic than
necessary.  I apologize for that.  I'd like to try to rephrase them in
a more clear way.

On Wed, Jun 20, 2018 at 8:43 AM, Conrad Meyer  wrote:
> On Tue, Jun 19, 2018 at 11:21 PM, Simon J. Gerraty  wrote:
>> As I mentioned in my talk at BSDCan,
>
> (FWIW, I was not at your talk, and it is not a justification for bad
> design or implementation anyway.)

I said before and I'll repeat: I think this design is pretty close to
a reasonable security feature.  I think it currently has a number of
serious — but addressable — flaws, some of which I have tried to
outline.

> ...
> Why is this either necessary or helpful to be in the FreeBSD tree
> as-is?  I don't think it is, and you should revert it.  Please.  I
> don't know if there's a maintainer timeout on this kind of thing, but,
> you are forewarned.

Sorry, this was a poor choice of words.

I mean to say something like: I asked for a revert in an earlier
email, and this reply did not address the primary reason for the
revert, so I am still asking for a revert.  I can do it myself, but I
would like to give the committer the opportunity to do it themselves.

(In private, Stephen has let me know he will do so when he gets back
to his FreeBSD machines, so there's no need for that anyway.)

All the best,
Conrad
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335453 - stable/11/sys/amd64/amd64

[Konstantin Belousov]

Author: kib
Date: Wed Jun 20 17:37:55 2018
New Revision: 335453
URL: https://svnweb.freebsd.org/changeset/base/335453

Log:
  MFC r332994 (by tychon):
  Handle potential alignment adjustment of the exception frame by hardware.

Modified:
  stable/11/sys/amd64/amd64/exception.S
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/amd64/amd64/exception.S
==
--- stable/11/sys/amd64/amd64/exception.S   Wed Jun 20 17:20:39 2018
(r335452)
+++ stable/11/sys/amd64/amd64/exception.S   Wed Jun 20 17:37:55 2018
(r335453)
@@ -341,6 +341,9 @@ page_cr2:
 * On the stack, we have the hardware interrupt frame to return
 * to usermode (faulted) and another frame with error code, for
 * fault.  For PTI, copy both frames to the main thread stack.
+* Handle the potential 16-byte alignment adjustment incurred
+* during the second fault by copying both frames independently
+* while unwinding the stack in between.
 */
.macro PROTF_ENTRY name,trapno
 \name\()_pti_doreti:
@@ -351,7 +354,11 @@ page_cr2:
movq%rax,%cr3
movqPCPU(RSP0),%rax
subq$2*PTI_SIZE-3*8,%rax /* no err, %rax, %rdx in faulted frame */
-   MOVE_STACKS (PTI_SIZE / 4 - 3)
+   MOVE_STACKS (PTI_SIZE / 8)
+   addq$PTI_SIZE,%rax
+   movqPTI_RSP(%rsp),%rsp
+   MOVE_STACKS (PTI_SIZE / 8 - 3)
+   subq$PTI_SIZE,%rax
movq%rax,%rsp
popq%rdx
popq%rax
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335452 - in head: . share/mk

[Bryan Drewery]

Author: bdrewery
Date: Wed Jun 20 17:20:39 2018
New Revision: 335452
URL: https://svnweb.freebsd.org/changeset/base/335452

Log:
  Reduce exec and fstat overhead for non-build targets.
  
  This is mostly targetting 'make showconfig' and 'make test-system-*' for
  the benefit of makeman and universe-one-clang work.
  
  Sponsored by: Dell EMC

Modified:
  head/Makefile.inc1
  head/Makefile.libcompat
  head/share/mk/bsd.compiler.mk
  head/share/mk/bsd.init.mk
  head/share/mk/local.meta.sys.mk
  head/share/mk/src.sys.obj.mk
  head/share/mk/sys.mk

Modified: head/Makefile.inc1
==
--- head/Makefile.inc1  Wed Jun 20 16:15:03 2018(r335451)
+++ head/Makefile.inc1  Wed Jun 20 17:20:39 2018(r335452)
@@ -50,6 +50,10 @@
 .error "Both TARGET and TARGET_ARCH must be defined."
 .endif
 
+.if make(showconfig) || make(test-system-*)
+_MKSHOWCONFIG= t
+.endif
+
 SRCDIR?=   ${.CURDIR}
 LOCALBASE?=/usr/local
 
@@ -175,7 +179,8 @@ WANT_COMPILER_TYPE= gcc
 WANT_COMPILER_TYPE=
 .endif
 
-.if !defined(WANT_COMPILER_FREEBSD_VERSION)
+.if !defined(WANT_COMPILER_FREEBSD_VERSION) && !make(showconfig) && \
+!make(test-system-linker)
 .if ${WANT_COMPILER_TYPE} == "clang"
 WANT_COMPILER_FREEBSD_VERSION_FILE= lib/clang/freebsd_cc_version.h
 WANT_COMPILER_FREEBSD_VERSION!= \
@@ -203,8 +208,9 @@ WANT_COMPILER_VERSION!= \
 # GCC cannot be used for cross-arch yet.  For clang we pass -target later if
 # TARGET_ARCH!=MACHINE_ARCH.
 .if ${MK_SYSTEM_COMPILER} == "yes" && \
+defined(WANT_COMPILER_FREEBSD_VERSION) && \
 (${MK_CLANG_BOOTSTRAP} == "yes" || ${MK_GCC_BOOTSTRAP} == "yes") && \
-!make(showconfig) && !make(xdev*) && \
+!make(xdev*) && \
 ${X_COMPILER_TYPE} == ${WANT_COMPILER_TYPE} && \
 (${X_COMPILER_TYPE} == "clang" || ${TARGET_ARCH} == ${MACHINE_ARCH}) && \
 ${X_COMPILER_VERSION} == ${WANT_COMPILER_VERSION} && \
@@ -228,7 +234,8 @@ WANT_LINKER_TYPE=   bfd
 WANT_LINKER_TYPE=
 .endif
 
-.if !defined(WANT_LINKER_FREEBSD_VERSION)
+.if !defined(WANT_LINKER_FREEBSD_VERSION) && !make(showconfig) && \
+!make(test-system-compiler)
 .if ${WANT_LINKER_TYPE} == "lld"
 WANT_LINKER_FREEBSD_VERSION_FILE= lib/clang/include/lld/Common/Version.inc
 WANT_LINKER_FREEBSD_VERSION!= \
@@ -246,8 +253,9 @@ WANT_LINKER_FREEBSD_VERSION=
 .endif # !defined(WANT_LINKER_FREEBSD_VERSION)
 
 .if ${MK_SYSTEM_LINKER} == "yes" && \
+defined(WANT_LINKER_FREEBSD_VERSION) && \
 (${MK_LLD_BOOTSTRAP} == "yes") && \
-!make(showconfig) && !make(xdev*) && \
+!make(xdev*) && \
 ${X_LINKER_TYPE} == ${WANT_LINKER_TYPE} && \
 ${X_LINKER_VERSION} == ${WANT_LINKER_VERSION} && \
 ${X_LINKER_FREEBSD_VERSION} == ${WANT_LINKER_FREEBSD_VERSION}
@@ -437,6 +445,7 @@ BUILDENV_SHELL?=${SHELL}
 BUILDENV_SHELL?=/bin/sh
 .endif
 
+.if !defined(_MKSHOWCONFIG)
 .if !defined(SVN_CMD) || empty(SVN_CMD)
 . for _P in /usr/bin /usr/local/bin
 .  for _S in svn svnlite
@@ -505,6 +514,7 @@ EXTRA_REVISION= _${_BRANCH:C/.*-p([0-9]+$)/\1/}
 .endif
 PKG_VERSION=   ${_REVISION}${EXTRA_REVISION}
 .endif
+.endif # !defined(_MKSHOWCONFIG)
 
 KNOWN_ARCHES?= aarch64/arm64 \
amd64 \
@@ -541,11 +551,13 @@ _t=   ${TARGET_ARCH}/${TARGET}
 .endif
 .endfor
 
+.if !defined(_MKSHOWCONFIG)
 _CPUTYPE!= MAKEFLAGS= CPUTYPE=${_TARGET_CPUTYPE} ${MAKE} -f /dev/null \
-m ${.CURDIR}/share/mk MK_AUTO_OBJ=no -V CPUTYPE
 .if ${_CPUTYPE} != ${_TARGET_CPUTYPE}
 .error CPUTYPE global should be set with ?=.
 .endif
+.endif
 .if make(buildworld)
 BUILD_ARCH!=   uname -p
 .if ${MACHINE_ARCH} != ${BUILD_ARCH}
@@ -763,7 +775,7 @@ LIBCOMPAT= SOFT
 # to get updated host tools.
 .if ${MK_META_MODE} == "yes" && defined(NO_CLEAN) && \
 !defined(NO_META_IGNORE_HOST) && !defined(NO_META_IGNORE_HOST_HEADERS) && \
-!make(showconfig)
+!defined(_MKSHOWCONFIG)
 # r318736 - ino64 major ABI breakage
 META_MODE_BAD_ABI_VERS+=   1200031
 
@@ -881,37 +893,33 @@ _cleanobj_fast_depend_hack: .PHONY
 # 20180525  r334224  vadvise
 # 20180604  r334626  brk sbrk
 .for f in brk exect fstat fstatat fstatfs getdirentries getfsstat sbrk 
setlogin shmat sigreturn statfs vadvise
-.if exists(${OBJTOP}/lib/libc/.depend.${f}.o)
-   @if egrep -qw '${f}\.[sS]' \
-   ${OBJTOP}/lib/libc/.depend.${f}.o; then \
-   echo Removing stale dependencies for ${f} syscall wrappers; \
+   @if [ -e "${OBJTOP}/lib/libc/.depend.${f}.o" ] && \
+   egrep -qw '${f}\.[sS]' ${OBJTOP}/lib/libc/.depend.${f}.o; then \
+   echo "Removing stale dependencies for ${f} syscall wrappers"; \
rm -f ${OBJTOP}/lib/libc/.depend.${f}.* \
   ${LIBCOMPAT:D${LIBCOMPAT_OBJTOP}/lib/libc/.depend.${f}.*}; \
fi
-.endif
 .endfor
 # 20170607 remove stale dependencies for utimens* wrappers removed in r319663
 .for f in futimens utimensat
-.if exists(${OBJTOP}/lib/libc/.depend.${f}.o)
-   @if egrep -q 

Re: svn commit: r335394 - head

[Bryan Drewery]

On 6/20/2018 10:00 AM, John Baldwin wrote:
> On 6/19/18 4:40 PM, Bryan Drewery wrote:
>> Author: bdrewery
>> Date: Tue Jun 19 23:40:42 2018
>> New Revision: 335394
>> URL: https://svnweb.freebsd.org/changeset/base/335394
>>
>> Log:
>>   Fix detection for binutils bootstrap package.
>>   
>>   The path was changed recently in the port to be the full target triple.
> 
> Except this doesn't work either.  The TARGET_TRIPLE the package uses is based
> on the build _host_ machine, so if you are building a current MIPS world
> on an 11.2 host (for example), TARGET_TRIPLE will use '12.0' but won't work
> because the package installed on the host will be using '11.2'.
> 

Oops...

> I want to revert the cross binutils packages back to the old naming scheme
> as that makes more sense (and it is what configure scripts keep looking for,
> I have to create symlinks for gdb's ./configure script to DTRT when 
> cross-building
> for example.)
> 

I'm all for reverting that.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r335394 - head

[John Baldwin]

On 6/19/18 4:40 PM, Bryan Drewery wrote:
> Author: bdrewery
> Date: Tue Jun 19 23:40:42 2018
> New Revision: 335394
> URL: https://svnweb.freebsd.org/changeset/base/335394
> 
> Log:
>   Fix detection for binutils bootstrap package.
>   
>   The path was changed recently in the port to be the full target triple.

Except this doesn't work either.  The TARGET_TRIPLE the package uses is based
on the build _host_ machine, so if you are building a current MIPS world
on an 11.2 host (for example), TARGET_TRIPLE will use '12.0' but won't work
because the package installed on the host will be using '11.2'.

I want to revert the cross binutils packages back to the old naming scheme
as that makes more sense (and it is what configure scripts keep looking for,
I have to create symlinks for gdb's ./configure script to DTRT when 
cross-building
for example.)

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Stephen Kiernan]

On Wed, Jun 20, 2018 at 9:30 AM, Conrad Meyer  wrote:
>
> Please look at the actual code size and layout of the sha1 support
> module and tell me that is a burden for Juniper to maintain in their
> downstream tree, rather than just getting angry about the suggestion
> we don't introduce novel, insecurity cryptographic designs.
>

I have no problem removing the SHA1 and RIPEMD implementations.
It's a minor change and very little code for others to have to maintain if
needed.
That was the intention of fingerprint module implementation, to try to make
it easy
to add/remote different algorithms. It could even potentially be done as a
port,
if people are keen to having to pre-load a module to get the support (I
know that
that's a bit of a grey area without a verified loader and secureboot or
similar
functionality to protect integrity.)

I think some of the issue was this code has been looking for eyes to give a
good
look for over 2 years (even before the review was posted, it was available
in my
GitHub branch for at least 1 year prior, if not longer.)

As for some of the other issues, note my comment in the review
https://reviews.freebsd.org/D8554:
"Note I have some updates that I have been working on to handle the
meta-data
store better in SMP environments. So there will be updates to these reviews,
hopefully in the near future, time permitting."

And I was working on those sets of changes, when work and family didn't
steal away time. I was told that some discussion happened at BSDCan this
year in such that veriexec should go in as-is so it would be there, which
is why
the commit happened (given the review was approved to land back in January.)

I suppose I should have just kept with my original intention to fix the
issues and
update the review(s).

Hopefully now it will mean it will get the right eyes on it. I don't
believe I need
to dig up all the e-mail threads and chat logs for IRC where I asked for
help and
was given pointers to folks to contact and we ended up here.

It's a better use of everyone's time to just cool down, back things out,
get new
reviews updated and provide constructive feedback.

So far this experience (I am not pointing at you here) has been a mixed set
of
constructive comments and outright flaming. The latter of which is never
going
to help get the right results and could be one of the reasons that a number
of
folks give up contributing to FreeBSD.

-Steve
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Ian Lepore]

On Wed, 2018-06-20 at 09:30 -0700, Conrad Meyer wrote:
> Ian,
> 
> On Wed, Jun 20, 2018 at 8:58 AM, Ian Lepore  wrote:
> > 
> > And I request exactly the opposite: reject the complaining of people
> > who think all the world is a 256-core 5ghz server
> First: no need to be so rude to other committers.  The hyperbole
> doesn't help anyone and doesn't help communicate your point clearly.
> It's just verbal diarrhea.  Please try to be excellent to each other.
> 
> > 
> > and leave in the
> > option to use faster algorithms on real-world hardware used by real-
> > world vendors who need some option other than "rev your hardware every
> > 18 months to keep up with the software or get out of the business."
> Second: You have very much misread my complaints and very much
> misunderstand the cryptographic algorithm landscape if that is your
> conclusion.
> 
> See my earlier email,
> https://lists.freebsd.org/pipermail/svn-src-all/2018-June/166107.html
> ; in particular I would quote:
> 
> > 
> > Performance is absolutely not a reason to use a known weak hash
> > algorithm in 2018, especially when the feature as-committed has so
> > many other glaring performance problems.  If you care about MAC
> > performance in a secure algorithm in 2018, perhaps look at any of
> > these great options:
> > 
> > * Blake2-b
> > * Poly1305-{AES,Salsa,ChaCha}
> > 
> > They have highly efficient software implementations *that smoke SHA-2
> > and don't have SHA-1's known weakness*.  Blake2 is even in-tree
> > already.
> (Removing Keccak, which I had forgotten has crap performance in
> software — mea culpa.)
> 
> > 
> > Stronger algorithm options, yes. Even making stronger options the
> > default, yes.
> "More secure than SHA1" and "faster than SHA1" are *not* mutually exclusive.
> 
> > 
> > But removing viable options which are endorsed by the
> > people who actually set the standards, no.
> No one actually endorses SHA1 in new designs.  No one endorses RIPEMD at all.
> 
> Please look at the actual code size and layout of the sha1 support
> module and tell me that is a burden for Juniper to maintain in their
> downstream tree, rather than just getting angry about the suggestion
> we don't introduce novel, insecurity cryptographic designs.
> 
> Thank you,
> Conrad
> 

I have zero interest in arguing with you (or anybody) about this. I've
expessed my opinion on the subject and have nothing more to say.

-- Ian
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot

[Konstantin Belousov]

On Wed, Jun 20, 2018 at 10:05:16AM -0600, Warner Losh wrote:
> On Wed, Jun 20, 2018 at 10:03 AM, Konstantin Belousov 
> wrote:
> 
> > On Wed, Jun 20, 2018 at 09:43:31AM -0600, Ian Lepore wrote:
> > > On Wed, 2018-06-20 at 12:22 +0300, Konstantin Belousov wrote:
> > > > On Tue, Jun 19, 2018 at 08:34:18PM -0400, Allan Jude wrote:
> > > > >
> > > > > On 2018-06-17 07:32, Eugene Grosbein wrote:
> > > > > >
> > > > > > 17.06.2018 10:18, Allan Jude wrote:
> > > > > >
> > > > > > >
> > > > > > > Author: allanjude
> > > > > > > Date: Sun Jun 17 03:18:56 2018
> > > > > > > New Revision: 335276
> > > > > > > URL: https://svnweb.freebsd.org/changeset/base/335276
> > > > > > >
> > > > > > > Log:
> > > > > > >   gptboot, zfsboot, gptzfsboot: Enable the video and serial
> > consoles early
> > > > > > >
> > > > > > >   Normally the serial console is not enabled until /boot.config
> > is read and
> > > > > > >   we know how the serial console should be
> > configured.  Initialize the
> > > > > > >   consoles early in 'dual' mode (serial & keyboard) with a
> > default serial
> > > > > > >   rate of 115200. Then serial is re-initialized once the disk is
> > decrypted
> > > > > > >   and the /boot.config file can be read.
> > > > > > >
> > > > > > >   This allows the GELIBoot passphrase to be provided via the
> > serial console.
> > > > > > >
> > > > > > >   PR: 221526
> > > > > > >   Requested by:   many
> > > > > > >   Reviewed by:imp
> > > > > > >   Sponsored by:   Klara Systems
> > > > > > >   Differential Revision:  https://reviews.freebsd.org/D15862
> > > > > > I had several cases when booting FreeBSD/amd64 with motherboard
> > having no serial ports
> > > > > > hang hard early at boot unless I rebuilt boot media configuring it
> > to NOT try accessing
> > > > > > missing serial ports. I even could reproduce that with VirtualBox
> > machine configured
> > > > > > with no serial ports (not same as existing bug inactive serial
> > port).
> > > > > >
> > > > > > Should there be some way to disable this serial ports
> > configuration at compile time?
> > > > > >
> > > > > >
> > > > > >
> > > > > I think what we'll do it compile it both ways, and use the non-serial
> > > > > one by default, because it is safer. Then you can just use
> > > > > 'gptboot-serial' if you want serial support.
> > > > >
> > > > > This will likely make Warner a bit sad, since we are just finally
> > > > > getting around to reducing the number of different bootcode files.
> > > > I think we should follow the hardware trends there and apply a policy
> > > > where new features are not added to the CSM boot. All modern machines
> > > > can be booted in UEFI mode, and if some modern machine cannot, then we
> > > > need it fixed.  We should encourage users to make new installs boot by
> > > > UEFI.
> > > >
> > > > The feature from the commit is only relevant for machines that require
> > > > CSM boot or do not have UEFI option at all, am I right ? With the
> > policy
> > > > applied, an additional CSM-boot bootblock would be not shipped.
> > > >
> > >
> > > I think it is far too early to say that the code for booting without
> > > efi is abandonware. I have half a dozen x86 boxes in use here, and only
> > > one of them is even able to boot efi, and its default resolution in efi
> > > mode confuses the kvm switch it's connected to, so even on that I have
> > > to use legacy bios boot.
> > I do not propose to abandon bios boot, or even to declare it legacy
> > with the proper meaning. I mean that CSM is disappearing on the newest
> > platforms, and should become only used on old machines or i386.  With that
> > attitude, adding a features for it, esp. by the cost of the user confusion,
> > is not worth the efforts.  It still should be maintained for the foreseable
> > future.
> >
> > If the machines where you get the trouble is newer than say 5 years,
> > then they should boot with UEFI.  If not, the problem in loader.efi
> > needs to be fixed.
> >
> 
> There is no problem in loader.efi that's specific to geli. It already uses
> the UEFI boot loader config. While there's some issues downstream (eg
> kernel messages), this specific issue is a non-issue for loader.efi.

I referenced the problems that Ian has with UEFI boot on his machines,
not the serial console and geli change above.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Conrad Meyer]

Ian,

On Wed, Jun 20, 2018 at 8:58 AM, Ian Lepore  wrote:
> And I request exactly the opposite: reject the complaining of people
> who think all the world is a 256-core 5ghz server

First: no need to be so rude to other committers.  The hyperbole
doesn't help anyone and doesn't help communicate your point clearly.
It's just verbal diarrhea.  Please try to be excellent to each other.

> and leave in the
> option to use faster algorithms on real-world hardware used by real-
> world vendors who need some option other than "rev your hardware every
> 18 months to keep up with the software or get out of the business."

Second: You have very much misread my complaints and very much
misunderstand the cryptographic algorithm landscape if that is your
conclusion.

See my earlier email,
https://lists.freebsd.org/pipermail/svn-src-all/2018-June/166107.html
; in particular I would quote:

> Performance is absolutely not a reason to use a known weak hash
> algorithm in 2018, especially when the feature as-committed has so
> many other glaring performance problems.  If you care about MAC
> performance in a secure algorithm in 2018, perhaps look at any of
> these great options:
>
> * Blake2-b
> * Poly1305-{AES,Salsa,ChaCha}
>
> They have highly efficient software implementations *that smoke SHA-2
> and don't have SHA-1's known weakness*.  Blake2 is even in-tree
> already.

(Removing Keccak, which I had forgotten has crap performance in
software — mea culpa.)

> Stronger algorithm options, yes. Even making stronger options the
> default, yes.

"More secure than SHA1" and "faster than SHA1" are *not* mutually exclusive.

> But removing viable options which are endorsed by the
> people who actually set the standards, no.

No one actually endorses SHA1 in new designs.  No one endorses RIPEMD at all.

Please look at the actual code size and layout of the sha1 support
module and tell me that is a burden for Juniper to maintain in their
downstream tree, rather than just getting angry about the suggestion
we don't introduce novel, insecurity cryptographic designs.

Thank you,
Conrad
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335451 - head/share/man/man5

[Bryan Drewery]

Author: bdrewery
Date: Wed Jun 20 16:15:03 2018
New Revision: 335451
URL: https://svnweb.freebsd.org/changeset/base/335451

Log:
  Regenerate for SYSTEM_LINKER

Modified:
  head/share/man/man5/src.conf.5

Modified: head/share/man/man5/src.conf.5
==
--- head/share/man/man5/src.conf.5  Wed Jun 20 16:10:14 2018
(r335450)
+++ head/share/man/man5/src.conf.5  Wed Jun 20 16:15:03 2018
(r335451)
@@ -1,6 +1,6 @@
 .\" DO NOT EDIT-- this file is @generated by tools/build/options/makeman.
 .\" $FreeBSD$
-.Dd June 15, 2018
+.Dd June 20, 2018
 .Dt SRC.CONF 5
 .Os
 .Sh NAME
@@ -1481,6 +1481,22 @@ The
 and
 .Va WITHOUT_GCC
 options control those.
+.It Va WITHOUT_SYSTEM_LINKER
+Set to not opportunistically skip building a cross-linker during the
+bootstrap phase of the build.
+Normally, if the currently installed linker matches the planned bootstrap
+linker type and revision, then it will not be built.
+This does not prevent a linker from being built for installation though,
+only for building one for the build itself.
+The
+.Va WITHOUT_LLD
+and
+.Va WITHOUT_BINUTILS
+options control those.
+.Pp
+This option is only relevant when
+.Va WITH_LLD_BOOTSTRAP
+is set.
 .It Va WITHOUT_TALK
 Set to not build or install
 .Xr talk 1
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335450 - in head: . share/mk tools/build/options

[Bryan Drewery]

Author: bdrewery
Date: Wed Jun 20 16:10:14 2018
New Revision: 335450
URL: https://svnweb.freebsd.org/changeset/base/335450

Log:
  Add WITH_SYSTEM_LINKER, on by default, that avoids building lld when possible.
  
  This works similar to WITH_SYSTEM_COMPILER added in r300354.  It only
  supports lld via WITH_LLD_BOOTSTRAP.
  
  When both SYSTEM_COMPILER and SYSTEM_LINKER logic passes then libclang
  will not build in cross-tools.  If either check fails though then
  libclang is built.
  
  The .info is reworked to notify when libclang will be built since if
  either clang or lld needs to be rebuilt, but not the other, the
  notification can lead to confusion on why "clang is building".
  
  -fuse-ld= is not used with this method so some combinations of compiler
  and linker are expected to fail.
  
  A new 'make test-system-linker' target is added to see the logic results.
  
  Makefile.inc1:
CROSS_BINUTILS_PREFIX support had to be moved higher up so that XLD
could be set and MK_LLD_BOOTSTRAP disabled before checking SYSTEM_LINKER
logic as done with SYSTEM_COMPILER.  This also required moving where
bsd.linker.mk was read since XLD needs to be set before parsing it.  This
creates a situation where src.opts.mk can not test LINKER_FEATURES or
add LLD_BOOTSTAP to BROKEN_OPTIONS.
  
  Reviewed by:  emaste (earlier version)
  Sponsored by: Dell EMC
  Differential Revision:https://reviews.freebsd.org/D15894

Added:
  head/tools/build/options/WITHOUT_SYSTEM_LINKER   (contents, props changed)
  head/tools/build/options/WITH_SYSTEM_LINKER   (contents, props changed)
Modified:
  head/Makefile
  head/Makefile.inc1
  head/share/mk/bsd.compiler.mk
  head/share/mk/bsd.linker.mk
  head/share/mk/src.opts.mk

Modified: head/Makefile
==
--- head/Makefile   Wed Jun 20 16:10:10 2018(r335449)
+++ head/Makefile   Wed Jun 20 16:10:14 2018(r335450)
@@ -143,7 +143,7 @@ TGTS=   all all-man buildenv buildenvvars buildkernel bu
stage-packages \
create-packages-world create-packages-kernel create-packages \
packages installconfig real-packages sign-packages package-pkg \
-   print-dir test-system-compiler
+   print-dir test-system-compiler test-system-linker
 
 # These targets require a TARGET and TARGET_ARCH be defined.
 XTGTS= native-xtools native-xtools-install xdev xdev-build xdev-install \
@@ -168,7 +168,7 @@ META_TGT_WHITELIST+= \
_* build32 buildfiles buildincludes buildkernel buildsoft \
buildworld everything kernel-toolchain kernel-toolchains kernel \
kernels libraries native-xtools showconfig test-system-compiler \
-   tinderbox toolchain \
+   test-system-linker tinderbox toolchain \
toolchains universe world worlds xdev xdev-build
 
 .ORDER: buildworld installworld

Modified: head/Makefile.inc1
==
--- head/Makefile.inc1  Wed Jun 20 16:10:10 2018(r335449)
+++ head/Makefile.inc1  Wed Jun 20 16:10:14 2018(r335450)
@@ -97,9 +97,74 @@ MK_GCC_BOOTSTRAP=no
 # Pull in COMPILER_TYPE and COMPILER_FREEBSD_VERSION early. Pull it from the
 # tree to be friendlier to foreign OS builds. It's safe to do so 
unconditionally
 # here since we will always have the right make, unlike in src/Makefile
+# Don't include bsd.linker.mk yet until XBINUTILS is handled (after 
src.opts.mk)
+_NO_INCLUDE_LINKERMK=  t
 .include "share/mk/bsd.compiler.mk"
+.undef _NO_INCLUDE_LINKERMK
+# src.opts.mk depends on COMPILER_FEATURES
 .include "share/mk/src.opts.mk"
 
+.if ${TARGET} == ${MACHINE}
+TARGET_CPUTYPE?=${CPUTYPE}
+.else
+TARGET_CPUTYPE?=
+.endif
+.if !empty(TARGET_CPUTYPE)
+_TARGET_CPUTYPE=${TARGET_CPUTYPE}
+.else
+_TARGET_CPUTYPE=dummy
+.endif
+.if ${TARGET} == "arm"
+.if ${TARGET_ARCH:Marmv[67]*} != "" && ${TARGET_CPUTYPE:M*soft*} == ""
+TARGET_ABI=gnueabihf
+.else
+TARGET_ABI=gnueabi
+.endif
+.endif
+MACHINE_ABI?=  unknown
+MACHINE_TRIPLE?=${MACHINE_ARCH:S/amd64/x86_64/:C/hf$//:S/mipsn32/mips64/}-${MACHINE_ABI}-freebsd12.0
+TARGET_ABI?=   unknown
+TARGET_TRIPLE?=
${TARGET_ARCH:S/amd64/x86_64/:C/hf$//:S/mipsn32/mips64/}-${TARGET_ABI}-freebsd12.0
+
+# Handle external binutils.
+.if defined(CROSS_TOOLCHAIN_PREFIX)
+CROSS_BINUTILS_PREFIX?=${CROSS_TOOLCHAIN_PREFIX}
+.endif
+# If we do not have a bootstrap binutils (because the in-tree one does not
+# support the target architecture), provide a default cross-binutils prefix.
+# This allows riscv64 builds, for example, to automatically use the
+# riscv64-binutils port or package.
+.if !make(showconfig)
+.if !empty(BROKEN_OPTIONS:MBINUTILS_BOOTSTRAP) && \
+${MK_LLD_BOOTSTRAP} == "no" && \
+!defined(CROSS_BINUTILS_PREFIX)
+CROSS_BINUTILS_PREFIX=/usr/local/${TARGET_TRIPLE}/bin/
+.if !exists(${CROSS_BINUTILS_PREFIX})
+.error In-tree binutils does not support the ${TARGET_ARCH} 

svn commit: r335449 - head/lib/clang/libllvm

[Bryan Drewery]

Author: bdrewery
Date: Wed Jun 20 16:10:10 2018
New Revision: 335449
URL: https://svnweb.freebsd.org/changeset/base/335449

Log:
  Fix sources needed for lld.
  
  lld always needs these DWARF sources, as well as other default and extra
  tools. XDL seems to be the best fit list.
  
  Remove MK_LLD_IS_LD check from SRCS_MIW which is now reduced to just a
  few files for llvm-objdump.
  
  Sponsored by: Dell EMC
  Differential Revision:https://reviews.freebsd.org/D15915

Modified:
  head/lib/clang/libllvm/Makefile

Modified: head/lib/clang/libllvm/Makefile
==
--- head/lib/clang/libllvm/Makefile Wed Jun 20 16:10:07 2018
(r335448)
+++ head/lib/clang/libllvm/Makefile Wed Jun 20 16:10:10 2018
(r335449)
@@ -371,30 +371,30 @@ SRCS_MIN+=
DebugInfo/CodeView/TypeIndexDiscovery.cpp
 SRCS_MIN+= DebugInfo/CodeView/TypeRecordMapping.cpp
 SRCS_MIN+= DebugInfo/CodeView/TypeStreamMerger.cpp
 SRCS_MIN+= DebugInfo/CodeView/TypeTableCollection.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFAbbreviationDeclaration.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFAcceleratorTable.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFCompileUnit.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFContext.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDataExtractor.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugAbbrev.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugArangeSet.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugAranges.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugFrame.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugInfoEntry.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugLine.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugLoc.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugMacro.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugPubTable.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDebugRangeList.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFDie.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFExpression.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFFormValue.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFGdbIndex.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFTypeUnit.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFUnit.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFUnitIndex.cpp
-SRCS_MIW+= DebugInfo/DWARF/DWARFVerifier.cpp
-SRCS_MIW+= DebugInfo/DWARF/SyntaxHighlighting.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFAbbreviationDeclaration.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFAcceleratorTable.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFCompileUnit.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFContext.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDataExtractor.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugAbbrev.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugArangeSet.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugAranges.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugFrame.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugInfoEntry.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugLine.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugLoc.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugMacro.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugPubTable.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDebugRangeList.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFDie.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFExpression.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFFormValue.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFGdbIndex.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFTypeUnit.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFUnit.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFUnitIndex.cpp
+SRCS_XDL+= DebugInfo/DWARF/DWARFVerifier.cpp
+SRCS_XDL+= DebugInfo/DWARF/SyntaxHighlighting.cpp
 SRCS_MIN+= DebugInfo/MSF/MSFBuilder.cpp
 SRCS_MIN+= DebugInfo/MSF/MSFCommon.cpp
 SRCS_MIN+= DebugInfo/MSF/MSFError.cpp
@@ -1275,7 +1275,7 @@ SRCS_EXT+=Transforms/Vectorize/Vectorize.cpp
 SRCS_EXT+= XRay/InstrumentationMap.cpp
 
 SRCS_ALL+= ${SRCS_MIN}
-.if !defined(TOOLS_PREFIX) || ${MK_LLD_IS_LD} != "no"
+.if !defined(TOOLS_PREFIX)
 SRCS_ALL+= ${SRCS_MIW}
 .endif
 .if ${MK_CLANG_EXTRAS} != "no"
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335447 - in head: . gnu/usr.bin/binutils/ld usr.bin/clang/lld

[Bryan Drewery]

Author: bdrewery
Date: Wed Jun 20 16:10:02 2018
New Revision: 335447
URL: https://svnweb.freebsd.org/changeset/base/335447

Log:
  Rework how the ld link is handled in WORLDTMP from r322811.
  
  LLD_BOOTSTRAP (build) is independent of LLD_IS_LD (installed) so they
  should not be based on each other.
  
  This is related to upcoming WITH_SYSTEM_LINKER work.
  
  Reviewed by:  emaste
  Sponsored by: Dell EMC
  Differential Revision:https://reviews.freebsd.org/D15836

Modified:
  head/Makefile.inc1
  head/gnu/usr.bin/binutils/ld/Makefile
  head/usr.bin/clang/lld/Makefile

Modified: head/Makefile.inc1
==
--- head/Makefile.inc1  Wed Jun 20 16:07:35 2018(r335446)
+++ head/Makefile.inc1  Wed Jun 20 16:10:02 2018(r335447)
@@ -586,7 +586,7 @@ TMAKE=  \
 # TOOLS_PREFIX set in BMAKE
 XMAKE= ${BMAKE} \
TARGET=${TARGET} TARGET_ARCH=${TARGET_ARCH} \
-   MK_GDB=no MK_LLD_IS_LD=${MK_LLD_BOOTSTRAP} MK_TESTS=no
+   MK_GDB=no MK_TESTS=no
 
 # kernel-tools stage
 KTMAKEENV= INSTALL="sh ${.CURDIR}/tools/install.sh" \

Modified: head/gnu/usr.bin/binutils/ld/Makefile
==
--- head/gnu/usr.bin/binutils/ld/Makefile   Wed Jun 20 16:07:35 2018
(r335446)
+++ head/gnu/usr.bin/binutils/ld/Makefile   Wed Jun 20 16:10:02 2018
(r335447)
@@ -7,8 +7,10 @@ ELF_SCR_EXT=   x xbn xc xd xdc xdw xn xr xs xsc xsw xu x
 .PATH: ${SRCDIR}/ld
 
 PROG=  ld.bfd
-.if ${MK_LLD_IS_LD} == "no"
+.if (!defined(TOOLS_PREFIX) && ${MK_LLD_IS_LD} == "no") || \
+(defined(TOOLS_PREFIX) && ${MK_LLD_BOOTSTRAP} == "no")
 MAN=   ld.1
+LINKS= ${BINDIR}/ld.bfd ${BINDIR}/ld
 .else
 MAN=   ld.bfd.1
 CLEANFILES+=   ld.bfd.1
@@ -57,9 +59,6 @@ CLEANFILES+=  ldemul-list.h stringify.sed
 
 FILES= ${LDSCRIPTS:S|^|ldscripts/|}
 FILESDIR=  ${SCRIPTDIR}
-.if ${MK_LLD_IS_LD} == "no"
-LINKS= ${BINDIR}/ld.bfd ${BINDIR}/ld
-.endif
 
 HOST=  ${TARGET_TUPLE}
 LIBSEARCHPATH= \"=/lib\":\"=/usr/lib\"

Modified: head/usr.bin/clang/lld/Makefile
==
--- head/usr.bin/clang/lld/Makefile Wed Jun 20 16:07:35 2018
(r335446)
+++ head/usr.bin/clang/lld/Makefile Wed Jun 20 16:10:02 2018
(r335447)
@@ -8,7 +8,8 @@ LLD_SRCS=   ${LLVM_SRCS}/tools/lld
 PACKAGE=   lld
 PROG_CXX=  ld.lld
 
-.if ${MK_LLD_IS_LD} != "no"
+.if (!defined(TOOLS_PREFIX) && ${MK_LLD_IS_LD} != "no") || \
+(defined(TOOLS_PREFIX) && ${MK_LLD_BOOTSTRAP} != "no")
 SYMLINKS=  ${PROG_CXX} ${BINDIR}/ld
 MLINKS=ld.lld.1 ld.1
 .endif
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Conrad Meyer]

I want to preface this by saying: this discussion should be happening
in either arch@ or phabricator, after the patch series was temporarily
reverted pending necessary improvements.  I have asked for the series
to be reverted and am still waiting on that.

I am happy to promise to respond promptly to updates on this
particular series so you are not waiting for two years again.

I think it's quite close to something reasonably general, but as-is,
it is worse than useless — it promises a security feature but _does
not deliver it_, which is the "emperor's new clothes" of security.

On Tue, Jun 19, 2018 at 11:21 PM, Simon J. Gerraty  wrote:
> Conrad Meyer  wrote:
>> First and foremost: nothing is actually signed, anywhere.  The
>
> The signing of manifests is external.  The veriexecctl tool is I assume
> a straight copy of what's in NetBSD (I've not looked at it in at least a
> decade).

The signing of manifests does not exist in the patch series committed.

(If NetBSD does something broken, that is not an excuse to copy it.)

> A veriexec loader that leverages signed manifests requires some signing
> infra.  That's a big topic all by itself.

It *may* require that.  However, even without that, admins could
reasonably manage their own PKI in some fashion, independent of
FreeBSD's infra.  But it requires the support code to verify
signatures, as in the "verify" part of veriexec, which is wholly
absent.

> As I mentioned in my talk at BSDCan,

(FWIW, I was not at your talk, and it is not a justification for bad
design or implementation anyway.)

> the signing server we use is open
> source and handles pretty much anything OpenSSL can, as well as OpenPGP
> (and others).

It doesn't really matter if there's a signing server, because nothing
in the patch series *verifies* signatures.

> Tweaking the veriexec loader to only process manifests after
> verification is not hard

Then I even more do not understand why it was not done prior to commit.

> - one of the first things I did when pulling
> veriexec into Junos almost 15 years ago.
>
>> As a corollary to the above, the name "signature file" is used
>> repeatedly in the code, which is misleading.  The file contains hashes
>> (digests), not signatures (MACs).  The file itself is unsigned.
>> Nothing about this has signatures.
>
> NetBSD refers to the hashes as fingerprints - AFAIK that terminology is
> retained.

Fingerprints is fine, "signatures" is not.  "Signatures file" is used
to refer to the manifest file, which only contains fingerprints, in
multiple locations in the code.

> If the term signature is used to refer to anything other than the signed
> manifests that should be fixed.

Should have been fixed prior to commit, yes.

>> There's absolutely no reason to use sha1 or ripemd in new designs.
>> These should be removed.
>
> Sorry I disagree - not with ripem (we never supported that or any of the
> non-NIST approved hashes), but sha1 is still approved by NIST for
> firmware integrity checks - which is what this is, and sha1 is cheaper
> than sha256.

Again — this is a discussion for arch or phabricator, with the series
reverted first.

I reckon you're wrong.  If you're unwilling to trust me, I believe you
should get and accept input from a 3rd party vaguely familiar with
cryptography (maybe cperciva@ or gordon@ or delphij@) before
introducing SHA1 or Ripe-MD in a novel integrity-protection design.

(Some modern Intel and AMD CPUs have intrinsics support for SHA-2, and
on those machines SHA-2 256 is about the same performance as SHA-1.)

Performance is absolutely not a reason to use a known weak hash
algorithm in 2018, especially when the feature as-committed has so
many other glaring performance problems.  If you care about MAC
performance in a secure algorithm in 2018, perhaps look at any of
these great options:

* SHA-3 (Keccak)
* Blake2-b
* Poly1305-{AES,Salsa,ChaCha}

All have highly efficient software implementations that smoke SHA-2
and don't have SHA-1's known weakness.  Blake2 is even in-tree
already.

> As I mentioned in my talk we've included support for sha256 for 10+
> years,

FreeBSD has had this code for 0 years.  It's a novel feature here.
There is no reason to introduce SHA-1 in novel security features in
2018.

> but do not plan to drop sha1 until NIST deprecate it for that
> purpose since boot time is a very sensitive subject for us.

See above.  There are lots of secure hashes faster than SHA-1 without
its known weaknesses.

>> The patchset is littered with style issues.  One fairly obvious issue
>> is mixed indentation styles — some files vary between space and tab
>> indentation from line to line.
>
> You can probably blame me for some of that.
> I only recently found a style9.el that does a half decent job of
> formatting per style(9).

To commit to the tree, you are supposed to be able to get it right, or
at least close to right.

>> Please revert this patchset.  It's not ready.

>> - Maybe use HMACs instead of raw hashes
>
> Why?

svn commit: r335448 - in head: . lib/clang/libllvm

[Bryan Drewery]

Author: bdrewery
Date: Wed Jun 20 16:10:07 2018
New Revision: 335448
URL: https://svnweb.freebsd.org/changeset/base/335448

Log:
  Rework WITHOUT_LLD/TOOLCHAIN fix from r327892 for cross-tools.
  
  MK_LLD is for the installed lld while MK_LLD_BOOTSTRAP is for the build
  tool.  For WITH_SYSTEM_LINKER it is necesarry to separate the logic of
  these two.  When building libllvm TOOLS_PREFIX will be defined and
  MK_LLD_BOOTSTRAP should be checked instead.
  
  Sponsored by: Dell EMC
  Differential Revision:https://reviews.freebsd.org/D15837

Modified:
  head/Makefile.inc1
  head/lib/clang/libllvm/Makefile

Modified: head/Makefile.inc1
==
--- head/Makefile.inc1  Wed Jun 20 16:10:02 2018(r335447)
+++ head/Makefile.inc1  Wed Jun 20 16:10:07 2018(r335448)
@@ -562,7 +562,6 @@ BSARGS= DESTDIR= \
-DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no \
MK_CLANG_EXTRAS=no MK_CLANG_FULL=no \
MK_LLDB=no MK_TESTS=no \
-   MK_LLD=${MK_LLD_BOOTSTRAP} \
MK_INCLUDES=yes
 
 BMAKE= \

Modified: head/lib/clang/libllvm/Makefile
==
--- head/lib/clang/libllvm/Makefile Wed Jun 20 16:10:02 2018
(r335447)
+++ head/lib/clang/libllvm/Makefile Wed Jun 20 16:10:07 2018
(r335448)
@@ -1284,16 +1284,19 @@ SRCS_ALL+=  ${SRCS_EXT}
 .if ${MK_CLANG_FULL} != "no"
 SRCS_ALL+= ${SRCS_FUL}
 .endif
-.if ${MK_CLANG_EXTRAS} != "no" || ${MK_LLD} != "no"
+.if ${MK_CLANG_EXTRAS} != "no" || ${MK_LLD} != "no" || \
+(defined(TOOLS_PREFIX) && ${MK_LLD_BOOTSTRAP} != "no")
 SRCS_ALL+= ${SRCS_EXL}
 .endif
-.if ${MK_LLD} != "no"
+.if ${MK_LLD} != "no" || \
+(defined(TOOLS_PREFIX) && ${MK_LLD_BOOTSTRAP} != "no")
 SRCS_ALL+= ${SRCS_LLD}
 .endif
 .if ${MK_CLANG_EXTRAS} != "no" || ${MK_LLDB} != "no"
 SRCS_ALL+= ${SRCS_XDB}
 .endif
-.if ${MK_CLANG_EXTRAS} != "no" || ${MK_LLDB} != "no" || ${MK_LLD} != "no"
+.if ${MK_CLANG_EXTRAS} != "no" || ${MK_LLDB} != "no" || ${MK_LLD} != "no" || \
+(defined(TOOLS_PREFIX) && ${MK_LLD_BOOTSTRAP} != "no")
 SRCS_ALL+= ${SRCS_XDL}
 .endif
 .if ${MK_CLANG_EXTRAS} != "no" || ${MK_LLDB} != "no" || !defined(TOOLS_PREFIX)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335446 - in head/sys: arm64/arm64 arm64/include kern

[Emmanuel Vadot]

Author: manu
Date: Wed Jun 20 16:07:35 2018
New Revision: 335446
URL: https://svnweb.freebsd.org/changeset/base/335446

Log:
  Add pmap_mapdev_attr for arm64
  
  This is needed for efifb.
  arm and ricv pmap (the two arch with arm64 that uses subr_devmap) have very
  different implementation so for now only add this for arm64.
  
  Tested with efifb on Pine64 with a few other patches.
  
  Reviewed by:  cognet
  Differential Revision:https://reviews.freebsd.org/D15294

Modified:
  head/sys/arm64/arm64/pmap.c
  head/sys/arm64/include/pmap.h
  head/sys/kern/subr_devmap.c

Modified: head/sys/arm64/arm64/pmap.c
==
--- head/sys/arm64/arm64/pmap.c Wed Jun 20 15:27:09 2018(r335445)
+++ head/sys/arm64/arm64/pmap.c Wed Jun 20 16:07:35 2018(r335446)
@@ -1142,7 +1142,7 @@ pmap_kextract(vm_offset_t va)
  * Low level mapping routines.
  ***/
 
-static void
+void
 pmap_kenter(vm_offset_t sva, vm_size_t size, vm_paddr_t pa, int mode)
 {
pd_entry_t *pde;

Modified: head/sys/arm64/include/pmap.h
==
--- head/sys/arm64/include/pmap.h   Wed Jun 20 15:27:09 2018
(r335445)
+++ head/sys/arm64/include/pmap.h   Wed Jun 20 16:07:35 2018
(r335446)
@@ -140,10 +140,12 @@ extern vm_offset_t virtual_end;
va) | (pa)) & L1_OFFSET) == 0 && (size) >= L1_SIZE)
 
 void   pmap_bootstrap(vm_offset_t, vm_offset_t, vm_paddr_t, vm_size_t);
+void   pmap_kenter(vm_offset_t sva, vm_size_t size, vm_paddr_t pa, int mode);
 void   pmap_kenter_device(vm_offset_t, vm_size_t, vm_paddr_t);
 vm_paddr_t pmap_kextract(vm_offset_t va);
 void   pmap_kremove(vm_offset_t);
 void   pmap_kremove_device(vm_offset_t, vm_size_t);
+void   *pmap_mapdev_attr(vm_offset_t pa, vm_size_t size, vm_memattr_t ma);
 
 void   *pmap_mapdev(vm_offset_t, vm_size_t);
 void   *pmap_mapbios(vm_paddr_t, vm_size_t);

Modified: head/sys/kern/subr_devmap.c
==
--- head/sys/kern/subr_devmap.c Wed Jun 20 15:27:09 2018(r335445)
+++ head/sys/kern/subr_devmap.c Wed Jun 20 16:07:35 2018(r335446)
@@ -287,6 +287,37 @@ pmap_mapdev(vm_offset_t pa, vm_size_t size)
return ((void *)(va + offset));
 }
 
+#if defined(__aarch64__)
+void *
+pmap_mapdev_attr(vm_offset_t pa, vm_size_t size, vm_memattr_t ma)
+{
+   vm_offset_t va, offset;
+   void * rva;
+
+   /* First look in the static mapping table. */
+   if ((rva = devmap_ptov(pa, size)) != NULL)
+   return (rva);
+
+   offset = pa & PAGE_MASK;
+   pa = trunc_page(pa);
+   size = round_page(size + offset);
+
+   if (early_boot) {
+   akva_devmap_vaddr = trunc_page(akva_devmap_vaddr - size);
+   va = akva_devmap_vaddr;
+   KASSERT(va >= VM_MAX_KERNEL_ADDRESS - L2_SIZE,
+   ("Too many early devmap mappings"));
+   } else
+   va = kva_alloc(size);
+   if (!va)
+   panic("pmap_mapdev: Couldn't alloc kernel virtual memory");
+
+   pmap_kenter(va, size, pa, ma);
+
+   return ((void *)(va + offset));
+}
+#endif
+
 /*
  * Unmap device memory and free the kva space.
  */
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot

[Warner Losh]

On Wed, Jun 20, 2018 at 10:03 AM, Konstantin Belousov 
wrote:

> On Wed, Jun 20, 2018 at 09:43:31AM -0600, Ian Lepore wrote:
> > On Wed, 2018-06-20 at 12:22 +0300, Konstantin Belousov wrote:
> > > On Tue, Jun 19, 2018 at 08:34:18PM -0400, Allan Jude wrote:
> > > >
> > > > On 2018-06-17 07:32, Eugene Grosbein wrote:
> > > > >
> > > > > 17.06.2018 10:18, Allan Jude wrote:
> > > > >
> > > > > >
> > > > > > Author: allanjude
> > > > > > Date: Sun Jun 17 03:18:56 2018
> > > > > > New Revision: 335276
> > > > > > URL: https://svnweb.freebsd.org/changeset/base/335276
> > > > > >
> > > > > > Log:
> > > > > >   gptboot, zfsboot, gptzfsboot: Enable the video and serial
> consoles early
> > > > > >
> > > > > >   Normally the serial console is not enabled until /boot.config
> is read and
> > > > > >   we know how the serial console should be
> configured.  Initialize the
> > > > > >   consoles early in 'dual' mode (serial & keyboard) with a
> default serial
> > > > > >   rate of 115200. Then serial is re-initialized once the disk is
> decrypted
> > > > > >   and the /boot.config file can be read.
> > > > > >
> > > > > >   This allows the GELIBoot passphrase to be provided via the
> serial console.
> > > > > >
> > > > > >   PR: 221526
> > > > > >   Requested by:   many
> > > > > >   Reviewed by:imp
> > > > > >   Sponsored by:   Klara Systems
> > > > > >   Differential Revision:  https://reviews.freebsd.org/D15862
> > > > > I had several cases when booting FreeBSD/amd64 with motherboard
> having no serial ports
> > > > > hang hard early at boot unless I rebuilt boot media configuring it
> to NOT try accessing
> > > > > missing serial ports. I even could reproduce that with VirtualBox
> machine configured
> > > > > with no serial ports (not same as existing bug inactive serial
> port).
> > > > >
> > > > > Should there be some way to disable this serial ports
> configuration at compile time?
> > > > >
> > > > >
> > > > >
> > > > I think what we'll do it compile it both ways, and use the non-serial
> > > > one by default, because it is safer. Then you can just use
> > > > 'gptboot-serial' if you want serial support.
> > > >
> > > > This will likely make Warner a bit sad, since we are just finally
> > > > getting around to reducing the number of different bootcode files.
> > > I think we should follow the hardware trends there and apply a policy
> > > where new features are not added to the CSM boot. All modern machines
> > > can be booted in UEFI mode, and if some modern machine cannot, then we
> > > need it fixed.  We should encourage users to make new installs boot by
> > > UEFI.
> > >
> > > The feature from the commit is only relevant for machines that require
> > > CSM boot or do not have UEFI option at all, am I right ? With the
> policy
> > > applied, an additional CSM-boot bootblock would be not shipped.
> > >
> >
> > I think it is far too early to say that the code for booting without
> > efi is abandonware. I have half a dozen x86 boxes in use here, and only
> > one of them is even able to boot efi, and its default resolution in efi
> > mode confuses the kvm switch it's connected to, so even on that I have
> > to use legacy bios boot.
> I do not propose to abandon bios boot, or even to declare it legacy
> with the proper meaning. I mean that CSM is disappearing on the newest
> platforms, and should become only used on old machines or i386.  With that
> attitude, adding a features for it, esp. by the cost of the user confusion,
> is not worth the efforts.  It still should be maintained for the foreseable
> future.
>
> If the machines where you get the trouble is newer than say 5 years,
> then they should boot with UEFI.  If not, the problem in loader.efi
> needs to be fixed.
>

There is no problem in loader.efi that's specific to geli. It already uses
the UEFI boot loader config. While there's some issues downstream (eg
kernel messages), this specific issue is a non-issue for loader.efi.

Warer
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot

[Konstantin Belousov]

On Wed, Jun 20, 2018 at 09:43:31AM -0600, Ian Lepore wrote:
> On Wed, 2018-06-20 at 12:22 +0300, Konstantin Belousov wrote:
> > On Tue, Jun 19, 2018 at 08:34:18PM -0400, Allan Jude wrote:
> > > 
> > > On 2018-06-17 07:32, Eugene Grosbein wrote:
> > > > 
> > > > 17.06.2018 10:18, Allan Jude wrote:
> > > > 
> > > > > 
> > > > > Author: allanjude
> > > > > Date: Sun Jun 17 03:18:56 2018
> > > > > New Revision: 335276
> > > > > URL: https://svnweb.freebsd.org/changeset/base/335276
> > > > > 
> > > > > Log:
> > > > >   gptboot, zfsboot, gptzfsboot: Enable the video and serial consoles 
> > > > > early
> > > > >   
> > > > >   Normally the serial console is not enabled until /boot.config is 
> > > > > read and
> > > > >   we know how the serial console should be configured.  Initialize the
> > > > >   consoles early in 'dual' mode (serial & keyboard) with a default 
> > > > > serial
> > > > >   rate of 115200. Then serial is re-initialized once the disk is 
> > > > > decrypted
> > > > >   and the /boot.config file can be read.
> > > > >   
> > > > >   This allows the GELIBoot passphrase to be provided via the serial 
> > > > > console.
> > > > >   
> > > > >   PR: 221526
> > > > >   Requested by:   many
> > > > >   Reviewed by:imp
> > > > >   Sponsored by:   Klara Systems
> > > > >   Differential Revision:  https://reviews.freebsd.org/D15862
> > > > I had several cases when booting FreeBSD/amd64 with motherboard having 
> > > > no serial ports
> > > > hang hard early at boot unless I rebuilt boot media configuring it to 
> > > > NOT try accessing
> > > > missing serial ports. I even could reproduce that with VirtualBox 
> > > > machine configured
> > > > with no serial ports (not same as existing bug inactive serial port).
> > > > 
> > > > Should there be some way to disable this serial ports configuration at 
> > > > compile time?
> > > > 
> > > > 
> > > > 
> > > I think what we'll do it compile it both ways, and use the non-serial
> > > one by default, because it is safer. Then you can just use
> > > 'gptboot-serial' if you want serial support.
> > > 
> > > This will likely make Warner a bit sad, since we are just finally
> > > getting around to reducing the number of different bootcode files.
> > I think we should follow the hardware trends there and apply a policy
> > where new features are not added to the CSM boot. All modern machines
> > can be booted in UEFI mode, and if some modern machine cannot, then we
> > need it fixed.  We should encourage users to make new installs boot by
> > UEFI.
> > 
> > The feature from the commit is only relevant for machines that require
> > CSM boot or do not have UEFI option at all, am I right ? With the policy
> > applied, an additional CSM-boot bootblock would be not shipped.
> > 
> 
> I think it is far too early to say that the code for booting without
> efi is abandonware. I have half a dozen x86 boxes in use here, and only
> one of them is even able to boot efi, and its default resolution in efi
> mode confuses the kvm switch it's connected to, so even on that I have
> to use legacy bios boot.
I do not propose to abandon bios boot, or even to declare it legacy
with the proper meaning. I mean that CSM is disappearing on the newest
platforms, and should become only used on old machines or i386.  With that
attitude, adding a features for it, esp. by the cost of the user confusion,
is not worth the efforts.  It still should be maintained for the foreseable
future.

If the machines where you get the trouble is newer than say 5 years, 
then they should boot with UEFI.  If not, the problem in loader.efi
needs to be fixed.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot

[Ian Lepore]

On Wed, 2018-06-20 at 12:22 +0300, Konstantin Belousov wrote:
> On Tue, Jun 19, 2018 at 08:34:18PM -0400, Allan Jude wrote:
> > 
> > On 2018-06-17 07:32, Eugene Grosbein wrote:
> > > 
> > > 17.06.2018 10:18, Allan Jude wrote:
> > > 
> > > > 
> > > > Author: allanjude
> > > > Date: Sun Jun 17 03:18:56 2018
> > > > New Revision: 335276
> > > > URL: https://svnweb.freebsd.org/changeset/base/335276
> > > > 
> > > > Log:
> > > >   gptboot, zfsboot, gptzfsboot: Enable the video and serial consoles 
> > > > early
> > > >   
> > > >   Normally the serial console is not enabled until /boot.config is read 
> > > > and
> > > >   we know how the serial console should be configured.  Initialize the
> > > >   consoles early in 'dual' mode (serial & keyboard) with a default 
> > > > serial
> > > >   rate of 115200. Then serial is re-initialized once the disk is 
> > > > decrypted
> > > >   and the /boot.config file can be read.
> > > >   
> > > >   This allows the GELIBoot passphrase to be provided via the serial 
> > > > console.
> > > >   
> > > >   PR:   221526
> > > >   Requested by: many
> > > >   Reviewed by:  imp
> > > >   Sponsored by: Klara Systems
> > > >   Differential Revision:https://reviews.freebsd.org/D15862
> > > I had several cases when booting FreeBSD/amd64 with motherboard having no 
> > > serial ports
> > > hang hard early at boot unless I rebuilt boot media configuring it to NOT 
> > > try accessing
> > > missing serial ports. I even could reproduce that with VirtualBox machine 
> > > configured
> > > with no serial ports (not same as existing bug inactive serial port).
> > > 
> > > Should there be some way to disable this serial ports configuration at 
> > > compile time?
> > > 
> > > 
> > > 
> > I think what we'll do it compile it both ways, and use the non-serial
> > one by default, because it is safer. Then you can just use
> > 'gptboot-serial' if you want serial support.
> > 
> > This will likely make Warner a bit sad, since we are just finally
> > getting around to reducing the number of different bootcode files.
> I think we should follow the hardware trends there and apply a policy
> where new features are not added to the CSM boot. All modern machines
> can be booted in UEFI mode, and if some modern machine cannot, then we
> need it fixed.  We should encourage users to make new installs boot by
> UEFI.
> 
> The feature from the commit is only relevant for machines that require
> CSM boot or do not have UEFI option at all, am I right ? With the policy
> applied, an additional CSM-boot bootblock would be not shipped.
> 

I think it is far too early to say that the code for booting without
efi is abandonware. I have half a dozen x86 boxes in use here, and only
one of them is even able to boot efi, and its default resolution in efi
mode confuses the kvm switch it's connected to, so even on that I have
to use legacy bios boot.

However, I'm not sure we need to make a prepackaged gptboot binary that
has serial prompting for geli passwords. That's a pretty specialized
need that can be handled by people building WITH_GPTBOOT_SERIAL or some
similar option and installing it themselves. 

-- Ian
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot

[Ian Lepore]

On Wed, 2018-06-20 at 12:22 +0300, Konstantin Belousov wrote:
> On Tue, Jun 19, 2018 at 08:34:18PM -0400, Allan Jude wrote:
> > 
> > On 2018-06-17 07:32, Eugene Grosbein wrote:
> > > 
> > > 17.06.2018 10:18, Allan Jude wrote:
> > > 
> > > > 
> > > > Author: allanjude
> > > > Date: Sun Jun 17 03:18:56 2018
> > > > New Revision: 335276
> > > > URL: https://svnweb.freebsd.org/changeset/base/335276
> > > > 
> > > > Log:
> > > >   gptboot, zfsboot, gptzfsboot: Enable the video and serial consoles 
> > > > early
> > > >   
> > > >   Normally the serial console is not enabled until /boot.config is read 
> > > > and
> > > >   we know how the serial console should be configured.  Initialize the
> > > >   consoles early in 'dual' mode (serial & keyboard) with a default 
> > > > serial
> > > >   rate of 115200. Then serial is re-initialized once the disk is 
> > > > decrypted
> > > >   and the /boot.config file can be read.
> > > >   
> > > >   This allows the GELIBoot passphrase to be provided via the serial 
> > > > console.
> > > >   
> > > >   PR:   221526
> > > >   Requested by: many
> > > >   Reviewed by:  imp
> > > >   Sponsored by: Klara Systems
> > > >   Differential Revision:https://reviews.freebsd.org/D15862
> > > I had several cases when booting FreeBSD/amd64 with motherboard having no 
> > > serial ports
> > > hang hard early at boot unless I rebuilt boot media configuring it to NOT 
> > > try accessing
> > > missing serial ports. I even could reproduce that with VirtualBox machine 
> > > configured
> > > with no serial ports (not same as existing bug inactive serial port).
> > > 
> > > Should there be some way to disable this serial ports configuration at 
> > > compile time?
> > > 
> > > 
> > > 
> > I think what we'll do it compile it both ways, and use the non-serial
> > one by default, because it is safer. Then you can just use
> > 'gptboot-serial' if you want serial support.
> > 
> > This will likely make Warner a bit sad, since we are just finally
> > getting around to reducing the number of different bootcode files.
> I think we should follow the hardware trends there and apply a policy
> where new features are not added to the CSM boot. All modern machines
> can be booted in UEFI mode, and if some modern machine cannot, then we
> need it fixed.  We should encourage users to make new installs boot by
> UEFI.
> 
> The feature from the commit is only relevant for machines that require
> CSM boot or do not have UEFI option at all, am I right ? With the policy
> applied, an additional CSM-boot bootblock would be not shipped.
> 

I think it is far too early to say that the code for booting without
efi is abandonware. I have half a dozen x86 boxes in use here, and only
one of them is even able to boot efi, and its default resolution in efi
mode confuses the kvm switch it's connected to, so even on that I have
to use legacy bios boot.

However, I'm not sure we need to make a prepackaged gptboot binary that
has serial prompting for geli passwords. That's a pretty specialized
need that can be handled by people building WITH_GPTBOOT_SERIAL or some
similar option and installing it themselves.

-- Ian
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Ian Lepore]

On Wed, 2018-06-20 at 08:45 -0700, Conrad Meyer wrote:
> You can keep these poor security modes in your downstream product if
> you want, but don't put them in the tree.
> 

And I request exactly the opposite: reject the complaining of people
who think all the world is a 256-core 5ghz server and leave in the
option to use faster algorithms on real-world hardware used by real-
world vendors who need some option other than "rev your hardware every
18 months to keep up with the software or get out of the business."

Stronger algorithm options, yes. Even making stronger options the
default, yes. But removing viable options which are endorsed by the
people who actually set the standards, no.

- Ian

> On Wed, Jun 20, 2018 at 8:28 AM, Simon J. Gerraty 
> wrote:
> > 
> > Benjamin Kaduk  wrote:
> > > 
> > > With all due respect, NIST is hardly the sole authority on this
> > > topic.
> > True, unless of course you sell to US govt.
> > 
> > > 
> > > With my IETF Security Area Director hat on, any greenfield
> > > proposal coming
> > > in
> > > to the IESG that included sha1 support would get extremely strong
> > > pushback,
> > > and I don't expect that "reducing boot time" would be seen as
> > > sufficiently
> > > compelling.
> > Well that's unfortunate, because reality (and sales teams) can be a
> > pain.   The number of customers who would trade boot time for
> > improved
> > security is depressingly small.
> > 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335437 - in head: share/man/man4 sys/kern

[Conrad Meyer]

On Wed, Jun 20, 2018 at 8:36 AM, Bjoern A. Zeeb  wrote:
> On 20 Jun 2018, at 15:05, Conrad Meyer wrote:
>
>> Hi Bjoern,
>>
>> It might be nice to be explicit that the vnode was not in the
>> namecache (in the ddb output) rather than failing silently.  The name
>> of the ddb method does not suggest that only entries in the namecache
>> may be found, and users (developers :)) do not always read manual
>> pages thoroughly.
>
> It’s not failing silently;  it ends with an address w/o name.

Hi,

To provide a more concrete proposal, would you object to the following?

0xfoobarbaz: 

Thanks,
Conrad
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Conrad Meyer]

You can keep these poor security modes in your downstream product if
you want, but don't put them in the tree.

On Wed, Jun 20, 2018 at 8:28 AM, Simon J. Gerraty  wrote:
> Benjamin Kaduk  wrote:
>> With all due respect, NIST is hardly the sole authority on this topic.
>
> True, unless of course you sell to US govt.
>
>> With my IETF Security Area Director hat on, any greenfield proposal coming
>> in
>> to the IESG that included sha1 support would get extremely strong pushback,
>> and I don't expect that "reducing boot time" would be seen as sufficiently
>> compelling.
>
> Well that's unfortunate, because reality (and sales teams) can be a
> pain.   The number of customers who would trade boot time for improved
> security is depressingly small.
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335437 - in head: share/man/man4 sys/kern

[Bjoern A. Zeeb]

On 20 Jun 2018, at 15:05, Conrad Meyer wrote:

> Hi Bjoern,
>
> It might be nice to be explicit that the vnode was not in the
> namecache (in the ddb output) rather than failing silently.  The name
> of the ddb method does not suggest that only entries in the namecache
> may be found, and users (developers :)) do not always read manual
> pages thoroughly.

It’s not failing silently;  it ends with an address w/o name.


/bz
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Simon J. Gerraty]

Cy Schubert  wrote:
> > The signing of manifests is external.  The veriexecctl tool is I assume
> > a straight copy of what's in NetBSD (I've not looked at it in at least a
> > decade).
> 
> If this is correct, should it not be imported into the vendor branches 
> first?
> 
> What are the criteria to import through the vendor branches v.s. direct 
> import into HEAD? Do I fail to understand a missing piece of 
> information or is there an inconsistency?

AFAIK the key is whether there is an upstream project that will be
tracked, which is not the case here.
The ctl tool is the only bit that bears any relationship to the NetBSD
code - because we never used it.

Once I commit the loader stuff, we can replace the above with something
more useful - can leverage the same library to verify manifest
signatures.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Simon J. Gerraty]

Benjamin Kaduk  wrote:
> With all due respect, NIST is hardly the sole authority on this topic.

True, unless of course you sell to US govt.

> With my IETF Security Area Director hat on, any greenfield proposal coming
> in
> to the IESG that included sha1 support would get extremely strong pushback,
> and I don't expect that "reducing boot time" would be seen as sufficiently
> compelling.

Well that's unfortunate, because reality (and sales teams) can be a
pain.   The number of customers who would trade boot time for improved
security is depressingly small.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335445 - head/sys/arm64/rockchip

[Emmanuel Vadot]

Author: manu
Date: Wed Jun 20 15:27:09 2018
New Revision: 335445
URL: https://svnweb.freebsd.org/changeset/base/335445

Log:
  if_rk_dwc: Disable setting delays for now
  
  The values for tx/rx delays differs accross the different DTS.
  Mainline Linux set it to 0x24/0x18
  Mostly-Vendor u-boot (the one maintained and developped) to 0x18/0x18
  Mostly-Vendor linux (the one maintained and developped) to 0x26/0x11
  
  By experience only 0x18/0x18 works so until the issue is resolved rely on
  the bootloader settings.

Modified:
  head/sys/arm64/rockchip/if_dwc_rk.c

Modified: head/sys/arm64/rockchip/if_dwc_rk.c
==
--- head/sys/arm64/rockchip/if_dwc_rk.c Wed Jun 20 14:46:07 2018
(r335444)
+++ head/sys/arm64/rockchip/if_dwc_rk.c Wed Jun 20 15:27:09 2018
(r335445)
@@ -80,7 +80,8 @@ rk3328_set_delays(struct syscon *grf, phandle_t node)
rx = ((rx & RK3328_GRF_MAC_CON0_TX_MASK) <<
RK3328_GRF_MAC_CON0_RX_SHIFT);
 
-   SYSCON_WRITE_4(grf, RK3328_GRF_MAC_CON0, tx | rx | 0x);
+   /* Disable delays as values conflict between DTS */
+   /* SYSCON_WRITE_4(grf, RK3328_GRF_MAC_CON0, tx | rx | 0x); */
 }
 
 static int
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Stephen Kiernan]

On Wed, Jun 20, 2018, 6:42 AM Cy Schubert  wrote:

> In message <96021.1529475...@kaos.jnpr.net>, "Simon J. Gerraty" writes:
> > Conrad Meyer  wrote:
> > > First and foremost: nothing is actually signed, anywhere.  The
> >
> > The signing of manifests is external.  The veriexecctl tool is I assume
> > a straight copy of what's in NetBSD (I've not looked at it in at least a
> > decade).
>
> If this is correct, should it not be imported into the vendor branches
> first?
>

It's not a straight copy. But much of it is from the NetBSD version.


> What are the criteria to import through the vendor branches v.s. direct
> import into HEAD? Do I fail to understand a missing piece of
> information or is there an inconsistency?
>

I asked about it at BSDCan 3 years ago and pointed people my github branch
(before review was created) to get opinions on what to do about it (vendor
or directly put it in sbin) and the consensus was to submit it the way I
did.

-Steve
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Simon J. Gerraty]

Simon J. Gerraty  wrote:
> > - Maybe sign the source-of-trust file
> 
> We do.  As noted above, we cannot upstream that until FreeBSD has
> suitable signing infra.

It occurred to me, that since I'll be upstreaming a library that
uses BearSSL to do the necessary manifest verification for the loader,
the same could be leveraged for the veriexec loader.

That may impact where the two libs should go - will discuss with imp.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335437 - in head: share/man/man4 sys/kern

[Conrad Meyer]

Hi Bjoern,

It might be nice to be explicit that the vnode was not in the
namecache (in the ddb output) rather than failing silently.  The name
of the ddb method does not suggest that only entries in the namecache
may be found, and users (developers :)) do not always read manual
pages thoroughly.

All the best,
Conrad


On Wed, Jun 20, 2018 at 1:34 AM, Bjoern A. Zeeb  wrote:
> Author: bz
> Date: Wed Jun 20 08:34:29 2018
> New Revision: 335437
> URL: https://svnweb.freebsd.org/changeset/base/335437
>
> Log:
>   Sometimes it is helpful to get the path for a vnode.
>   Implement a ddb function walking the namecache to do this.
>
>   Reviewed by:  jhb, mjg
>   Inspired by:  gdb macro from jhb (old version)
>   Sponsored by: iXsystems, Inc.
>   Differential Revision:https://reviews.freebsd.org/D14898
>
> Modified:
>   head/share/man/man4/ddb.4
>   head/sys/kern/vfs_cache.c
>
> Modified: head/share/man/man4/ddb.4
> ==
> --- head/share/man/man4/ddb.4   Wed Jun 20 07:02:19 2018(r335436)
> +++ head/share/man/man4/ddb.4   Wed Jun 20 08:34:29 2018(r335437)
> @@ -60,7 +60,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd August 24, 2017
> +.Dd June 20, 2018
>  .Dt DDB 4
>  .Os
>  .Sh NAME
> @@ -1121,6 +1121,11 @@ header file.
>  .Pp
>  .It Ic show Cm vnodebufs Ar addr
>  Shows clean/dirty buffer lists of the vnode located at
> +.Ar addr .
> +.\"
> +.Pp
> +.It Ic show Cm vpath Ar addr
> +Walk the namecache to lookup the pathname of the vnode located at
>  .Ar addr .
>  .\"
>  .Pp
>
> Modified: head/sys/kern/vfs_cache.c
> ==
> --- head/sys/kern/vfs_cache.c   Wed Jun 20 07:02:19 2018(r335436)
> +++ head/sys/kern/vfs_cache.c   Wed Jun 20 08:34:29 2018(r335437)
> @@ -37,6 +37,7 @@
>  #include 
>  __FBSDID("$FreeBSD$");
>
> +#include "opt_ddb.h"
>  #include "opt_ktrace.h"
>
>  #include 
> @@ -62,6 +63,10 @@ __FBSDID("$FreeBSD$");
>  #include 
>  #endif
>
> +#ifdef DDB
> +#include 
> +#endif
> +
>  #include 
>
>  SDT_PROVIDER_DECLARE(vfs);
> @@ -2529,3 +2534,54 @@ out:
> free(fbuf, M_TEMP);
> return (error);
>  }
> +
> +#ifdef DDB
> +static void
> +db_print_vpath(struct vnode *vp)
> +{
> +
> +   while (vp != NULL) {
> +   db_printf("%p: ", vp);
> +   if (vp == rootvnode) {
> +   db_printf("/");
> +   vp = NULL;
> +   } else {
> +   if (vp->v_vflag & VV_ROOT) {
> +   db_printf("");
> +   vp = vp->v_mount->mnt_vnodecovered;
> +   } else {
> +   struct namecache *ncp;
> +   char *ncn;
> +   int i;
> +
> +   ncp = TAILQ_FIRST(>v_cache_dst);
> +   if (ncp != NULL) {
> +   ncn = ncp->nc_name;
> +   for (i = 0; i < ncp->nc_nlen; i++)
> +   db_printf("%c", *ncn++);
> +   vp = ncp->nc_dvp;
> +   } else {
> +   vp = NULL;
> +   }
> +   }
> +   }
> +   db_printf("\n");
> +   }
> +
> +   return;
> +}
> +
> +DB_SHOW_COMMAND(vpath, db_show_vpath)
> +{
> +   struct vnode *vp;
> +
> +   if (!have_addr) {
> +   db_printf("usage: show vpath \n");
> +   return;
> +   }
> +
> +   vp = (struct vnode *)addr;
> +   db_print_vpath(vp);
> +}
> +
> +#endif
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335444 - head/sys/arm64/rockchip

[Emmanuel Vadot]

Author: manu
Date: Wed Jun 20 14:46:07 2018
New Revision: 335444
URL: https://svnweb.freebsd.org/changeset/base/335444

Log:
  rk_gpio: Read the correct register for gpio read
  
  Reported by:  jmcneill

Modified:
  head/sys/arm64/rockchip/rk_gpio.c

Modified: head/sys/arm64/rockchip/rk_gpio.c
==
--- head/sys/arm64/rockchip/rk_gpio.c   Wed Jun 20 14:45:26 2018
(r335443)
+++ head/sys/arm64/rockchip/rk_gpio.c   Wed Jun 20 14:46:07 2018
(r335444)
@@ -277,7 +277,7 @@ rk_gpio_pin_get(device_t dev, uint32_t pin, unsigned i
sc = device_get_softc(dev);
 
RK_GPIO_LOCK(sc);
-   reg = RK_GPIO_READ(sc, RK_GPIO_SWPORTA_DR);
+   reg = RK_GPIO_READ(sc, RK_GPIO_EXT_PORTA);
RK_GPIO_UNLOCK(sc);
 
*val = reg & (1 << pin) ? 1 : 0;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335443 - head/sys/arm64/rockchip

[Emmanuel Vadot]

Author: manu
Date: Wed Jun 20 14:45:26 2018
New Revision: 335443
URL: https://svnweb.freebsd.org/changeset/base/335443

Log:
  if_rk_dwc: Fix delays handling
  
  The property are named {t,r}x_delay and not {t,r}-delay.
  The upper bits of the register are a mask of which bits is allowed
  to be written, set it otherwise we write nothing.
  OF_getencprop returns <0 = for an error.
  
  Pointy Hat: myself
  Reported by:  jmcneill (delay and mask bits)

Modified:
  head/sys/arm64/rockchip/if_dwc_rk.c

Modified: head/sys/arm64/rockchip/if_dwc_rk.c
==
--- head/sys/arm64/rockchip/if_dwc_rk.c Wed Jun 20 13:30:35 2018
(r335442)
+++ head/sys/arm64/rockchip/if_dwc_rk.c Wed Jun 20 14:45:26 2018
(r335443)
@@ -70,16 +70,17 @@ rk3328_set_delays(struct syscon *grf, phandle_t node)
 {
uint32_t tx, rx;
 
-   if (OF_getencprop(node, "tx-delay", , sizeof(tx)) >= 0)
+   if (OF_getencprop(node, "tx_delay", , sizeof(tx)) <= 0)
tx = 0x30;
-   if (OF_getencprop(node, "rx-delay", , sizeof(rx)) >= 0)
+   if (OF_getencprop(node, "rx_delay", , sizeof(rx)) <= 0)
rx = 0x10;
 
tx = ((tx & RK3328_GRF_MAC_CON0_TX_MASK) <<
RK3328_GRF_MAC_CON0_TX_SHIFT);
rx = ((rx & RK3328_GRF_MAC_CON0_TX_MASK) <<
RK3328_GRF_MAC_CON0_RX_SHIFT);
-   SYSCON_WRITE_4(grf, RK3328_GRF_MAC_CON0, tx | rx);
+
+   SYSCON_WRITE_4(grf, RK3328_GRF_MAC_CON0, tx | rx | 0x);
 }
 
 static int
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot

[Warner Losh]

On Tue, Jun 19, 2018 at 6:34 PM, Allan Jude  wrote:

> On 2018-06-17 07:32, Eugene Grosbein wrote:
> > 17.06.2018 10:18, Allan Jude wrote:
> >
> >> Author: allanjude
> >> Date: Sun Jun 17 03:18:56 2018
> >> New Revision: 335276
> >> URL: https://svnweb.freebsd.org/changeset/base/335276
> >>
> >> Log:
> >>   gptboot, zfsboot, gptzfsboot: Enable the video and serial consoles
> early
> >>
> >>   Normally the serial console is not enabled until /boot.config is read
> and
> >>   we know how the serial console should be configured.  Initialize the
> >>   consoles early in 'dual' mode (serial & keyboard) with a default
> serial
> >>   rate of 115200. Then serial is re-initialized once the disk is
> decrypted
> >>   and the /boot.config file can be read.
> >>
> >>   This allows the GELIBoot passphrase to be provided via the serial
> console.
> >>
> >>   PR:221526
> >>   Requested by:  many
> >>   Reviewed by:   imp
> >>   Sponsored by:  Klara Systems
> >>   Differential Revision: https://reviews.freebsd.org/D15862
> >
> > I had several cases when booting FreeBSD/amd64 with motherboard having
> no serial ports
> > hang hard early at boot unless I rebuilt boot media configuring it to
> NOT try accessing
> > missing serial ports. I even could reproduce that with VirtualBox
> machine configured
> > with no serial ports (not same as existing bug inactive serial port).
> >
> > Should there be some way to disable this serial ports configuration at
> compile time?
> >
> >
> >
>
> I think what we'll do it compile it both ways, and use the non-serial
> one by default, because it is safer. Then you can just use
> 'gptboot-serial' if you want serial support.
>
> This will likely make Warner a bit sad, since we are just finally
> getting around to reducing the number of different bootcode files.
>

I think we should *NOT* do that.

There is a niche market for this stuff, and we should support building
serial-enabled bootblocks on an opt-in basis. The support is really already
there, this just enables it early.

I agree with kib@ that the target market here is too small to justify a
proliferation of new boot blocks.

Warner
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Cy Schubert]

In message <96021.1529475...@kaos.jnpr.net>, "Simon J. Gerraty" writes:
> Conrad Meyer  wrote:
> > First and foremost: nothing is actually signed, anywhere.  The
>
> The signing of manifests is external.  The veriexecctl tool is I assume
> a straight copy of what's in NetBSD (I've not looked at it in at least a
> decade).

If this is correct, should it not be imported into the vendor branches 
first?

What are the criteria to import through the vendor branches v.s. direct 
import into HEAD? Do I fail to understand a missing piece of 
information or is there an inconsistency?


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Benjamin Kaduk]

On Wed, Jun 20, 2018 at 1:21 AM, Simon J. Gerraty  wrote:

> Conrad Meyer  wrote:
>
> > There's absolutely no reason to use sha1 or ripemd in new designs.
> > These should be removed.
>
> Sorry I disagree - not with ripem (we never supported that or any of the
> non-NIST approved hashes), but sha1 is still approved by NIST for
> firmware integrity checks - which is what this is, and sha1 is cheaper
> than sha256.
>
> As I mentioned in my talk we've included support for sha256 for 10+
> years, but do not plan to drop sha1 until NIST deprecate it for that
> purpose since boot time is a very sensitive subject for us.
>


With all due respect, NIST is hardly the sole authority on this topic.
Over in the IETF, we have the SUIT working group that is even considering
hash-based signatures for firmware updates for post-quantum resistance
(so that devices can be shipped now that have 20-year lifecycles can have
some expectation of retaining the ability to securely take updates over that
lifecycle, admittedly).

With my IETF Security Area Director hat on, any greenfield proposal coming
in
to the IESG that included sha1 support would get extremely strong pushback,
and I don't expect that "reducing boot time" would be seen as sufficiently
compelling.

-Ben
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335442 - head/sys/dev/ofw

[Justin Hibbits]

Author: jhibbits
Date: Wed Jun 20 13:30:35 2018
New Revision: 335442
URL: https://svnweb.freebsd.org/changeset/base/335442

Log:
  Attach dev.cpu nodes on powerpc SMT cores, using only the first found thread
  
  Summary: In order to use cpufreq(4), a dev.cpu attachment must be created.  If
  the IBM property is found denoting SMT, attach only to the first thread setup,
  so that a cpufreq device can bind.
  
  Reviewed by:  nwhitehorn
  Differential Revision: https://reviews.freebsd.org/D15921

Modified:
  head/sys/dev/ofw/ofw_cpu.c

Modified: head/sys/dev/ofw/ofw_cpu.c
==
--- head/sys/dev/ofw/ofw_cpu.c  Wed Jun 20 11:42:06 2018(r335441)
+++ head/sys/dev/ofw/ofw_cpu.c  Wed Jun 20 13:30:35 2018(r335442)
@@ -191,10 +191,6 @@ ofw_cpu_probe(device_t dev)
if (type == NULL || strcmp(type, "cpu") != 0)
return (ENXIO);
 
-   /* Skip SMT CPUs, which we can't reasonably represent with this code */
-   if (OF_hasprop(ofw_bus_get_node(dev), "ibm,ppc-interrupt-server#s"))
-   return (ENXIO);
-
device_set_desc(dev, "Open Firmware CPU");
return (0);
 }
@@ -233,6 +229,43 @@ ofw_cpu_attach(device_t dev)
} else
sc->sc_reg_valid = true;
 
+#ifdef __powerpc__
+   /*
+* On powerpc, "interrupt-servers" denotes a SMT CPU.  Look for any
+* thread on this CPU, and assign that.
+*/
+   if (OF_hasprop(node, "ibm,ppc-interrupt-server#s")) {
+   struct cpuref cpuref;
+   cell_t *servers;
+   int i, nservers, rv;
+   
+   if ((nservers = OF_getencprop_alloc(node, 
+   "ibm,ppc-interrupt-server#s", (void **))) < 0)
+   return (ENXIO);
+   nservers /= sizeof(cell_t);
+   for (i = 0; i < nservers; i++) {
+   for (rv = platform_smp_first_cpu(); rv == 0;
+   rv = platform_smp_next_cpu()) {
+   if (cpuref.cr_hwref == servers[i]) {
+   sc->sc_cpu_pcpu =
+   pcpu_find(cpuref.cr_cpuid);
+   if (sc->sc_cpu_pcpu == NULL) {
+   OF_prop_free(servers);
+   return (ENXIO);
+   }
+   break;
+   }
+   }
+   if (rv != ENOENT)
+   break;
+   }
+   OF_prop_free(servers);
+   if (sc->sc_cpu_pcpu == NULL) {
+   device_printf(dev, "No CPU found for this device.\n");
+   return (ENXIO);
+   }
+   } else
+#endif
sc->sc_cpu_pcpu = pcpu_find(device_get_unit(dev));
 
if (OF_getencprop(node, "clock-frequency", , sizeof(cell)) < 0) {
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335441 - head/sys/kern

[Bjoern A. Zeeb]

Author: bz
Date: Wed Jun 20 11:42:06 2018
New Revision: 335441
URL: https://svnweb.freebsd.org/changeset/base/335441

Log:
  Instead of using hand-rolled loops where not needed switch them
  to FOREACH_PROC_IN_SYSTEM() to have a single pattern to look for.
  
  Reviewed by:  kib
  MFC after:2 weeks
  Sponsored by: iXsystems, Inc.
  Differential Revision:https://reviews.freebsd.org/D15916

Modified:
  head/sys/kern/kern_jail.c
  head/sys/kern/kern_proc.c
  head/sys/kern/subr_kdb.c

Modified: head/sys/kern/kern_jail.c
==
--- head/sys/kern/kern_jail.c   Wed Jun 20 11:13:10 2018(r335440)
+++ head/sys/kern/kern_jail.c   Wed Jun 20 11:42:06 2018(r335441)
@@ -2286,7 +2286,7 @@ prison_remove_one(struct prison *pr)
 * Kill all processes unfortunate enough to be attached to this prison.
 */
sx_slock(_lock);
-   LIST_FOREACH(p, , p_list) {
+   FOREACH_PROC_IN_SYSTEM(p) {
PROC_LOCK(p);
if (p->p_state != PRS_NEW && p->p_ucred &&
p->p_ucred->cr_prison == pr)

Modified: head/sys/kern/kern_proc.c
==
--- head/sys/kern/kern_proc.c   Wed Jun 20 11:13:10 2018(r335440)
+++ head/sys/kern/kern_proc.c   Wed Jun 20 11:42:06 2018(r335441)
@@ -3176,7 +3176,7 @@ again:
}
}
/*  Did the loop above missed any stopped process ? */
-   LIST_FOREACH(p, , p_list) {
+   FOREACH_PROC_IN_SYSTEM(p) {
/* No need for proc lock. */
if ((p->p_flag & P_TOTAL_STOP) != 0)
goto again;

Modified: head/sys/kern/subr_kdb.c
==
--- head/sys/kern/subr_kdb.cWed Jun 20 11:13:10 2018(r335440)
+++ head/sys/kern/subr_kdb.cWed Jun 20 11:42:06 2018(r335441)
@@ -580,14 +580,12 @@ kdb_thr_first(void)
struct proc *p;
struct thread *thr;
 
-   p = LIST_FIRST();
-   while (p != NULL) {
+   FOREACH_PROC_IN_SYSTEM(p) {
if (p->p_flag & P_INMEM) {
thr = FIRST_THREAD_IN_PROC(p);
if (thr != NULL)
return (thr);
}
-   p = LIST_NEXT(p, p_list);
}
return (NULL);
 }
@@ -597,11 +595,9 @@ kdb_thr_from_pid(pid_t pid)
 {
struct proc *p;
 
-   p = LIST_FIRST();
-   while (p != NULL) {
+   FOREACH_PROC_IN_SYSTEM(p) {
if (p->p_flag & P_INMEM && p->p_pid == pid)
return (FIRST_THREAD_IN_PROC(p));
-   p = LIST_NEXT(p, p_list);
}
return (NULL);
 }
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335440 - head/sys/arm/arm

[Andrew Turner]

Author: andrew
Date: Wed Jun 20 11:13:10 2018
New Revision: 335440
URL: https://svnweb.freebsd.org/changeset/base/335440

Log:
  Move the SYSINIT to allow userspace access to the ARM generic timer later
  in the boot. It doesn't need to be early, so move it to the SI_ORDER_ANY
  stage of SI_SUB_SMP.
  
  Sponsored by: DARPA, AFRL

Modified:
  head/sys/arm/arm/generic_timer.c

Modified: head/sys/arm/arm/generic_timer.c
==
--- head/sys/arm/arm/generic_timer.cWed Jun 20 10:57:29 2018
(r335439)
+++ head/sys/arm/arm/generic_timer.cWed Jun 20 11:13:10 2018
(r335440)
@@ -243,7 +243,7 @@ tmr_setup_user_access(void *arg __unused)
if (arm_tmr_sc != NULL)
smp_rendezvous(NULL, setup_user_access, NULL, NULL);
 }
-SYSINIT(tmr_ua, SI_SUB_SMP, SI_ORDER_SECOND, tmr_setup_user_access, NULL);
+SYSINIT(tmr_ua, SI_SUB_SMP, SI_ORDER_ANY, tmr_setup_user_access, NULL);
 
 static unsigned
 arm_tmr_get_timecount(struct timecounter *tc)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335439 - head/sys/dev/psci

[Andrew Turner]

Author: andrew
Date: Wed Jun 20 10:57:29 2018
New Revision: 335439
URL: https://svnweb.freebsd.org/changeset/base/335439

Log:
  Move the SMCCC SYSINIT later in the boot so the psci driver has attached.
  
  Sponsored by: DARPA, AFRL

Modified:
  head/sys/dev/psci/smccc.c

Modified: head/sys/dev/psci/smccc.c
==
--- head/sys/dev/psci/smccc.c   Wed Jun 20 10:02:50 2018(r335438)
+++ head/sys/dev/psci/smccc.c   Wed Jun 20 10:57:29 2018(r335439)
@@ -67,7 +67,7 @@ smccc_init(void *dummy)
SMCCC_VERSION_MINOR(smccc_version));
}
 }
-SYSINIT(smccc_start, SI_SUB_DRIVERS, SI_ORDER_ANY, smccc_init, NULL);
+SYSINIT(smccc_start, SI_SUB_CONFIGURE, SI_ORDER_ANY, smccc_init, NULL);
 
 int32_t
 smccc_arch_features(uint32_t smccc_func_id)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335438 - head/sys/dev/psci

[Andrew Turner]

Author: andrew
Date: Wed Jun 20 10:02:50 2018
New Revision: 335438
URL: https://svnweb.freebsd.org/changeset/base/335438

Log:
  Fix the SMCCC signatures, they are all 32-bit calls. This fixes SMCCC
  version detection.
  
  Sponsored by: DARPA, AFRL

Modified:
  head/sys/dev/psci/smccc.h

Modified: head/sys/dev/psci/smccc.h
==
--- head/sys/dev/psci/smccc.h   Wed Jun 20 08:34:29 2018(r335437)
+++ head/sys/dev/psci/smccc.h   Wed Jun 20 10:02:50 2018(r335438)
@@ -54,11 +54,11 @@
  * These are documented in the document ARM DEN 0070A.
  */
 #defineSMCCC_VERSION   
\
-SMCCC_FUNC_ID(SMCCC_FAST_CALL, SMCCC_64BIT_CALL, 0, 0)
+SMCCC_FUNC_ID(SMCCC_FAST_CALL, SMCCC_32BIT_CALL, 0, 0)
 #defineSMCCC_ARCH_FEATURES 
\
-SMCCC_FUNC_ID(SMCCC_FAST_CALL, SMCCC_64BIT_CALL, 0, 1)
+SMCCC_FUNC_ID(SMCCC_FAST_CALL, SMCCC_32BIT_CALL, 0, 1)
 #defineSMCCC_ARCH_WORKAROUND_1 
\
-SMCCC_FUNC_ID(SMCCC_FAST_CALL, SMCCC_64BIT_CALL, 0, 0x8000)
+SMCCC_FUNC_ID(SMCCC_FAST_CALL, SMCCC_32BIT_CALL, 0, 0x8000)
 
 /* The return values from ARM DEN 0070A. */
 #defineSMCCC_RET_SUCCESS   0
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Stephen Kiernan]

On Tue, Jun 19, 2018 at 11:21 PM, Simon J. Gerraty  wrote:

> Conrad Meyer  wrote:
>
> > As a corollary to the above, the name "signature file" is used
> > repeatedly in the code, which is misleading.  The file contains hashes
> > (digests), not signatures (MACs).  The file itself is unsigned.
> > Nothing about this has signatures.
>

I think you mean "signature".
I belive the only place that says "signature file" is the veriexecctl.
And that was in the original sources from NetBSD.

For example, see the currentl veriexecctl in NetBSD and it still uses the
terminology "signature file".

http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/veriexecctl/veriexecctl.c?rev=1.40

But yes, I agree that it's the wrong term that they're using there.


> NetBSD refers to the hashes as fingerprints - AFAIK that terminology is
> retained.
>
> If the term signature is used to refer to anything other than the signed
> manifests that should be fixed.
>

That was in the veriexec that was the basis for the MAC conversion. I know
I had corrected some before, but probably missed the fact that it was used
in some other places. Easy to happen when you've seen the same code for
a number of years.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335276 - in head/stand/i386: gptboot zfsboot

[Konstantin Belousov]

On Tue, Jun 19, 2018 at 08:34:18PM -0400, Allan Jude wrote:
> On 2018-06-17 07:32, Eugene Grosbein wrote:
> > 17.06.2018 10:18, Allan Jude wrote:
> > 
> >> Author: allanjude
> >> Date: Sun Jun 17 03:18:56 2018
> >> New Revision: 335276
> >> URL: https://svnweb.freebsd.org/changeset/base/335276
> >>
> >> Log:
> >>   gptboot, zfsboot, gptzfsboot: Enable the video and serial consoles early
> >>   
> >>   Normally the serial console is not enabled until /boot.config is read and
> >>   we know how the serial console should be configured.  Initialize the
> >>   consoles early in 'dual' mode (serial & keyboard) with a default serial
> >>   rate of 115200. Then serial is re-initialized once the disk is decrypted
> >>   and the /boot.config file can be read.
> >>   
> >>   This allows the GELIBoot passphrase to be provided via the serial 
> >> console.
> >>   
> >>   PR:  221526
> >>   Requested by:many
> >>   Reviewed by: imp
> >>   Sponsored by:Klara Systems
> >>   Differential Revision:   https://reviews.freebsd.org/D15862
> > 
> > I had several cases when booting FreeBSD/amd64 with motherboard having no 
> > serial ports
> > hang hard early at boot unless I rebuilt boot media configuring it to NOT 
> > try accessing
> > missing serial ports. I even could reproduce that with VirtualBox machine 
> > configured
> > with no serial ports (not same as existing bug inactive serial port).
> > 
> > Should there be some way to disable this serial ports configuration at 
> > compile time?
> > 
> > 
> > 
> 
> I think what we'll do it compile it both ways, and use the non-serial
> one by default, because it is safer. Then you can just use
> 'gptboot-serial' if you want serial support.
> 
> This will likely make Warner a bit sad, since we are just finally
> getting around to reducing the number of different bootcode files.

I think we should follow the hardware trends there and apply a policy
where new features are not added to the CSM boot. All modern machines
can be booted in UEFI mode, and if some modern machine cannot, then we
need it fixed.  We should encourage users to make new installs boot by
UEFI.

The feature from the commit is only relevant for machines that require
CSM boot or do not have UEFI option at all, am I right ? With the policy
applied, an additional CSM-boot bootblock would be not shipped.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335437 - in head: share/man/man4 sys/kern

[Bjoern A. Zeeb]

Author: bz
Date: Wed Jun 20 08:34:29 2018
New Revision: 335437
URL: https://svnweb.freebsd.org/changeset/base/335437

Log:
  Sometimes it is helpful to get the path for a vnode.
  Implement a ddb function walking the namecache to do this.
  
  Reviewed by:  jhb, mjg
  Inspired by:  gdb macro from jhb (old version)
  Sponsored by: iXsystems, Inc.
  Differential Revision:https://reviews.freebsd.org/D14898

Modified:
  head/share/man/man4/ddb.4
  head/sys/kern/vfs_cache.c

Modified: head/share/man/man4/ddb.4
==
--- head/share/man/man4/ddb.4   Wed Jun 20 07:02:19 2018(r335436)
+++ head/share/man/man4/ddb.4   Wed Jun 20 08:34:29 2018(r335437)
@@ -60,7 +60,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd August 24, 2017
+.Dd June 20, 2018
 .Dt DDB 4
 .Os
 .Sh NAME
@@ -1121,6 +1121,11 @@ header file.
 .Pp
 .It Ic show Cm vnodebufs Ar addr
 Shows clean/dirty buffer lists of the vnode located at
+.Ar addr .
+.\"
+.Pp
+.It Ic show Cm vpath Ar addr
+Walk the namecache to lookup the pathname of the vnode located at
 .Ar addr .
 .\"
 .Pp

Modified: head/sys/kern/vfs_cache.c
==
--- head/sys/kern/vfs_cache.c   Wed Jun 20 07:02:19 2018(r335436)
+++ head/sys/kern/vfs_cache.c   Wed Jun 20 08:34:29 2018(r335437)
@@ -37,6 +37,7 @@
 #include 
 __FBSDID("$FreeBSD$");
 
+#include "opt_ddb.h"
 #include "opt_ktrace.h"
 
 #include 
@@ -62,6 +63,10 @@ __FBSDID("$FreeBSD$");
 #include 
 #endif
 
+#ifdef DDB
+#include 
+#endif
+
 #include 
 
 SDT_PROVIDER_DECLARE(vfs);
@@ -2529,3 +2534,54 @@ out:
free(fbuf, M_TEMP);
return (error);
 }
+
+#ifdef DDB
+static void
+db_print_vpath(struct vnode *vp)
+{
+
+   while (vp != NULL) {
+   db_printf("%p: ", vp);
+   if (vp == rootvnode) {
+   db_printf("/");
+   vp = NULL;
+   } else {
+   if (vp->v_vflag & VV_ROOT) {
+   db_printf("");
+   vp = vp->v_mount->mnt_vnodecovered;
+   } else {
+   struct namecache *ncp;
+   char *ncn;
+   int i;
+
+   ncp = TAILQ_FIRST(>v_cache_dst);
+   if (ncp != NULL) {
+   ncn = ncp->nc_name;
+   for (i = 0; i < ncp->nc_nlen; i++)
+   db_printf("%c", *ncn++);
+   vp = ncp->nc_dvp;
+   } else {
+   vp = NULL;
+   }
+   }
+   }
+   db_printf("\n");
+   }
+
+   return;
+}
+
+DB_SHOW_COMMAND(vpath, db_show_vpath)
+{
+   struct vnode *vp;
+
+   if (!have_addr) {
+   db_printf("usage: show vpath \n");
+   return;
+   }
+
+   vp = (struct vnode *)addr;
+   db_print_vpath(vp);
+}
+
+#endif
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335436 - stable/11/sys/sys

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 07:02:19 2018
New Revision: 335436
URL: https://svnweb.freebsd.org/changeset/base/335436

Log:
  Bump the __FreeBSD_version after recent LinuxKPI updates to force
  recompilation of external kernel modules.
  
  This is a direct commit.
  
  Sponsored by:   Mellanox Technologies

Modified:
  stable/11/sys/sys/param.h

Modified: stable/11/sys/sys/param.h
==
--- stable/11/sys/sys/param.h   Wed Jun 20 06:59:39 2018(r335435)
+++ stable/11/sys/sys/param.h   Wed Jun 20 07:02:19 2018(r335436)
@@ -58,7 +58,7 @@
  * in the range 5 to 9.
  */
 #undef __FreeBSD_version
-#define __FreeBSD_version 1102500  /* Master, propagated to newvers */
+#define __FreeBSD_version 1102501  /* Master, propagated to newvers */
 
 /*
  * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD,
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335435 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:59:39 2018
New Revision: 335435
URL: https://svnweb.freebsd.org/changeset/base/335435

Log:
  MFC r334775:
  Move the EXPORT_SYMBOL_XXX() function macros into own header file.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Added:
  stable/11/sys/compat/linuxkpi/common/include/linux/export.h
 - copied unchanged from r334775, 
head/sys/compat/linuxkpi/common/include/linux/export.h
Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/module.h
Directory Properties:
  stable/11/   (props changed)

Copied: stable/11/sys/compat/linuxkpi/common/include/linux/export.h (from 
r334775, head/sys/compat/linuxkpi/common/include/linux/export.h)
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/export.h Wed Jun 20 
06:59:39 2018(r335435, copy of r334775, 
head/sys/compat/linuxkpi/common/include/linux/export.h)
@@ -0,0 +1,33 @@
+/*-
+ * Copyright (c) 2018 Johannes Lundberg 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice unmodified, this list of conditions, and the following
+ *disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+#ifndef_LINUX_EXPORT_H
+#define_LINUX_EXPORT_H
+
+#defineEXPORT_SYMBOL(name)
+#defineEXPORT_SYMBOL_GPL(name)
+
+#endif

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/module.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/module.h Wed Jun 20 
06:58:51 2018(r335434)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/module.h Wed Jun 20 
06:59:39 2018(r335435)
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MODULE_AUTHOR(name)
 #define MODULE_DESCRIPTION(name)
@@ -51,8 +52,6 @@
 
 #defineTHIS_MODULE ((struct module *)0)
 
-#defineEXPORT_SYMBOL(name)
-#defineEXPORT_SYMBOL_GPL(name)
 #define__MODULE_STRING(x) __stringify(x)
 
 /* OFED pre-module initialization */
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335434 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:58:51 2018
New Revision: 335434
URL: https://svnweb.freebsd.org/changeset/base/335434

Log:
  MFC r334662:
  Define the __kernel_size_t type in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/types.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/types.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/types.h  Wed Jun 20 
06:57:59 2018(r335433)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/types.h  Wed Jun 20 
06:58:51 2018(r335434)
@@ -62,6 +62,8 @@ typedef unsigned long pgoff_t;
 
 typedef u64 phys_addr_t;
 
+typedef size_t __kernel_size_t;
+
 #defineDECLARE_BITMAP(n, bits) 
\
unsigned long n[howmany(bits, sizeof(long) * 8)]
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335432 - stable/11/sys/compat/linuxkpi/common/include/asm

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:57:14 2018
New Revision: 335432
URL: https://svnweb.freebsd.org/changeset/base/335432

Log:
  MFC r334953:
  Implement the user_access_begin(), user_access_end(), usafe_get_user() and
  unsafe_put_user() function macros in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/asm/uaccess.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/asm/uaccess.h
==
--- stable/11/sys/compat/linuxkpi/common/include/asm/uaccess.h  Wed Jun 20 
06:56:18 2018(r335431)
+++ stable/11/sys/compat/linuxkpi/common/include/asm/uaccess.h  Wed Jun 20 
06:57:14 2018(r335432)
@@ -52,4 +52,17 @@ copy_from_user(void *to, const void *from, unsigned lo
 #define__copy_from_user(...)   copy_from_user(__VA_ARGS__)
 #define__copy_in_user(...) copy_from_user(__VA_ARGS__)
 
+#defineuser_access_begin() do { } while (0)
+#defineuser_access_end() do { } while (0)
+
+#defineunsafe_get_user(x, ptr, err) do { \
+   if (unlikely(__get_user(x, ptr))) \
+   goto err; \
+} while (0)
+
+#defineunsafe_put_user(x, ptr, err) do { \
+   if (unlikely(__put_user(x, ptr))) \
+   goto err; \
+} while (0)
+
 #endif /* _ASM_UACCESS_H_ */
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335433 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:57:59 2018
New Revision: 335433
URL: https://svnweb.freebsd.org/changeset/base/335433

Log:
  MFC r334958:
  Implement the kstrtobool() and kstrtobool_from_user() functions
  in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/kernel.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/kernel.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/kernel.h Wed Jun 20 
06:57:14 2018(r335432)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/kernel.h Wed Jun 20 
06:57:59 2018(r335433)
@@ -50,7 +50,9 @@
 #include 
 #include 
 #include 
+
 #include 
+#include 
 
 #include 
 
@@ -370,6 +372,46 @@ kstrtou32(const char *cp, unsigned int base, u32 *res)
if (temp != (u32)temp)
return (-ERANGE);
return (0);
+}
+
+static inline int
+kstrtobool(const char *s, bool *res)
+{
+   int len;
+
+   if (s == NULL || (len = strlen(s)) == 0 || res == NULL)
+   return (-EINVAL);
+
+   /* skip newline character, if any */
+   if (s[len - 1] == '\n')
+   len--;
+
+   if (len == 1 && strchr("yY1", s[0]) != NULL)
+   *res = true;
+   else if (len == 1 && strchr("nN0", s[0]) != NULL)
+   *res = false;
+   else if (strncasecmp("on", s, len) == 0)
+   *res = true;
+   else if (strncasecmp("off", s, len) == 0)
+   *res = false;
+   else
+   return (-EINVAL);
+
+   return (0);
+}
+
+static inline int
+kstrtobool_from_user(const char __user *s, size_t count, bool *res)
+{
+   char buf[8] = {};
+
+   if (count > (sizeof(buf) - 1))
+   count = (sizeof(buf) - 1);
+
+   if (copy_from_user(buf, s, count))
+   return (-EFAULT);
+
+   return (kstrtobool(buf, res));
 }
 
 #define min(x, y)  ((x) < (y) ? (x) : (y))
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335431 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:56:18 2018
New Revision: 335431
URL: https://svnweb.freebsd.org/changeset/base/335431

Log:
  MFC r334778:
  Define ARCH_KMALLOC_MINALIGN in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/slab.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/slab.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/slab.h   Wed Jun 20 
06:54:38 2018(r335430)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/slab.h   Wed Jun 20 
06:56:18 2018(r335431)
@@ -85,6 +85,9 @@ struct linux_kmem_cache {
 #defineSLAB_DESTROY_BY_RCU \
SLAB_TYPESAFE_BY_RCU
 
+#defineARCH_KMALLOC_MINALIGN \
+   __alignof(unsigned long long)
+
 static inline gfp_t
 linux_check_m_flags(gfp_t flags)
 {
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335430 - head/sys/security/mac_veriexec

[Stephen J. Kiernan]

Author: stevek
Date: Wed Jun 20 06:54:38 2018
New Revision: 335430
URL: https://svnweb.freebsd.org/changeset/base/335430

Log:
  Fix build breakage in veriexec for 32-bit architectures.
  
  fsid_t and ino_t are 64-bit entities, use uintmax_t typecast to ensure we
  can print it on 32-bit or 64-bit architectures by using the %ju format for
  prints.
  
  Obtained from:Juniper Networks, Inc.

Modified:
  head/sys/security/mac_veriexec/veriexec_fingerprint.c
  head/sys/security/mac_veriexec/veriexec_metadata.c

Modified: head/sys/security/mac_veriexec/veriexec_fingerprint.c
==
--- head/sys/security/mac_veriexec/veriexec_fingerprint.c   Wed Jun 20 
06:52:32 2018(r335429)
+++ head/sys/security/mac_veriexec/veriexec_fingerprint.c   Wed Jun 20 
06:54:38 2018(r335430)
@@ -108,11 +108,12 @@ identify_error (struct image_params *imgp, struct thre
gppid = (parent != NULL && parent->p_pptr != NULL) ?
parent->p_pptr->p_pid : 0;
 
-   log(LOG_ERR, MAC_VERIEXEC_FULLNAME ": %s (file=%s fsid=%lu fileid=%lu "
+   log(LOG_ERR, MAC_VERIEXEC_FULLNAME ": %s (file=%s fsid=%ju fileid=%ju "
"gen=%lu uid=%u pid=%u ppid=%u gppid=%u)", msg,
(imgp->args != NULL) ? imgp->args->fname : "",
-   imgp->attr->va_fsid, imgp->attr->va_fileid, imgp->attr->va_gen,
-   td->td_ucred->cr_ruid, imgp->proc->p_pid, ppid, gppid);
+   (uintmax_t)imgp->attr->va_fsid, (uintmax_t)imgp->attr->va_fileid,
+   imgp->attr->va_gen, td->td_ucred->cr_ruid, imgp->proc->p_pid,
+   ppid, gppid);
 }
 
 /**
@@ -217,8 +218,9 @@ mac_veriexec_fingerprint_check_vnode(struct vnode *vp,
return (ETXTBSY);
 
if ((vp->v_mount->mnt_flag & MNT_VERIFIED) != 0) {
-   VERIEXEC_DEBUG(2, ("file %lu.%lu on verified %s mount\n",
-   ip->fileid, ip->gen, vp->v_mount->mnt_vfc->vfc_name));
+   VERIEXEC_DEBUG(2, ("file %ju.%lu on verified %s mount\n",
+   (uintmax_t)ip->fileid, ip->gen,
+   vp->v_mount->mnt_vfc->vfc_name));
 
/*
 * The VFS is backed by a file which has been verified.

Modified: head/sys/security/mac_veriexec/veriexec_metadata.c
==
--- head/sys/security/mac_veriexec/veriexec_metadata.c  Wed Jun 20 06:52:32 
2018(r335429)
+++ head/sys/security/mac_veriexec/veriexec_metadata.c  Wed Jun 20 06:54:38 
2018(r335430)
@@ -110,8 +110,8 @@ get_veriexec_file(struct veriexec_devhead *head, dev_t
if (found_dev != NULL)
*found_dev = 0;
 
-   VERIEXEC_DEBUG(3, ("searching for file %lu.%lu on device %lu,"
-   " files=%d\n", fileid, gen, (unsigned long)fsid,
+   VERIEXEC_DEBUG(3, ("searching for file %ju.%lu on device %ju,"
+   " files=%d\n", (uintmax_t)fileid, gen, (uintmax_t)fsid,
(head == _file_dev_head)));
 
/* Get a lock to access the list */
@@ -124,8 +124,8 @@ get_veriexec_file(struct veriexec_devhead *head, dev_t
 
/* We found the file system in the list */
if (lp != NULL) {
-   VERIEXEC_DEBUG(3, ("found matching dev number %lu\n",
-   lp->fsid));
+   VERIEXEC_DEBUG(3, ("found matching dev number %ju\n",
+   (uintmax_t)lp->fsid));
 
/* If found_dev is non-NULL, store true there */
if (found_dev != NULL)
@@ -182,8 +182,8 @@ find_veriexec_file(dev_t fsid, long fileid, unsigned l
}
search[2] = NULL;
 
-   VERIEXEC_DEBUG(3, ("%s: searching for dev %lu, file %lu\n",
-   __func__, fsid, fileid));
+   VERIEXEC_DEBUG(3, ("%s: searching for dev %ju, file %lu\n",
+   __func__, (uintmax_t)fsid, fileid));
 
/* Search for the specified file */
for (ip = NULL, x = 0; ip == NULL && search[x]; x++)
@@ -226,7 +226,7 @@ mac_veriexec_print_db_head(struct sbuf *sbp, struct ve
struct veriexec_dev_list *lp;
 
for (lp = LIST_FIRST(head); lp != NULL; lp = LIST_NEXT(lp, entries)) {
-   sbuf_printf(sbp, " FS id: %lu\n", lp->fsid);
+   sbuf_printf(sbp, " FS id: %ju\n", (uintmax_t)lp->fsid);
mac_veriexec_print_db_dev_list(sbp, lp);
}
 
@@ -524,9 +524,9 @@ mac_veriexec_metadata_fetch_fingerprint_status(struct 
status = (found_dev) ? FINGERPRINT_NOENTRY :
FINGERPRINT_NODEV;
VERIEXEC_DEBUG(3,
-   ("fingerprint status is %d for dev %lu, file "
-   "%lu.%lu\n", status, vap->va_fsid, vap->va_fileid,
-   vap->va_gen));
+   ("fingerprint status is %d for dev %ju, file "
+   "%ju.%lu\n", status, (uintmax_t)vap->va_fsid,
+   

svn commit: r335429 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:52:32 2018
New Revision: 335429
URL: https://svnweb.freebsd.org/changeset/base/335429

Log:
  MFC r334777:
  Wrap timespec64 into timespec in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/ktime.h
  stable/11/sys/compat/linuxkpi/common/include/linux/time.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/ktime.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/ktime.h  Wed Jun 20 
06:51:41 2018(r335428)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/ktime.h  Wed Jun 20 
06:52:32 2018(r335429)
@@ -159,6 +159,7 @@ timeval_to_ktime(struct timeval tv)
 }
 
 #definektime_to_timespec(kt)   ns_to_timespec(kt)
+#definektime_to_timespec64(kt) ns_to_timespec(kt)
 #definektime_to_timeval(kt)ns_to_timeval(kt)
 #definektime_to_ns(kt) (kt)
 

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/time.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/time.h   Wed Jun 20 
06:51:41 2018(r335428)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/time.h   Wed Jun 20 
06:52:32 2018(r335429)
@@ -35,6 +35,8 @@
 #defineUSEC_PER_MSEC   1000L
 #defineUSEC_PER_SEC100L
 
+#definetimespec64 timespec
+
 #include 
 #include 
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335428 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:51:41 2018
New Revision: 335428
URL: https://svnweb.freebsd.org/changeset/base/335428

Log:
  MFC r334774:
  Implement the dev_pm_set_driver_flags() function macro in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/device.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/device.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/device.h Wed Jun 20 
06:50:56 2018(r335427)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/device.h Wed Jun 20 
06:51:41 2018(r335428)
@@ -461,6 +461,9 @@ device_destroy(struct class *class, dev_t devt)
device_unregister(device_get_softc(bsddev));
 }
 
+#definedev_pm_set_driver_flags(dev, flags) do { \
+} while (0)
+
 static inline void
 linux_class_kfree(struct class *class)
 {
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335427 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:50:56 2018
New Revision: 335427
URL: https://svnweb.freebsd.org/changeset/base/335427

Log:
  MFC r334720:
  Make some list functions RCU safe in the LinuxKPI.
  While at it rename hlist_add_after() into hlist_add_behind().
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/list.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/list.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/list.h   Wed Jun 20 
06:50:11 2018(r335426)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/list.h   Wed Jun 20 
06:50:56 2018(r335427)
@@ -337,16 +337,16 @@ static inline int
 hlist_empty(const struct hlist_head *h)
 {
 
-   return !h->first;
+   return !READ_ONCE(h->first);
 }
 
 static inline void
 hlist_del(struct hlist_node *n)
 {
 
-   if (n->next)
+   WRITE_ONCE(*(n->pprev), n->next);
+   if (n->next != NULL)
n->next->pprev = n->pprev;
-   *n->pprev = n->next;
 }
 
 static inline void
@@ -364,9 +364,9 @@ hlist_add_head(struct hlist_node *n, struct hlist_head
 {
 
n->next = h->first;
-   if (h->first)
+   if (h->first != NULL)
h->first->pprev = >next;
-   h->first = n;
+   WRITE_ONCE(h->first, n);
n->pprev = >first;
 }
 
@@ -377,18 +377,19 @@ hlist_add_before(struct hlist_node *n, struct hlist_no
n->pprev = next->pprev;
n->next = next;
next->pprev = >next;
-   *(n->pprev) = n;
+   WRITE_ONCE(*(n->pprev), n);
 }
 
 static inline void
-hlist_add_after(struct hlist_node *n, struct hlist_node *next)
+hlist_add_behind(struct hlist_node *n, struct hlist_node *prev)
 {
 
-   next->next = n->next;
-   n->next = next;
-   next->pprev = >next;
-   if (next->next)
-   next->next->pprev = >next;
+   n->next = prev->next;
+   WRITE_ONCE(prev->next, n);
+   n->pprev = >next;
+
+   if (n->next != NULL)
+   n->next->pprev = >next;
 }
 
 static inline void
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335426 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:50:11 2018
New Revision: 335426
URL: https://svnweb.freebsd.org/changeset/base/335426

Log:
  MFC r334717:
  Implement the __add_wait_queue_entry_tail() function in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/wait.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/wait.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/wait.h   Wed Jun 20 
06:49:26 2018(r335425)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/wait.h   Wed Jun 20 
06:50:11 2018(r335426)
@@ -54,7 +54,10 @@
 struct wait_queue;
 struct wait_queue_head;
 
+#definewait_queue_entry wait_queue
+
 typedef struct wait_queue wait_queue_t;
+typedef struct wait_queue_entry wait_queue_entry_t;
 typedef struct wait_queue_head wait_queue_head_t;
 
 typedef int wait_queue_func_t(wait_queue_t *, unsigned int, int, void *);
@@ -246,6 +249,12 @@ static inline void
 __add_wait_queue_tail(wait_queue_head_t *wqh, wait_queue_t *wq)
 {
list_add_tail(>task_list, >task_list);
+}
+
+static inline void
+__add_wait_queue_entry_tail(wait_queue_head_t *wqh, wait_queue_entry_t *wq)
+{
+list_add_tail(>entry, >head);
 }
 
 static inline void
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335425 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:49:26 2018
New Revision: 335425
URL: https://svnweb.freebsd.org/changeset/base/335425

Log:
  MFC r334715:
  Implement the might_sleep_if() function macro in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/wait.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/wait.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/wait.h   Wed Jun 20 
06:48:41 2018(r335424)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/wait.h   Wed Jun 20 
06:49:26 2018(r335425)
@@ -47,6 +47,10 @@
 #definemight_sleep()   
\
WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, "might_sleep()")
 
+#definemight_sleep_if(cond) do { \
+   if (cond) { might_sleep(); } \
+} while (0)
+
 struct wait_queue;
 struct wait_queue_head;
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335424 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:48:41 2018
New Revision: 335424
URL: https://svnweb.freebsd.org/changeset/base/335424

Log:
  MFC r334714:
  Rename two structure field members while keeping backwards compatibility in
  the LinuxKPI. Add a comment saying in which Linux version this change was 
made.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/wait.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/wait.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/wait.h   Wed Jun 20 
06:47:49 2018(r335423)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/wait.h   Wed Jun 20 
06:48:41 2018(r335424)
@@ -63,12 +63,18 @@ struct wait_queue {
unsigned int flags; /* always 0 */
void *private;
wait_queue_func_t *func;
-   struct list_head task_list;
+   union {
+   struct list_head task_list; /* < v4.13 */
+   struct list_head entry; /* >= v4.13 */
+   };
 };
 
 struct wait_queue_head {
spinlock_t lock;
-   struct list_head task_list;
+   union {
+   struct list_head task_list; /* < v4.13 */
+   struct list_head head; /* >= v4.13 */
+   };
 };
 
 /*
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335423 - in stable/11/sys/compat/linuxkpi/common: include/linux src

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:47:49 2018
New Revision: 335423
URL: https://svnweb.freebsd.org/changeset/base/335423

Log:
  MFC r334713:
  Implement the init_wait_entry() function macro in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/wait.h
  stable/11/sys/compat/linuxkpi/common/src/linux_schedule.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/wait.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/wait.h   Wed Jun 20 
06:46:54 2018(r335422)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/wait.h   Wed Jun 20 
06:47:49 2018(r335423)
@@ -106,8 +106,11 @@ extern wait_queue_func_t default_wake_function;
INIT_LIST_HEAD(&(wqh)->task_list);  \
 } while (0)
 
+void linux_init_wait_entry(wait_queue_t *, int);
 void linux_wake_up(wait_queue_head_t *, unsigned int, int, bool);
 
+#defineinit_wait_entry(wq, flags)  
\
+linux_init_wait_entry(wq, flags)
 #definewake_up(wqh)
\
linux_wake_up(wqh, TASK_NORMAL, 1, false)
 #definewake_up_all(wqh)
\

Modified: stable/11/sys/compat/linuxkpi/common/src/linux_schedule.c
==
--- stable/11/sys/compat/linuxkpi/common/src/linux_schedule.c   Wed Jun 20 
06:46:54 2018(r335422)
+++ stable/11/sys/compat/linuxkpi/common/src/linux_schedule.c   Wed Jun 20 
06:47:49 2018(r335423)
@@ -188,6 +188,17 @@ default_wake_function(wait_queue_t *wq, unsigned int s
 }
 
 void
+linux_init_wait_entry(wait_queue_t *wq, int flags)
+{
+
+   memset(wq, 0, sizeof(*wq));
+   wq->flags = flags;
+   wq->private = current;
+   wq->func = autoremove_wake_function;
+   INIT_LIST_HEAD(>task_list);
+}
+
+void
 linux_wake_up(wait_queue_head_t *wqh, unsigned int state, int nr, bool locked)
 {
wait_queue_t *pos, *next;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335422 - stable/11/sys/compat/linuxkpi/common/include/asm

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:46:54 2018
New Revision: 335422
URL: https://svnweb.freebsd.org/changeset/base/335422

Log:
  MFC r334712 and r334718:
  Implement the atomic_dec_if_positive() function in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/asm/atomic.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/asm/atomic.h
==
--- stable/11/sys/compat/linuxkpi/common/include/asm/atomic.h   Wed Jun 20 
06:43:41 2018(r335421)
+++ stable/11/sys/compat/linuxkpi/common/include/asm/atomic.h   Wed Jun 20 
06:46:54 2018(r335422)
@@ -235,6 +235,23 @@ atomic_cmpxchg(atomic_t *v, int old, int new)
__ret.val;  \
 })
 
+static inline int
+atomic_dec_if_positive(atomic_t *v)
+{
+   int retval;
+   int old;
+
+   old = atomic_read(v);
+   for (;;) {
+   retval = old - 1;
+   if (unlikely(retval < 0))
+   break;
+   if (likely(atomic_fcmpset_int(>counter, , retval)))
+   break;
+   }
+   return (retval);
+}
+
 #defineLINUX_ATOMIC_OP(op, c_op)   \
 static inline void atomic_##op(int i, atomic_t *v) \
 {  \
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335421 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:43:41 2018
New Revision: 335421
URL: https://svnweb.freebsd.org/changeset/base/335421

Log:
  MFC r334711:
  Implement the ktime_compare() and ktime_after() functions in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/ktime.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/ktime.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/ktime.h  Wed Jun 20 
06:42:51 2018(r335420)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/ktime.h  Wed Jun 20 
06:43:41 2018(r335421)
@@ -127,6 +127,25 @@ ktime_add(ktime_t lhs, ktime_t rhs)
return (lhs + rhs);
 }
 
+static inline int
+ktime_compare(const ktime_t cmp1, const ktime_t cmp2)
+{
+
+   if (cmp1 > cmp2)
+   return (1);
+   else if (cmp1 < cmp2)
+   return (-1);
+   else
+   return (0);
+}
+
+static inline bool
+ktime_after(const ktime_t cmp1, const ktime_t cmp2)
+{
+
+   return (ktime_compare(cmp1, cmp2) > 0);
+}
+
 static inline ktime_t
 timespec_to_ktime(struct timespec ts)
 {
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335420 - stable/11/sys/compat/linuxkpi/common/include/asm

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:42:51 2018
New Revision: 335420
URL: https://svnweb.freebsd.org/changeset/base/335420

Log:
  MFC r334710:
  Implement the rdmsrl_safe() function macro in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/asm/msr.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/asm/msr.h
==
--- stable/11/sys/compat/linuxkpi/common/include/asm/msr.h  Wed Jun 20 
06:42:04 2018(r335419)
+++ stable/11/sys/compat/linuxkpi/common/include/asm/msr.h  Wed Jun 20 
06:42:51 2018(r335420)
@@ -32,5 +32,6 @@
 #include 
 
 #definerdmsrl(msr, val)((val) = rdmsr(msr))
+#definerdmsrl_safe(msr, val)   rdmsr_safe(msr, val)
 
 #endif /* _ASM_MSR_H_ */
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335419 - in stable/11/sys/compat/linuxkpi/common: include/linux src

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:42:04 2018
New Revision: 335419
URL: https://svnweb.freebsd.org/changeset/base/335419

Log:
  MFC r334664:
  Declare and set the global "system_highpri_wq" workqueue structure pointer
  in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/workqueue.h
  stable/11/sys/compat/linuxkpi/common/src/linux_work.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/workqueue.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/workqueue.h  Wed Jun 
20 06:41:15 2018(r335418)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/workqueue.h  Wed Jun 
20 06:42:04 2018(r335419)
@@ -214,6 +214,7 @@ do {
\
 extern struct workqueue_struct *system_wq;
 extern struct workqueue_struct *system_long_wq;
 extern struct workqueue_struct *system_unbound_wq;
+extern struct workqueue_struct *system_highpri_wq;
 extern struct workqueue_struct *system_power_efficient_wq;
 
 extern void linux_init_delayed_work(struct delayed_work *, work_func_t);

Modified: stable/11/sys/compat/linuxkpi/common/src/linux_work.c
==
--- stable/11/sys/compat/linuxkpi/common/src/linux_work.c   Wed Jun 20 
06:41:15 2018(r335418)
+++ stable/11/sys/compat/linuxkpi/common/src/linux_work.c   Wed Jun 20 
06:42:04 2018(r335419)
@@ -55,6 +55,7 @@ static struct workqueue_struct *linux_system_long_wq;
 struct workqueue_struct *system_wq;
 struct workqueue_struct *system_long_wq;
 struct workqueue_struct *system_unbound_wq;
+struct workqueue_struct *system_highpri_wq;
 struct workqueue_struct *system_power_efficient_wq;
 
 static int linux_default_wq_cpus = 4;
@@ -598,6 +599,7 @@ linux_work_init(void *arg)
system_wq = linux_system_short_wq;
system_power_efficient_wq = linux_system_short_wq;
system_unbound_wq = linux_system_short_wq;
+   system_highpri_wq = linux_system_short_wq;
 }
 SYSINIT(linux_work_init, SI_SUB_TASKQ, SI_ORDER_THIRD, linux_work_init, NULL);
 
@@ -612,5 +614,6 @@ linux_work_uninit(void *arg)
system_wq = NULL;
system_power_efficient_wq = NULL;
system_unbound_wq = NULL;
+   system_highpri_wq = NULL;
 }
 SYSUNINIT(linux_work_uninit, SI_SUB_TASKQ, SI_ORDER_THIRD, linux_work_uninit, 
NULL);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335418 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:41:15 2018
New Revision: 335418
URL: https://svnweb.freebsd.org/changeset/base/335418

Log:
  MFC r334663:
  Implement the INIT_DELAYED_WORK_ONSTACK() function macro in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/workqueue.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/workqueue.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/workqueue.h  Wed Jun 
20 06:40:19 2018(r335417)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/workqueue.h  Wed Jun 
20 06:41:15 2018(r335418)
@@ -117,6 +117,9 @@ do {
\
 #defineINIT_DELAYED_WORK(dwork, fn) \
linux_init_delayed_work(dwork, fn)
 
+#defineINIT_DELAYED_WORK_ONSTACK(dwork, fn) \
+   linux_init_delayed_work(dwork, fn)
+
 #defineINIT_DEFERRABLE_WORK(dwork, fn) \
INIT_DELAYED_WORK(dwork, fn)
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335417 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:40:19 2018
New Revision: 335417
URL: https://svnweb.freebsd.org/changeset/base/335417

Log:
  MFC r334661:
  Implement the task_pid_vnr() function macro in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/sched.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/sched.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/sched.h  Wed Jun 20 
06:39:32 2018(r335416)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/sched.h  Wed Jun 20 
06:40:19 2018(r335417)
@@ -89,6 +89,7 @@ struct task_struct {
 #definetask_pid_group_leader(task) (task)->task_thread->td_proc->p_pid
 #definetask_pid(task)  ((task)->pid)
 #definetask_pid_nr(task)   ((task)->pid)
+#definetask_pid_vnr(task)  ((task)->pid)
 #defineget_pid(x)  (x)
 #defineput_pid(x)  do { } while (0)
 #definecurrent_euid()  (curthread->td_ucred->cr_uid)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335416 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:39:32 2018
New Revision: 335416
URL: https://svnweb.freebsd.org/changeset/base/335416

Log:
  MFC r334660:
  Add "access" function pointer to the "vm_operations_struct" structure
  in the LinuxKPI. While at it document when to use the "virtual_address" or
  the "address" field in the "vm_fault" structure.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/mm.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/mm.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/mm.h Wed Jun 20 
06:38:46 2018(r335415)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/mm.h Wed Jun 20 
06:39:32 2018(r335416)
@@ -120,8 +120,8 @@ struct vm_fault {
pgoff_t pgoff;
union {
/* user-space address */
-   void *virtual_address;
-   unsigned long address;
+   void *virtual_address;  /* < 4.11 */
+   unsigned long address;  /* >= 4.11 */
};
struct page *page;
struct vm_area_struct *vma;
@@ -131,6 +131,7 @@ struct vm_operations_struct {
void(*open) (struct vm_area_struct *);
void(*close) (struct vm_area_struct *);
int (*fault) (struct vm_area_struct *, struct vm_fault *);
+   int (*access) (struct vm_area_struct *, unsigned long, void *, int, 
int);
 };
 
 /*
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335415 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:38:46 2018
New Revision: 335415
URL: https://svnweb.freebsd.org/changeset/base/335415

Log:
  MFC r334659:
  Implement mul_u32_u32() function in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/math64.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/math64.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/math64.h Wed Jun 20 
06:38:03 2018(r335414)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/math64.h Wed Jun 20 
06:38:46 2018(r335415)
@@ -84,4 +84,11 @@ div_u64(uint64_t dividend, uint32_t divisor)
return (dividend / divisor);
 }
 
+static inline uint64_t
+mul_u32_u32(uint32_t a, uint32_t b)
+{
+
+   return ((uint64_t)a * b);
+}
+
 #endif /* _LINUX_MATH64_H */
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335414 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:38:03 2018
New Revision: 335414
URL: https://svnweb.freebsd.org/changeset/base/335414

Log:
  MFC r334658:
  Implement timer_setup() and from_timer() function macros in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/timer.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/timer.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/timer.h  Wed Jun 20 
06:37:15 2018(r335413)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/timer.h  Wed Jun 20 
06:38:03 2018(r335414)
@@ -39,7 +39,10 @@
 
 struct timer_list {
struct callout callout;
-   void(*function) (unsigned long);
+   union {
+   void (*function) (unsigned long);   /* < v4.15 */
+   void (*function_415) (struct timer_list *);
+   };
unsigned long data;
int expires;
 };
@@ -47,6 +50,16 @@ struct timer_list {
 extern unsigned long linux_timer_hz_mask;
 
 #defineTIMER_IRQSAFE   0x0001
+
+#definefrom_timer(var, arg, field) 
\
+container_of(arg, typeof(*(var)), field)
+
+#definetimer_setup(timer, func, flags) do {
\
+   CTASSERT(((flags) & ~TIMER_IRQSAFE) == 0);  \
+   (timer)->function_415 = (func); \
+   (timer)->data = (unsigned long)(timer); \
+   callout_init(&(timer)->callout, 1); \
+} while (0)
 
 #definesetup_timer(timer, func, dat) do {  
\
(timer)->function = (func); \
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335413 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:37:15 2018
New Revision: 335413
URL: https://svnweb.freebsd.org/changeset/base/335413

Log:
  MFC r334484:
  Implement the __sg_alloc_table_from_pages() function based on the existing
  sg_alloc_table_from_pages() function in the LinuxKPI.
  
  This basically allow segments to have a limit, max_segment.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/scatterlist.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/scatterlist.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/scatterlist.hWed Jun 
20 06:36:25 2018(r335412)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/scatterlist.hWed Jun 
20 06:37:15 2018(r335413)
@@ -64,6 +64,8 @@ struct sg_page_iter {
} internal;
 };
 
+#defineSCATTERLIST_MAX_SEGMENT (-1U & ~(PAGE_SIZE - 1))
+
 #defineSG_MAX_SINGLE_ALLOC (PAGE_SIZE / sizeof(struct scatterlist))
 
 #defineSG_MAGIC0x87654321UL
@@ -286,18 +288,26 @@ sg_alloc_table(struct sg_table *table, unsigned int ne
 }
 
 static inline int
-sg_alloc_table_from_pages(struct sg_table *sgt,
+__sg_alloc_table_from_pages(struct sg_table *sgt,
 struct page **pages, unsigned int count,
 unsigned long off, unsigned long size,
-gfp_t gfp_mask)
+unsigned int max_segment, gfp_t gfp_mask)
 {
-   unsigned int i, segs, cur;
+   unsigned int i, segs, cur, len;
int rc;
struct scatterlist *s;
 
+   if (__predict_false(!max_segment || offset_in_page(max_segment)))
+   return (-EINVAL);
+
+   len = 0;
for (segs = i = 1; i < count; ++i) {
-   if (page_to_pfn(pages[i]) != page_to_pfn(pages[i - 1]) + 1)
+   len += PAGE_SIZE;
+   if (len >= max_segment ||
+   page_to_pfn(pages[i]) != page_to_pfn(pages[i - 1]) + 1) {
++segs;
+   len = 0;
+   }
}
if (__predict_false((rc = sg_alloc_table(sgt, segs, gfp_mask
return (rc);
@@ -307,10 +317,13 @@ sg_alloc_table_from_pages(struct sg_table *sgt,
unsigned long seg_size;
unsigned int j;
 
-   for (j = cur + 1; j < count; ++j)
-   if (page_to_pfn(pages[j]) !=
+   len = 0;
+   for (j = cur + 1; j < count; ++j) {
+   len += PAGE_SIZE;
+   if (len >= max_segment || page_to_pfn(pages[j]) !=
page_to_pfn(pages[j - 1]) + 1)
break;
+   }
 
seg_size = ((j - cur) << PAGE_SHIFT) - off;
sg_set_page(s, pages[cur], min(size, seg_size), off);
@@ -321,6 +334,16 @@ sg_alloc_table_from_pages(struct sg_table *sgt,
return (0);
 }
 
+static inline int
+sg_alloc_table_from_pages(struct sg_table *sgt,
+struct page **pages, unsigned int count,
+unsigned long off, unsigned long size,
+gfp_t gfp_mask)
+{
+
+   return (__sg_alloc_table_from_pages(sgt, pages, count, off, size,
+   SCATTERLIST_MAX_SEGMENT, gfp_mask));
+}
 
 static inline int
 sg_nents(struct scatterlist *sg)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335412 - in stable/11/sys/compat/linuxkpi/common: include/linux src

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:36:25 2018
New Revision: 335412
URL: https://svnweb.freebsd.org/changeset/base/335412

Log:
  MFC r334483:
  Implement radix_tree_iter_delete() in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/radix-tree.h
  stable/11/sys/compat/linuxkpi/common/src/linux_radix.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/radix-tree.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/radix-tree.h Wed Jun 
20 06:35:37 2018(r335411)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/radix-tree.h Wed Jun 
20 06:36:25 2018(r335412)
@@ -79,5 +79,6 @@ void  *radix_tree_lookup(struct radix_tree_root *, unsi
 void   *radix_tree_delete(struct radix_tree_root *, unsigned long);
 intradix_tree_insert(struct radix_tree_root *, unsigned long, void *);
 bool   radix_tree_iter_find(struct radix_tree_root *, struct radix_tree_iter 
*, void ***);
+void   radix_tree_iter_delete(struct radix_tree_root *, struct radix_tree_iter 
*, void **);
 
 #endif /* _LINUX_RADIX_TREE_H_ */

Modified: stable/11/sys/compat/linuxkpi/common/src/linux_radix.c
==
--- stable/11/sys/compat/linuxkpi/common/src/linux_radix.c  Wed Jun 20 
06:35:37 2018(r335411)
+++ stable/11/sys/compat/linuxkpi/common/src/linux_radix.c  Wed Jun 20 
06:36:25 2018(r335412)
@@ -162,6 +162,13 @@ out:
return (item);
 }
 
+void
+radix_tree_iter_delete(struct radix_tree_root *root,
+struct radix_tree_iter *iter, void **slot)
+{
+   radix_tree_delete(root, iter->index);
+}
+
 int
 radix_tree_insert(struct radix_tree_root *root, unsigned long index, void 
*item)
 {
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335411 - in stable/11/sys/compat/linuxkpi/common: include/linux src

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:35:37 2018
New Revision: 335411
URL: https://svnweb.freebsd.org/changeset/base/335411

Log:
  MFC r334482:
  Improve high resolution timer support in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/hrtimer.h
  stable/11/sys/compat/linuxkpi/common/src/linux_hrtimer.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/hrtimer.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/hrtimer.hWed Jun 
20 06:34:31 2018(r335410)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/hrtimer.hWed Jun 
20 06:35:37 2018(r335411)
@@ -37,6 +37,7 @@
 
 enum hrtimer_mode {
HRTIMER_MODE_REL,
+   HRTIMER_MODE_REL_PINNED = HRTIMER_MODE_REL,
 };
 
 enum hrtimer_restart {
@@ -48,31 +49,42 @@ struct hrtimer {
enum hrtimer_restart (*function)(struct hrtimer *);
struct mtx mtx;
struct callout callout;
+   s64 expires;/* relative time in nanoseconds */
+   s64 precision;  /* in nanoseconds */
 };
 
 #definehrtimer_active(hrtimer) linux_hrtimer_active(hrtimer)
 #definehrtimer_cancel(hrtimer) linux_hrtimer_cancel(hrtimer)
+
 #definehrtimer_init(hrtimer, clock, mode) do { \
CTASSERT((clock) == CLOCK_MONOTONIC);   \
CTASSERT((mode) == HRTIMER_MODE_REL);   \
linux_hrtimer_init(hrtimer);\
 } while (0)
+
 #definehrtimer_set_expires(hrtimer, time)  \
linux_hrtimer_set_expires(hrtimer, time)
+
 #definehrtimer_start(hrtimer, time, mode) do { \
CTASSERT((mode) == HRTIMER_MODE_REL);   \
linux_hrtimer_start(hrtimer, time); \
 } while (0)
+
 #definehrtimer_start_range_ns(hrtimer, time, prec, mode) do {  \
CTASSERT((mode) == HRTIMER_MODE_REL);   \
linux_hrtimer_start_range_ns(hrtimer, time, prec);  \
 } while (0)
 
+#definehrtimer_forward_now(hrtimer, interval) do { \
+   linux_hrtimer_forward_now(hrtimer, interval);   \
+} while (0)
+
 bool   linux_hrtimer_active(struct hrtimer *);
 intlinux_hrtimer_cancel(struct hrtimer *);
 void   linux_hrtimer_init(struct hrtimer *);
 void   linux_hrtimer_set_expires(struct hrtimer *, ktime_t);
 void   linux_hrtimer_start(struct hrtimer *, ktime_t);
 void   linux_hrtimer_start_range_ns(struct hrtimer *, ktime_t, int64_t);
+void   linux_hrtimer_forward_now(struct hrtimer *, ktime_t);
 
 #endif /* _LINUX_HRTIMER_H_ */

Modified: stable/11/sys/compat/linuxkpi/common/src/linux_hrtimer.c
==
--- stable/11/sys/compat/linuxkpi/common/src/linux_hrtimer.cWed Jun 20 
06:34:31 2018(r335410)
+++ stable/11/sys/compat/linuxkpi/common/src/linux_hrtimer.cWed Jun 20 
06:35:37 2018(r335411)
@@ -45,8 +45,13 @@ hrtimer_call_handler(void *arg)
 
hrtimer = arg;
ret = hrtimer->function(hrtimer);
-   MPASS(ret == HRTIMER_NORESTART);
-   callout_deactivate(>callout);
+
+   if (ret == HRTIMER_RESTART) {
+   callout_schedule_sbt(>callout,
+   nstosbt(hrtimer->expires), nstosbt(hrtimer->precision), 0);
+   } else {
+   callout_deactivate(>callout);
+   }
 }
 
 bool
@@ -57,6 +62,7 @@ linux_hrtimer_active(struct hrtimer *hrtimer)
mtx_lock(>mtx);
ret = callout_active(>callout);
mtx_unlock(>mtx);
+
return (ret);
 }
 
@@ -75,15 +81,16 @@ void
 linux_hrtimer_init(struct hrtimer *hrtimer)
 {
 
-   hrtimer->function = NULL;
-   mtx_init(>mtx, "hrtimer", NULL, MTX_DEF | MTX_RECURSE);
+   memset(hrtimer, 0, sizeof(*hrtimer));
+   mtx_init(>mtx, "hrtimer", NULL,
+   MTX_DEF | MTX_RECURSE | MTX_NOWITNESS);
callout_init_mtx(>callout, >mtx, 0);
 }
 
 void
-linux_hrtimer_set_expires(struct hrtimer *hrtimer __unused,
-ktime_t time __unused)
+linux_hrtimer_set_expires(struct hrtimer *hrtimer, ktime_t time)
 {
+   hrtimer->expires = ktime_to_ns(time);
 }
 
 void
@@ -94,11 +101,24 @@ linux_hrtimer_start(struct hrtimer *hrtimer, ktime_t t
 }
 
 void
-linux_hrtimer_start_range_ns(struct hrtimer *hrtimer, ktime_t time, int64_t 
nsec)
+linux_hrtimer_start_range_ns(struct hrtimer *hrtimer, ktime_t time,
+int64_t nsec)
 {
 
mtx_lock(>mtx);
-   callout_reset_sbt(>callout, nstosbt(time), nstosbt(nsec),
-   hrtimer_call_handler, hrtimer, 0);
+   hrtimer->precision = nsec;
+   callout_reset_sbt(>callout, nstosbt(ktime_to_ns(time)),
+   nstosbt(nsec), hrtimer_call_handler, 

svn commit: r335410 - stable/11/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Wed Jun 20 06:34:31 2018
New Revision: 335410
URL: https://svnweb.freebsd.org/changeset/base/335410

Log:
  MFC r334481:
  Add more GFP macro definitions in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  stable/11/sys/compat/linuxkpi/common/include/linux/gfp.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/compat/linuxkpi/common/include/linux/gfp.h
==
--- stable/11/sys/compat/linuxkpi/common/include/linux/gfp.hWed Jun 20 
06:24:03 2018(r335409)
+++ stable/11/sys/compat/linuxkpi/common/include/linux/gfp.hWed Jun 20 
06:34:31 2018(r335410)
@@ -49,6 +49,9 @@
 #define__GFP_NORETRY   0
 #define__GFP_RECLAIM   0
 #define__GFP_RECLAIMABLE   0
+#define__GFP_RETRY_MAYFAIL 0
+#define__GFP_MOVABLE   0
+#define__GFP_COMP  0
 
 #define__GFP_IO0
 #define__GFP_NO_KSWAPD 0
@@ -56,6 +59,7 @@
 #define__GFP_DMA32 (1U << 24) /* LinuxKPI only */
 #define__GFP_BITS_SHIFT 25
 #define__GFP_BITS_MASK ((1 << __GFP_BITS_SHIFT) - 1)
+#define__GFP_NOFAILM_WAITOK
 
 #defineGFP_NOWAIT  M_NOWAIT
 #defineGFP_ATOMIC  (M_NOWAIT | M_USE_RESERVE)
@@ -68,6 +72,7 @@
 #defineGFP_DMA32   __GFP_DMA32
 #defineGFP_TEMPORARY   M_NOWAIT
 #defineGFP_NATIVE_MASK (M_NOWAIT | M_WAITOK | M_USE_RESERVE | M_ZERO)
+#defineGFP_TRANSHUGE   0
 
 CTASSERT((__GFP_DMA32 & GFP_NATIVE_MASK) == 0);
 CTASSERT((__GFP_BITS_MASK & GFP_NATIVE_MASK) == GFP_NATIVE_MASK);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335409 - stable/11/usr.sbin/sysrc

[Devin Teske]

Author: dteske
Date: Wed Jun 20 06:24:03 2018
New Revision: 335409
URL: https://svnweb.freebsd.org/changeset/base/335409

Log:
  MFC r334303: sysrc(8): Test variable names for invalid characters
  
  PR:   bin/187461
  Reported by:  e...@looksharp.net
  Sponsored by: Smule, Inc.

Modified:
  stable/11/usr.sbin/sysrc/sysrc
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/usr.sbin/sysrc/sysrc
==
--- stable/11/usr.sbin/sysrc/sysrc  Wed Jun 20 06:11:51 2018
(r335408)
+++ stable/11/usr.sbin/sysrc/sysrc  Wed Jun 20 06:24:03 2018
(r335409)
@@ -370,6 +370,18 @@ if [ "$LIST_SERVICE_CONFS" ]; then
 fi
 
 #
+# Validate arguments
+#
+for name in "$@"; do
+   # NB: shell expansion syntax removed first
+   name="${name%%:[+=-]*}"
+   name="${name%%[%#+=-]*}"
+   [ "$name" = "${name#*[!$VALID_VARNAME_CHARS]}" ] || die \
+   "%s: %s: name contains characters not allowed in shell" \
+   "$pgm" "$name"
+done
+
+#
 # Process `-s name' argument
 #
 if [ "$SERVICE" -a ! "${RC_CONFS+set}" ]; then
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Simon J. Gerraty]

Conrad Meyer  wrote:
> First and foremost: nothing is actually signed, anywhere.  The

The signing of manifests is external.  The veriexecctl tool is I assume
a straight copy of what's in NetBSD (I've not looked at it in at least a
decade).

A veriexec loader that leverages signed manifests requires some signing
infra.  That's a big topic all by itself.

As I mentioned in my talk at BSDCan, the signing server we use is open
source and handles pretty much anything OpenSSL can, as well as OpenPGP
(and others).
I also made a point of suggesting that the packages for base system
include signed manifests.

Tweaking the veriexec loader to only process manifests after
verification is not hard - one of the first things I did when pulling
veriexec into Junos almost 15 years ago.

> As a corollary to the above, the name "signature file" is used
> repeatedly in the code, which is misleading.  The file contains hashes
> (digests), not signatures (MACs).  The file itself is unsigned.
> Nothing about this has signatures.

NetBSD refers to the hashes as fingerprints - AFAIK that terminology is
retained.

If the term signature is used to refer to anything other than the signed
manifests that should be fixed.

> There's absolutely no reason to use sha1 or ripemd in new designs.
> These should be removed.

Sorry I disagree - not with ripem (we never supported that or any of the
non-NIST approved hashes), but sha1 is still approved by NIST for
firmware integrity checks - which is what this is, and sha1 is cheaper
than sha256.

As I mentioned in my talk we've included support for sha256 for 10+
years, but do not plan to drop sha1 until NIST deprecate it for that
purpose since boot time is a very sensitive subject for us.

> The patchset is littered with style issues.  One fairly obvious issue
> is mixed indentation styles — some files vary between space and tab
> indentation from line to line.

You can probably blame me for some of that.
I only recently found a style9.el that does a half decent job of
formatting per style(9).

> Please revert this patchset.  It's not ready.
> 
> Some suggestions for a second attempt:
> 
> - Maybe use HMACs instead of raw hashes

Why?

> - Maybe sign the source-of-trust file

We do.  As noted above, we cannot upstream that until FreeBSD has
suitable signing infra.

> - Fix the style issues
> - Fix the compiler warnings at 6
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"