svn commit: r344186 - head/sys/fs/fuse

2019-02-15 Thread Conrad Meyer
Author: cem
Date: Fri Feb 15 22:52:49 2019
New Revision: 344186
URL: https://svnweb.freebsd.org/changeset/base/344186

Log:
  FUSE: The FUSE design expects writethrough caching
  
  At least prior to 7.23 (which adds FUSE_WRITEBACK_CACHE), the FUSE protocol
  specifies only clean data to be cached.
  
  Prior to this change, we implement and default to writeback caching.  This
  is ok enough for local only filesystems without hardlinks, but violates the
  general design contract with FUSE and breaks distributed filesystems or
  concurrent access to hardlinks of the same inode.
  
  In this change, add cache mode as an extension of cache enable/disable.  The
  new modes are UC (was: cache disabled), WT (default), and WB (was: cache
  enabled).
  
  For now, WT caching is implemented as write-around, which meets the goal of
  only caching clean data.  WT can be better than WA for workloads that
  frequently read data that was recently written, but WA is trivial to
  implement.  Note that this has no effect on O_WRONLY-opened files, which
  were already coerced to write-around.
  
  Refs:
* https://sourceforge.net/p/fuse/mailman/message/8902254/
* https://github.com/vgough/encfs/issues/315
  
  PR:   230258 (inspired by)

Modified:
  head/sys/fs/fuse/fuse_io.c
  head/sys/fs/fuse/fuse_ipc.h
  head/sys/fs/fuse/fuse_node.c

Modified: head/sys/fs/fuse/fuse_io.c
==
--- head/sys/fs/fuse/fuse_io.c  Fri Feb 15 22:51:09 2019(r344185)
+++ head/sys/fs/fuse/fuse_io.c  Fri Feb 15 22:52:49 2019(r344186)
@@ -155,7 +155,13 @@ fuse_io_dispatch(struct vnode *vp, struct uio *uio, in
}
break;
case UIO_WRITE:
-   if (directio) {
+   /*
+* Kludge: simulate write-through caching via write-around
+* caching.  Same effect, as far as never caching dirty data,
+* but slightly pessimal in that newly written data is not
+* cached.
+*/
+   if (directio || fuse_data_cache_mode == FUSE_CACHE_WT) {
FS_DEBUG("direct write of vnode %ju via file handle 
%ju\n",
(uintmax_t)VTOILLU(vp), (uintmax_t)fufh->fh_id);
err = fuse_write_directbackend(vp, uio, cred, fufh, 
ioflag);
@@ -363,7 +369,7 @@ fuse_write_directbackend(struct vnode *vp, struct uio 
uio->uio_resid += diff;
uio->uio_offset -= diff;
if (uio->uio_offset > fvdat->filesize &&
-   fuse_data_cache_enable) {
+   fuse_data_cache_mode != FUSE_CACHE_UC) {
fuse_vnode_setsize(vp, cred, uio->uio_offset);
fvdat->flag &= ~FN_SIZECHANGE;
}

Modified: head/sys/fs/fuse/fuse_ipc.h
==
--- head/sys/fs/fuse/fuse_ipc.h Fri Feb 15 22:51:09 2019(r344185)
+++ head/sys/fs/fuse/fuse_ipc.h Fri Feb 15 22:52:49 2019(r344186)
@@ -214,7 +214,13 @@ struct fuse_data {
 #define FSESS_NO_MMAP 0x0800 /* disable mmap */
 #define FSESS_BROKENIO0x1000 /* fix broken io */
 
-extern int fuse_data_cache_enable;
+enum fuse_data_cache_mode {
+   FUSE_CACHE_UC,
+   FUSE_CACHE_WT,
+   FUSE_CACHE_WB,
+};
+
+extern int fuse_data_cache_mode;
 extern int fuse_data_cache_invalidate;
 extern int fuse_mmap_enable;
 extern int fuse_sync_resize;
@@ -248,7 +254,7 @@ fsess_opt_datacache(struct mount *mp)
 {
 struct fuse_data *data = fuse_get_mpdata(mp);
 
-return (fuse_data_cache_enable ||
+return (fuse_data_cache_mode != FUSE_CACHE_UC &&
 (data->dataflags & FSESS_NO_DATACACHE) == 0);
 }
 
@@ -257,7 +263,7 @@ fsess_opt_mmap(struct mount *mp)
 {
 struct fuse_data *data = fuse_get_mpdata(mp);
 
-if (!(fuse_mmap_enable && fuse_data_cache_enable))
+if (!fuse_mmap_enable || fuse_data_cache_mode == FUSE_CACHE_UC)
 return 0;
 return ((data->dataflags & (FSESS_NO_DATACACHE | FSESS_NO_MMAP)) == 0);
 }

Modified: head/sys/fs/fuse/fuse_node.c
==
--- head/sys/fs/fuse/fuse_node.cFri Feb 15 22:51:09 2019
(r344185)
+++ head/sys/fs/fuse/fuse_node.cFri Feb 15 22:52:49 2019
(r344186)
@@ -94,16 +94,19 @@ __FBSDID("$FreeBSD$");
 
 MALLOC_DEFINE(M_FUSEVN, "fuse_vnode", "fuse vnode private data");
 
+static int sysctl_fuse_cache_mode(SYSCTL_HANDLER_ARGS);
+
 static int fuse_node_count = 0;
 
 SYSCTL_INT(_vfs_fuse, OID_AUTO, node_count, CTLFLAG_RD,
 _node_count, 0, "Count of FUSE vnodes");
 
-intfuse_data_cache_enable = 1;
+intfuse_data_cache_mode = FUSE_CACHE_WT;
 
-SYSCTL_INT(_vfs_fuse, OID_AUTO, data_cache_enable, CTLFLAG_RW,
-_data_cache_enable, 0,
-"enable caching of FUSE file data 

svn commit: r344333 - head/sys/fs/fuse

2019-02-19 Thread Conrad Meyer
Author: cem
Date: Wed Feb 20 02:48:59 2019
New Revision: 344333
URL: https://svnweb.freebsd.org/changeset/base/344333

Log:
  fuse: add descriptions for remaining sysctls
  
  (Except reclaim revoked; I don't know what that goal of that one is.)

Modified:
  head/sys/fs/fuse/fuse_file.c
  head/sys/fs/fuse/fuse_vnops.c

Modified: head/sys/fs/fuse/fuse_file.c
==
--- head/sys/fs/fuse/fuse_file.cWed Feb 20 02:40:38 2019
(r344332)
+++ head/sys/fs/fuse/fuse_file.cWed Feb 20 02:48:59 2019
(r344333)
@@ -88,7 +88,7 @@ __FBSDID("$FreeBSD$");
 static int fuse_fh_count = 0;
 
 SYSCTL_INT(_vfs_fuse, OID_AUTO, filehandle_count, CTLFLAG_RD,
-_fh_count, 0, "");
+_fh_count, 0, "number of open FUSE filehandles");
 
 int
 fuse_filehandle_open(struct vnode *vp,

Modified: head/sys/fs/fuse/fuse_vnops.c
==
--- head/sys/fs/fuse/fuse_vnops.c   Wed Feb 20 02:40:38 2019
(r344332)
+++ head/sys/fs/fuse/fuse_vnops.c   Wed Feb 20 02:48:59 2019
(r344333)
@@ -180,17 +180,17 @@ struct vop_vector fuse_vnops = {
 static u_long fuse_lookup_cache_hits = 0;
 
 SYSCTL_ULONG(_vfs_fuse, OID_AUTO, lookup_cache_hits, CTLFLAG_RD,
-_lookup_cache_hits, 0, "");
+_lookup_cache_hits, 0, "number of positive cache hits in lookup");
 
 static u_long fuse_lookup_cache_misses = 0;
 
 SYSCTL_ULONG(_vfs_fuse, OID_AUTO, lookup_cache_misses, CTLFLAG_RD,
-_lookup_cache_misses, 0, "");
+_lookup_cache_misses, 0, "number of cache misses in lookup");
 
 intfuse_lookup_cache_enable = 1;
 
 SYSCTL_INT(_vfs_fuse, OID_AUTO, lookup_cache_enable, CTLFLAG_RW,
-_lookup_cache_enable, 0, "");
+_lookup_cache_enable, 0, "if non-zero, enable lookup cache");
 
 /*
  * XXX: This feature is highly experimental and can bring to instabilities,
___
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: r344334 - head/sys/fs/fuse

2019-02-19 Thread Conrad Meyer
Author: cem
Date: Wed Feb 20 02:49:26 2019
New Revision: 344334
URL: https://svnweb.freebsd.org/changeset/base/344334

Log:
  Fuse: whitespace and style(9) cleanup
  
  Take a pass through fixing some of the most egregious whitespace issues in
  fs/fuse.  Also fix some style(9) warts while here.  Not 100% cleaned up, but
  somewhat less painful to look at and edit.
  
  No functional change.

Modified:
  head/sys/fs/fuse/fuse.h
  head/sys/fs/fuse/fuse_device.c
  head/sys/fs/fuse/fuse_file.c
  head/sys/fs/fuse/fuse_file.h
  head/sys/fs/fuse/fuse_internal.h
  head/sys/fs/fuse/fuse_ipc.c
  head/sys/fs/fuse/fuse_ipc.h
  head/sys/fs/fuse/fuse_node.c
  head/sys/fs/fuse/fuse_node.h
  head/sys/fs/fuse/fuse_vfsops.c
  head/sys/fs/fuse/fuse_vnops.c

Modified: head/sys/fs/fuse/fuse.h
==
--- head/sys/fs/fuse/fuse.h Wed Feb 20 02:48:59 2019(r344333)
+++ head/sys/fs/fuse/fuse.h Wed Feb 20 02:49:26 2019(r344334)
@@ -197,26 +197,27 @@ do {  \
 #define FUSE_TRACE  0
 #endif
 
-#define DEBUGX(cond, fmt, ...) do { \
-if (((cond))) { \
-printf("%s: " fmt, __func__, ## __VA_ARGS__);   \
-} } while (0)
+#define DEBUGX(cond, fmt, ...) do {\
+   if (((cond))) { \
+   printf("%s: " fmt, __func__, ## __VA_ARGS__);   \
+   }   \
+} while (0)
 
-#define fuse_lck_mtx_lock(mtx) do { \
-DEBUGX(FUSE_DEBUG_LOCK, "0:   lock(%s): %s@%d by %d\n", \
-__STRING(mtx), __func__, __LINE__, curthread->td_proc->p_pid);  \
-mtx_lock(&(mtx));   \
-DEBUGX(FUSE_DEBUG_LOCK, "1:   lock(%s): %s@%d by %d\n", \
-__STRING(mtx), __func__, __LINE__, curthread->td_proc->p_pid);  \
-} while (0)
+#define fuse_lck_mtx_lock(mtx) do {
\
+   DEBUGX(FUSE_DEBUG_LOCK, "0:   lock(%s): %s@%d by %d\n", 
\
+   __STRING(mtx), __func__, __LINE__, curthread->td_proc->p_pid);  
\
+   mtx_lock(&(mtx));   
\
+   DEBUGX(FUSE_DEBUG_LOCK, "1:   lock(%s): %s@%d by %d\n", 
\
+   __STRING(mtx), __func__, __LINE__, curthread->td_proc->p_pid);  
\
+} while (0)
 
-#define fuse_lck_mtx_unlock(mtx) do {   \
-DEBUGX(FUSE_DEBUG_LOCK, "0: unlock(%s): %s@%d by %d\n", \
-__STRING(mtx), __func__, __LINE__, curthread->td_proc->p_pid);  \
-mtx_unlock(&(mtx)); \
-DEBUGX(FUSE_DEBUG_LOCK, "1: unlock(%s): %s@%d by %d\n", \
-__STRING(mtx), __func__, __LINE__, curthread->td_proc->p_pid);  \
-} while (0)
+#define fuse_lck_mtx_unlock(mtx) do {  
\
+   DEBUGX(FUSE_DEBUG_LOCK, "0: unlock(%s): %s@%d by %d\n", 
\
+   __STRING(mtx), __func__, __LINE__, curthread->td_proc->p_pid);  
\
+   mtx_unlock(&(mtx)); 
\
+   DEBUGX(FUSE_DEBUG_LOCK, "1: unlock(%s): %s@%d by %d\n", 
\
+   __STRING(mtx), __func__, __LINE__, curthread->td_proc->p_pid);  
\
+} while (0)
 
 void fuse_ipc_init(void);
 void fuse_ipc_destroy(void);

Modified: head/sys/fs/fuse/fuse_device.c
==
--- head/sys/fs/fuse/fuse_device.c  Wed Feb 20 02:48:59 2019
(r344333)
+++ head/sys/fs/fuse/fuse_device.c  Wed Feb 20 02:49:26 2019
(r344334)
@@ -317,7 +317,7 @@ again:
return (err);
 }
 
-static __inline int
+static inline int
 fuse_ohead_audit(struct fuse_out_header *ohead, struct uio *uio)
 {
FS_DEBUG("Out header -- len: %i, error: %i, unique: %llu; iovecs: %d\n",

Modified: head/sys/fs/fuse/fuse_file.c
==
--- head/sys/fs/fuse/fuse_file.cWed Feb 20 02:48:59 2019
(r344333)
+++ head/sys/fs/fuse/fuse_file.cWed Feb 20 02:49:26 2019
(r344334)
@@ -91,11 +91,8 @@ SYSCTL_INT(_vfs_fuse, OID_AUTO, filehandle_count, CTLF
 _fh_count, 0, "number of open FUSE filehandles");
 
 int
-fuse_filehandle_open(struct vnode *vp,
-fufh_type_t fufh_type,
-struct fuse_filehandle **fufhp,
-struct thread *td,
-struct ucred *cred)
+fuse_filehandle_open(struct vnode *vp, fufh_type_t fufh_type,
+struct fuse_filehandle **fufhp, struct thread *td, struct ucred *cred)
 {
struct fuse_dispatcher fdi;
struct fuse_open_in *foi;
@@ -114,8 +111,8 

svn commit: r343670 - in head/sys: dev/qlnx/qlnxe dev/qlnx/qlnxr modules/qlnx/qlnxr

2019-02-01 Thread Conrad Meyer
Author: cem
Date: Fri Feb  1 23:04:45 2019
New Revision: 343670
URL: https://svnweb.freebsd.org/changeset/base/343670

Log:
  qlnxr(4), qlnxe(4): Unbreak gcc build
  
  Remove redundant definitions and conditionalize Clang-specific CFLAGS.
  
  Sponsored by: Dell EMC Isilon

Modified:
  head/sys/dev/qlnx/qlnxe/qlnx_rdma.h
  head/sys/dev/qlnx/qlnxr/qlnxr_verbs.c
  head/sys/modules/qlnx/qlnxr/Makefile

Modified: head/sys/dev/qlnx/qlnxe/qlnx_rdma.h
==
--- head/sys/dev/qlnx/qlnxe/qlnx_rdma.h Fri Feb  1 22:24:14 2019
(r343669)
+++ head/sys/dev/qlnx/qlnxe/qlnx_rdma.h Fri Feb  1 23:04:45 2019
(r343670)
@@ -51,8 +51,6 @@ typedef struct qlnx_rdma_if qlnx_rdma_if_t;
 
 extern int qlnx_rdma_register_if(qlnx_rdma_if_t *rdma_if);
 extern int qlnx_rdma_deregister_if(qlnx_rdma_if_t *rdma_if);
-extern int qlnx_rdma_ll2_set_mac_filter(void *rdma_ctx, uint8_t 
*old_mac_address,
-uint8_t *new_mac_address);
 
 #define QLNX_NUM_CNQ   1
 

Modified: head/sys/dev/qlnx/qlnxr/qlnxr_verbs.c
==
--- head/sys/dev/qlnx/qlnxr/qlnxr_verbs.c   Fri Feb  1 22:24:14 2019
(r343669)
+++ head/sys/dev/qlnx/qlnxr/qlnxr_verbs.c   Fri Feb  1 23:04:45 2019
(r343670)
@@ -74,16 +74,6 @@ __FBSDID("$FreeBSD$");
((unsigned char *))[2], \
((unsigned char *))[3]
 
-struct ib_srq *qlnxr_create_srq(struct ib_pd *,
-   struct ib_srq_init_attr *,
-   struct ib_udata *);
-
-int qlnxr_destroy_srq(struct ib_srq *);
-
-int qlnxr_modify_srq(struct ib_srq *,
-   struct ib_srq_attr *,
-   enum ib_srq_attr_mask,
-   struct ib_udata *);
 static int
 qlnxr_check_srq_params(struct ib_pd *ibpd,
struct qlnxr_dev *dev,
@@ -99,19 +89,6 @@ static int
 qlnxr_alloc_srq_kernel_params(struct qlnxr_srq *srq,
struct qlnxr_dev *dev,
struct ib_srq_init_attr *init_attr);
-
-extern enum _ecore_status_t
-ecore_rdma_modify_srq(void *rdma_cxt,
-   struct ecore_rdma_modify_srq_in_params *in_params);
-
-extern enum _ecore_status_t
-ecore_rdma_destroy_srq(void *rdma_cxt,
-   struct ecore_rdma_destroy_srq_in_params *in_params);
-
-extern enum _ecore_status_t
-ecore_rdma_create_srq(void *rdma_cxt,
-   struct ecore_rdma_create_srq_in_params *in_params,
-   struct ecore_rdma_create_srq_out_params *out_params);
 
 
 static int

Modified: head/sys/modules/qlnx/qlnxr/Makefile
==
--- head/sys/modules/qlnx/qlnxr/MakefileFri Feb  1 22:24:14 2019
(r343669)
+++ head/sys/modules/qlnx/qlnxr/MakefileFri Feb  1 23:04:45 2019
(r343670)
@@ -62,12 +62,14 @@ CFLAGS+= -DINET6 -DINET
 
 CWARNEXTRA += -Wno-cast-qual
 CWARNEXTRA += -Wno-unused-function
+.if ${COMPILER_TYPE} == "clang"
 CWARNEXTRA += -Wno-gnu-variable-sized-type-not-at-end
+.endif
 CWARNEXTRA += -Wno-missing-prototypes
-CWARNEXTRA += -Wno-constant-conversion
+CWARNEXTRA += ${NO_WCONSTANT_CONVERSION}
 CWARNEXTRA += -Wno-format
 
-CWARNEXTRA += -Wno-shift-sign-overflow
+CWARNEXTRA += ${NO_WSHIFT_COUNT_OVERFLOW}
 CWARNEXTRA += -Wno-empty-body
 
 CFLAGS += -DQLNX_DEBUG
___
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: r343761 - head/sys/kern

2019-02-04 Thread Conrad Meyer
Author: cem
Date: Tue Feb  5 03:32:58 2019
New Revision: 343761
URL: https://svnweb.freebsd.org/changeset/base/343761

Log:
  extattr_list_vp: Only take shared vnode lock
  
  List is a 'read'-type operation that does not modify shared state; it's safe
  for multiple thread to proceed concurrently.  This is reflected in the vnode
  operation LISTEXTATTR locking protocol specification, which only requires a
  shared lock.
  
  (Similar to previous r248933.)
  
  Reported by:  Case van Rij 
  Reviewed by:  kib, mjg
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D19082

Modified:
  head/sys/kern/vfs_extattr.c

Modified: head/sys/kern/vfs_extattr.c
==
--- head/sys/kern/vfs_extattr.c Tue Feb  5 03:01:10 2019(r343760)
+++ head/sys/kern/vfs_extattr.c Tue Feb  5 03:32:58 2019(r343761)
@@ -633,7 +633,7 @@ extattr_list_vp(struct vnode *vp, int attrnamespace, v
if (nbytes > IOSIZE_MAX)
return (EINVAL);
 
-   vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
+   vn_lock(vp, LK_SHARED | LK_RETRY);
 
auiop = NULL;
sizep = 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: r343762 - head/sys/kern

2019-02-04 Thread Conrad Meyer
Author: cem
Date: Tue Feb  5 04:47:21 2019
New Revision: 343762
URL: https://svnweb.freebsd.org/changeset/base/343762

Log:
  extattr_list_vp: Narrow locked section somewhat
  
  Suggested by: mjg
  Reviewed by:  kib, mjg
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D19083

Modified:
  head/sys/kern/vfs_extattr.c

Modified: head/sys/kern/vfs_extattr.c
==
--- head/sys/kern/vfs_extattr.c Tue Feb  5 03:32:58 2019(r343761)
+++ head/sys/kern/vfs_extattr.c Tue Feb  5 04:47:21 2019(r343762)
@@ -633,8 +633,6 @@ extattr_list_vp(struct vnode *vp, int attrnamespace, v
if (nbytes > IOSIZE_MAX)
return (EINVAL);
 
-   vn_lock(vp, LK_SHARED | LK_RETRY);
-
auiop = NULL;
sizep = NULL;
cnt = 0;
@@ -653,24 +651,25 @@ extattr_list_vp(struct vnode *vp, int attrnamespace, v
} else
sizep = 
 
+   vn_lock(vp, LK_SHARED | LK_RETRY);
+
 #ifdef MAC
error = mac_vnode_check_listextattr(td->td_ucred, vp, attrnamespace);
-   if (error)
-   goto done;
+   if (error) {
+   VOP_UNLOCK(vp, 0);
+   return (error);
+   }
 #endif
 
error = VOP_LISTEXTATTR(vp, attrnamespace, auiop, sizep,
td->td_ucred, td);
+   VOP_UNLOCK(vp, 0);
 
if (auiop != NULL) {
cnt -= auio.uio_resid;
td->td_retval[0] = cnt;
} else
td->td_retval[0] = size;
-#ifdef MAC
-done:
-#endif
-   VOP_UNLOCK(vp, 0);
return (error);
 }
 
___
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: r346116 - head/usr.bin/sort

2019-04-10 Thread Conrad Meyer
Author: cem
Date: Thu Apr 11 05:08:49 2019
New Revision: 346116
URL: https://svnweb.freebsd.org/changeset/base/346116

Log:
  sort(1): Simplify and bound random seeding
  
  Bound input file processing length to avoid the issue reported in [1].  For
  simplicity, only allow regular file and character device inputs.  For
  character devices, only allow /dev/random (and /dev/urandom symblink).
  
  32 bytes of random is perfectly sufficient to seed MD5; we don't need any
  more.  Users that want to use large files as seeds are encouraged to truncate
  those files down to an appropriate input file via tools like sha256(1).
  
  (This does not change the sort algorithm of sort -R.)
  
  [1]: 
https://lists.freebsd.org/pipermail/freebsd-hackers/2018-August/053152.html
  
  PR:   230792
  Reported by:  Ali Abdallah 
  Relnotes: yes

Modified:
  head/usr.bin/sort/sort.c

Modified: head/usr.bin/sort/sort.c
==
--- head/usr.bin/sort/sort.cThu Apr 11 04:24:41 2019(r346115)
+++ head/usr.bin/sort/sort.cThu Apr 11 05:08:49 2019(r346116)
@@ -36,6 +36,7 @@ __FBSDID("$FreeBSD$");
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -61,13 +62,7 @@ nl_catd catalog;
 
 #defineOPTIONS "bcCdfghik:Mmno:RrsS:t:T:uVz"
 
-#define DEFAULT_RANDOM_SORT_SEED_FILE ("/dev/random")
-#define MAX_DEFAULT_RANDOM_SEED_DATA_SIZE (1024)
-
 static bool need_random;
-static const char *random_source = DEFAULT_RANDOM_SORT_SEED_FILE;
-static const void *random_seed;
-static size_t random_seed_size;
 
 MD5_CTX md5_ctx;
 
@@ -907,55 +902,76 @@ fix_obsolete_keys(int *argc, char **argv)
 }
 
 /*
- * Set random seed
+ * Seed random sort
  */
 static void
-set_random_seed(void)
+get_random_seed(const char *random_source)
 {
-   if (strcmp(random_source, DEFAULT_RANDOM_SORT_SEED_FILE) == 0) {
-   FILE* fseed;
-   MD5_CTX ctx;
-   char rsd[MAX_DEFAULT_RANDOM_SEED_DATA_SIZE];
-   size_t sz = 0;
+   char randseed[32];
+   struct stat fsb, rsb;
+   ssize_t rd;
+   int rsfd;
 
-   fseed = openfile(random_source, "r");
-   while (!feof(fseed)) {
-   int cr;
+   rsfd = -1;
+   rd = sizeof(randseed);
 
-   cr = fgetc(fseed);
-   if (cr == EOF)
-   break;
+   if (random_source == NULL) {
+   if (getentropy(randseed, sizeof(randseed)) < 0)
+   err(EX_SOFTWARE, "getentropy");
+   goto out;
+   }
 
-   rsd[sz++] = (char) cr;
+   rsfd = open(random_source, O_RDONLY | O_CLOEXEC);
+   if (rsfd < 0)
+   err(EX_NOINPUT, "open: %s", random_source);
 
-   if (sz >= MAX_DEFAULT_RANDOM_SEED_DATA_SIZE)
-   break;
-   }
+   if (fstat(rsfd, ) != 0)
+   err(EX_SOFTWARE, "fstat");
 
-   closefile(fseed, random_source);
+   if (!S_ISREG(fsb.st_mode) && !S_ISCHR(fsb.st_mode))
+   err(EX_USAGE,
+   "random seed isn't a regular file or /dev/random");
 
-   MD5Init();
-   MD5Update(, rsd, sz);
+   /*
+* Regular files: read up to maximum seed size and explicitly
+* reject longer files.
+*/
+   if (S_ISREG(fsb.st_mode)) {
+   if (fsb.st_size > (off_t)sizeof(randseed))
+   errx(EX_USAGE, "random seed is too large (%jd >"
+   " %zu)!", (intmax_t)fsb.st_size,
+   sizeof(randseed));
+   else if (fsb.st_size < 1)
+   errx(EX_USAGE, "random seed is too small ("
+   "0 bytes)");
 
-   random_seed = MD5End(, NULL);
-   random_seed_size = strlen(random_seed);
+   memset(randseed, 0, sizeof(randseed));
 
-   } else {
-   MD5_CTX ctx;
-   char *b;
+   rd = read(rsfd, randseed, fsb.st_size);
+   if (rd < 0)
+   err(EX_SOFTWARE, "reading random seed file %s",
+   random_source);
+   if (rd < (ssize_t)fsb.st_size)
+   errx(EX_SOFTWARE, "short read from %s", random_source);
+   } else if (S_ISCHR(fsb.st_mode)) {
+   if (stat("/dev/random", ) < 0)
+   err(EX_SOFTWARE, "stat");
 
-   MD5Init();
-   b = MD5File(random_source, NULL);
-   if (b == NULL)
-   err(2, NULL);
+   if (fsb.st_dev != rsb.st_dev ||
+   fsb.st_ino != rsb.st_ino)
+   errx(EX_USAGE, "random seed is a character "
+   "device other than /dev/random");
 
-   random_seed = b;
-

svn commit: r346110 - head/usr.bin/sort

2019-04-10 Thread Conrad Meyer
Author: cem
Date: Thu Apr 11 00:39:06 2019
New Revision: 346110
URL: https://svnweb.freebsd.org/changeset/base/346110

Log:
  sort(1): Whitespace and style cleanup
  
  No functional change.
  
  Sponsored by: Dell EMC Isilon

Modified:
  head/usr.bin/sort/sort.c

Modified: head/usr.bin/sort/sort.c
==
--- head/usr.bin/sort/sort.cWed Apr 10 22:26:59 2019(r346109)
+++ head/usr.bin/sort/sort.cThu Apr 11 00:39:06 2019(r346110)
@@ -566,55 +566,57 @@ static bool
 set_sort_modifier(struct sort_mods *sm, int c)
 {
 
-   if (sm) {
-   switch (c){
-   case 'b':
-   sm->bflag = true;
-   break;
-   case 'd':
-   sm->dflag = true;
-   break;
-   case 'f':
-   sm->fflag = true;
-   break;
-   case 'g':
-   sm->gflag = true;
-   need_hint = true;
-   break;
-   case 'i':
-   sm->iflag = true;
-   break;
-   case 'R':
-   sm->Rflag = true;
-   need_random = true;
-   break;
-   case 'M':
-   initialise_months();
-   sm->Mflag = true;
-   need_hint = true;
-   break;
-   case 'n':
-   sm->nflag = true;
-   need_hint = true;
-   print_symbols_on_debug = true;
-   break;
-   case 'r':
-   sm->rflag = true;
-   break;
-   case 'V':
-   sm->Vflag = true;
-   break;
-   case 'h':
-   sm->hflag = true;
-   need_hint = true;
-   print_symbols_on_debug = true;
-   break;
-   default:
-   return false;
-   }
-   sort_opts_vals.complex_sort = true;
-   sm->func = get_sort_func(sm);
+   if (sm == NULL)
+   return (true);
+
+   switch (c){
+   case 'b':
+   sm->bflag = true;
+   break;
+   case 'd':
+   sm->dflag = true;
+   break;
+   case 'f':
+   sm->fflag = true;
+   break;
+   case 'g':
+   sm->gflag = true;
+   need_hint = true;
+   break;
+   case 'i':
+   sm->iflag = true;
+   break;
+   case 'R':
+   sm->Rflag = true;
+   need_random = true;
+   break;
+   case 'M':
+   initialise_months();
+   sm->Mflag = true;
+   need_hint = true;
+   break;
+   case 'n':
+   sm->nflag = true;
+   need_hint = true;
+   print_symbols_on_debug = true;
+   break;
+   case 'r':
+   sm->rflag = true;
+   break;
+   case 'V':
+   sm->Vflag = true;
+   break;
+   case 'h':
+   sm->hflag = true;
+   need_hint = true;
+   print_symbols_on_debug = true;
+   break;
+   default:
+   return (false);
}
+
+   sort_opts_vals.complex_sort = true;
+   sm->func = get_sort_func(sm);
return (true);
 }
 
@@ -910,54 +912,50 @@ fix_obsolete_keys(int *argc, char **argv)
 static void
 set_random_seed(void)
 {
-   if (need_random) {
+   if (strcmp(random_source, DEFAULT_RANDOM_SORT_SEED_FILE) == 0) {
+   FILE* fseed;
+   MD5_CTX ctx;
+   char rsd[MAX_DEFAULT_RANDOM_SEED_DATA_SIZE];
+   size_t sz = 0;
 
-   if (strcmp(random_source, DEFAULT_RANDOM_SORT_SEED_FILE) == 0) {
-   FILE* fseed;
-   MD5_CTX ctx;
-   char rsd[MAX_DEFAULT_RANDOM_SEED_DATA_SIZE];
-   size_t sz = 0;
+   fseed = openfile(random_source, "r");
+   while (!feof(fseed)) {
+   int cr;
 
-   fseed = openfile(random_source, "r");
-   while (!feof(fseed)) {
-   int cr;
+   cr = fgetc(fseed);
+   if (cr == EOF)
+   break;
 
-   cr = fgetc(fseed);
-   if (cr == EOF)
-   break;
+   rsd[sz++] = (char) cr;
 
-   rsd[sz++] = (char) cr;
+   if (sz >= 

svn commit: r345993 - head/sys/kern

2019-04-06 Thread Conrad Meyer
Author: cem
Date: Sat Apr  6 21:56:24 2019
New Revision: 345993
URL: https://svnweb.freebsd.org/changeset/base/345993

Log:
  kern/subr_pctrie: Fix mismatched signedness in assertion comparison
  
  'tos' is an index into an array and never holds a negative value.  Correct
  its signedness to match PCTRIE_LIMIT, which it is compared to in assertions.
  
  No functional change (kills a warning).

Modified:
  head/sys/kern/subr_pctrie.c

Modified: head/sys/kern/subr_pctrie.c
==
--- head/sys/kern/subr_pctrie.c Sat Apr  6 21:53:46 2019(r345992)
+++ head/sys/kern/subr_pctrie.c Sat Apr  6 21:56:24 2019(r345993)
@@ -385,7 +385,8 @@ pctrie_lookup_ge(struct pctrie *ptree, uint64_t index)
 #ifdef INVARIANTS
int loops = 0;
 #endif
-   int slot, tos;
+   unsigned tos;
+   int slot;
 
node = pctrie_getroot(ptree);
if (node == NULL)
@@ -496,7 +497,8 @@ pctrie_lookup_le(struct pctrie *ptree, uint64_t index)
 #ifdef INVARIANTS
int loops = 0;
 #endif
-   int slot, tos;
+   unsigned tos;
+   int slot;
 
node = pctrie_getroot(ptree);
if (node == 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"


Re: svn commit: r346120 - head/sys/kern

2019-04-11 Thread Conrad Meyer
Hi Edward,

I have a question about this change below.

On Thu, Apr 11, 2019 at 4:22 AM Edward Tomasz Napierala
 wrote:
>
> Author: trasz
> Date: Thu Apr 11 11:21:45 2019
> New Revision: 346120
> URL: https://svnweb.freebsd.org/changeset/base/346120
>
> Log:
>   Use shared vnode locks for the ELF interpreter.
>
> ...
>   Differential Revision:https://reviews.freebsd.org/D19874
> ...
> Modified: head/sys/kern/imgact_elf.c
> ==
> --- head/sys/kern/imgact_elf.c  Thu Apr 11 08:06:45 2019(r346119)
> +++ head/sys/kern/imgact_elf.c  Thu Apr 11 11:21:45 2019(r346120)
> ...
> -   NDINIT(nd, LOOKUP, LOCKLEAF | FOLLOW, UIO_SYSSPACE, file, curthread);
> +   flags = FOLLOW | LOCKSHARED | LOCKLEAF;
> +
> +again:
> +   NDINIT(nd, LOOKUP, flags, UIO_SYSSPACE, file, curthread);
> if ((error = namei(nd)) != 0) {
> ...
> @@ -759,15 +762,30 @@ __elfN(load_file)(struct proc *p, const char *file, u_
> ...
> +   if (VOP_IS_TEXT(nd->ni_vp) == 0) {
> +   if (VOP_ISLOCKED(nd->ni_vp) != LK_EXCLUSIVE) {
> +   /*
> +* LK_UPGRADE could have resulted in dropping
> +* the lock.  Just try again from the start,
> +* this time with exclusive vnode lock.
> +*/
> +   vput(nd->ni_vp);
> +   flags &= ~LOCKSHARED;
> +   goto again;

It's unclear to me why we don't attempt LK_UPGRADE first.  If upgrade
succeeds, we avoid an extra filesystem traversal (namei/lookup).  If
it fails, of course we can 'goto again' the same as we do
unconditionally here.

There was some discussion about the topic in the linked phabricator PR
with Konstantin, but I did not follow it fully.

On the one hand, perhaps VOP_IS_TEXT() is rarely false for common
interpreters anyway.  On the other hand, there is sort of a
renaissance of static linking happening.  So maybe the thought is,
!VOP_IS_TEXT is likely to be rare, and LK_UPGRADE success even more
rare, so why bother writing additional code for it?

Thanks,
Conrad

P.S., It is orthogonal to this discussion, but I don't see any reason
for VOP_IS_TEXT to be a vnode_if operation.  Neither it, nor
VOP_UNSET_TEXT, is ever specialized.  They simply check or clear the
VV_TEXT flag on the vnode's vflags, respectively.  It is common for
the kernel to reach out and interact with other vnode vflags directly;
e.g., pretty much all other VV_flags, like VV_ROOT.  The only
specialization of VOP_SET_TEXT is NFSclient, and it is unclear to me
why the same requirements NFS client has for setting VV_TEXT do not
apply universally.
___
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: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

2019-04-15 Thread Conrad Meyer
Author: cem
Date: Mon Apr 15 18:40:36 2019
New Revision: 346250
URL: https://svnweb.freebsd.org/changeset/base/346250

Log:
  random(4): Block read_random(9) on initial seeding
  
  read_random() is/was used, mostly without error checking, in a lot of
  very sensitive places in the kernel -- including seeding the widely used
  arc4random(9).
  
  Most uses, especially arc4random(9), should block until the device is seeded
  rather than proceeding with a bogus or empty seed.  I did not spy any
  obvious kernel consumers where blocking would be inappropriate (in the
  sense that lack of entropy would be ok -- I did not investigate locking
  angle thoroughly).  In many instances, arc4random_buf(9) or that family
  of APIs would be more appropriate anyway; that work was done in r345865.
  
  A minor cleanup was made to the implementation of the READ_RANDOM function:
  instead of using a variable-length array on the stack to temporarily store
  all full random blocks sufficient to satisfy the requested 'len', only store
  a single block on the stack.  This has some benefit in terms of reducing
  stack usage, reducing memcpy overhead and reducing devrandom output leakage
  via the stack.  Additionally, the stack block is now safely zeroed if it was
  used.
  
  One caveat of this change is that the kern.arandom sysctl no longer returns
  zero bytes immediately if the random device is not seeded.  This means that
  FreeBSD-specific userspace applications which attempted to handle an
  unseeded random device may be broken by this change.  If such behavior is
  needed, it can be replaced by the more portable getrandom(2) GRND_NONBLOCK
  option.
  
  On any typical FreeBSD system, entropy is persisted on read/write media and
  used to seed the random device very early in boot, and blocking is never a
  problem.
  
  This change primarily impacts the behavior of /dev/random on embedded
  systems with read-only media that do not configure "nodevice random".  We
  toggle the default from 'charge on blindly with no entropy' to 'block
  indefinitely.'  This default is safer, but may cause frustration.  Embedded
  system designers using FreeBSD have several options.  The most obvious is to
  plan to have a small writable NVRAM or NAND to persist entropy, like larger
  systems.  Early entropy can be fed from any loader, or by writing directly
  to /dev/random during boot.  Some embedded SoCs now provide a fast hardware
  entropy source; this would also work for quickly seeding Fortuna.  A 3rd
  option would be creating an embedded-specific, more simplistic random
  module, like that designed by DJB in [1] (this design still requires a small
  rewritable media for forward secrecy).  Finally, the least preferred option
  might be "nodevice random", although I plan to remove this in a subsequent
  revision.
  
  To help developers emulate the behavior of these embedded systems on
  ordinary workstations, the tunable kern.random.block_seeded_status was
  added.  When set to 1, it blocks the random device.
  
  I attempted to document this change in random.4 and random.9 and ran into a
  bunch of out-of-date or irrelevant or inaccurate content and ended up
  rototilling those documents more than I intended to.  Sorry.  I think
  they're in a better state now.
  
  PR:   230875
  Reviewed by:  delphij, markm (earlier version)
  Approved by:  secteam(delphij), devrandom(markm)
  Relnotes: yes
  Differential Revision:https://reviews.freebsd.org/D19744

Modified:
  head/share/man/man4/random.4
  head/share/man/man9/random.9
  head/sys/dev/random/fortuna.c
  head/sys/dev/random/random_harvestq.c
  head/sys/dev/random/random_infra.c
  head/sys/dev/random/randomdev.c
  head/sys/dev/random/randomdev.h
  head/sys/kern/kern_mib.c
  head/sys/libkern/arc4random.c
  head/sys/sys/random.h

Modified: head/share/man/man4/random.4
==
--- head/share/man/man4/random.4Mon Apr 15 17:54:40 2019
(r346249)
+++ head/share/man/man4/random.4Mon Apr 15 18:40:36 2019
(r346250)
@@ -23,7 +23,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd August 26, 2018
+.Dd April 15, 2019
 .Dt RANDOM 4
 .Os
 .Sh NAME
@@ -32,63 +32,44 @@
 .Sh SYNOPSIS
 .Cd "device random"
 .Cd "options RANDOM_LOADABLE"
+.Cd "options RANDOM_ENABLE_ETHER"
 .Cd "options RANDOM_ENABLE_UMA"
 .Sh DESCRIPTION
 The
 .Nm
-device
-returns an endless supply of random bytes when read.
-It also accepts and reads data
-as any ordinary file.
+device returns an endless supply of random bytes when read.
 .Pp
 The generator will start in an
 .Em unseeded
-state, and will block reads until
-it is seeded for the first time.
-This may cause trouble at system boot
-when keys and the like
-are generated from
-.Nm
-so steps should be taken to ensure a
-seeding as soon as possible.
+state, and will block reads until it is seeded for the first time.
 .Pp
-It is also possible
-to read random bytes
-by 

svn commit: r346251 - head/lib/libc/stdlib

2019-04-15 Thread Conrad Meyer
Author: cem
Date: Mon Apr 15 18:49:04 2019
New Revision: 346251
URL: https://svnweb.freebsd.org/changeset/base/346251

Log:
  random.3: Clarify confusing summary
  
  random.3 is only "better" in contrast to rand.3.  Both are non-cryptographic
  pseudo-random number generators.  The opening blurbs of each's DESCRIPTION
  section does emphasize this, and correctly directs unfamiliar developers to
  arc4random(3).  However, the summary (".Nd" or Name description) of random.3
  conflicted in tone and message with that warning.
  
  Resolve the conflict by clarifying in the Nd section that random(3) is
  non-cryptographic and pseudo-random.  Elide the "better" qualifier which
  implied a comparison but did not provide a specific object to contrast.
  
  Sponsored by: Dell EMC Isilon

Modified:
  head/lib/libc/stdlib/random.3

Modified: head/lib/libc/stdlib/random.3
==
--- head/lib/libc/stdlib/random.3   Mon Apr 15 18:40:36 2019
(r346250)
+++ head/lib/libc/stdlib/random.3   Mon Apr 15 18:49:04 2019
(r346251)
@@ -28,7 +28,7 @@
 .\" @(#)random.3   8.1 (Berkeley) 6/4/93
 .\" $FreeBSD$
 .\"
-.Dd July 26, 2016
+.Dd April 15, 2019
 .Dt RANDOM 3
 .Os
 .Sh NAME
@@ -37,7 +37,7 @@
 .Nm srandomdev ,
 .Nm initstate ,
 .Nm setstate
-.Nd better random number generator; routines for changing generators
+.Nd non-cryptographic pseudorandom number generator; routines for changing 
generators
 .Sh LIBRARY
 .Lb libc
 .Sh SYNOPSIS
___
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: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

2019-04-15 Thread Conrad Meyer
On Mon, Apr 15, 2019 at 5:53 PM Conrad Meyer  wrote:
> E.g., the CI infrastructure for
> Riscv/Arm is/was generating minimal filesystem images and not
> populating /boot/entropy.

I should add, I say "is/was" because I have a PR out which may address
the problem: https://github.com/freebsd/freebsd-ci/pull/31

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"


Re: svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

2019-04-15 Thread Conrad Meyer
Hi Justin,

On Mon, Apr 15, 2019 at 5:01 PM Justin Hibbits  wrote:
> Given the discussion over there it would probably also fail on powernv, which 
> also does not use loader.

Does power use bsdinstall (which populates /boot/entropy at install
time via usr.sbin/bsdinstall/scripts/entropy) and install the
libexec/rc/rc.d/random rc script (which re-emits new /boot/entropy on
every startup)?  If so, it should be ok.

The problem is new installs that don't use bsdinstall or otherwise
provide initial /boot/entropy.  E.g., the CI infrastructure for
Riscv/Arm is/was generating minimal filesystem images and not
populating /boot/entropy.

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"


Re: svn commit: r346259 - head/sys/dev/tpm

2019-04-16 Thread Conrad Meyer
Hi Marcin,

Isn't this check racy?  Thread TIDs are allocated from a fixed range
and can be recycled.

Best,
Conrad

On Mon, Apr 15, 2019 at 7:28 PM Marcin Wojtas  wrote:
>
> Author: mw
> Date: Tue Apr 16 02:28:35 2019
> New Revision: 346259
> URL: https://svnweb.freebsd.org/changeset/base/346259
>
> Log:
>   tpm: Prevent session hijack
>
>   Check caller thread id before allowing to read the buffer
>   to make sure that it can only be accessed by the thread that
>   did the associated write to the TPM.
>
>   Submitted by: Kornel Duleba 
>   Reviewed by: delphij
>   Obtained from: Semihalf
>   Sponsored by: Stormshield
>   Differential Revision: https://reviews.freebsd.org/D19713
>
> Modified:
>   head/sys/dev/tpm/tpm20.c
>   head/sys/dev/tpm/tpm20.h
>
> Modified: head/sys/dev/tpm/tpm20.c
> ==
> --- head/sys/dev/tpm/tpm20.cTue Apr 16 02:12:38 2019(r346258)
> +++ head/sys/dev/tpm/tpm20.cTue Apr 16 02:28:35 2019(r346259)
> @@ -77,6 +77,10 @@ tpm20_read(struct cdev *dev, struct uio *uio, int flag
>
> callout_stop(>discard_buffer_callout);
> sx_xlock(>dev_lock);
> +   if (sc->owner_tid != uio->uio_td->td_tid) {
> +   sx_xunlock(>dev_lock);
> +   return (EPERM);
> +   }
>
> bytes_to_transfer = MIN(sc->pending_data_length, uio->uio_resid);
> if (bytes_to_transfer > 0) {
> @@ -128,9 +132,11 @@ tpm20_write(struct cdev *dev, struct uio *uio, int fla
>
> result = sc->transmit(sc, byte_count);
>
> -   if (result == 0)
> +   if (result == 0) {
> callout_reset(>discard_buffer_callout,
> TPM_READ_TIMEOUT / tick, tpm20_discard_buffer, sc);
> +   sc->owner_tid = uio->uio_td->td_tid;
> +   }
>
> sx_xunlock(>dev_lock);
> return (result);
>
> Modified: head/sys/dev/tpm/tpm20.h
> ==
> --- head/sys/dev/tpm/tpm20.hTue Apr 16 02:12:38 2019(r346258)
> +++ head/sys/dev/tpm/tpm20.hTue Apr 16 02:28:35 2019(r346259)
> @@ -120,6 +120,7 @@ struct tpm_sc {
>
> uint8_t *buf;
> size_t  pending_data_length;
> +   lwpid_t owner_tid;
>
> struct callout  discard_buffer_callout;
>  #ifdef TPM_HARVEST
>
___
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: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

2019-04-16 Thread Conrad Meyer
On Tue, Apr 16, 2019 at 6:19 AM Warner Losh  wrote:
> On Tue, Apr 16, 2019, 7:04 AM Emmanuel Vadot  wrote:
>>  It's not only CI, all release images (memstick, iso) don't have
>> a /boot/entropy.
>>  Also all arm/arm64 image don't have this file too.
>>  If /boot/entropy is needed and isn't present loader(8) should gather
>> some entropy and pass this to the kernel for the first boot.
>
> Maybe we need to bootstrap the entropy file as part of buildworld. I'm not 
> sure if the loader can find enough...

Well, one thing we should explicitly *not do* is distribute the same
"entropy" to everyone in released images.  So there is some difficulty
here.  Buildworld does not know if the target of the build is a
one-off or a release image.  Something like makerelease still seems
inappropriately dangerous.

The idea of loader-provided entropy is not that it generates the
entropy itself, but that it can access the /boot/ filesystem to load
entropy and pass it to the kernel as a fake module.

I think we have identified that at least stack_chk_init was silently
broken on a number of systems, using non-random stack guards.  Now
it's loudly broken.  Ed has proposed a happy medium where we can
check, in stack_chk_init, if the random device is seeded (via new KPI)
and give users a big stick tunable to proceed without entropy or not.
For now, I think we would default that to "proceed" just to unbreak CI
and any other sharp corners.  But the goal would be to default that to
"panic" eventually.

I don't know enough about stack_chk_init to determine how late it can
be seeded.  It seems to have come in in r180012 as a component of
-fstack-protector.  I will do a little investigating.  Suggestions on
appropriate reviewers welcome (I think ru@ is no longer with the
project).

Best regards,
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: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

2019-04-16 Thread Conrad Meyer
On Tue, Apr 16, 2019 at 7:24 AM Justin Hibbits  wrote:
>
> Hi Conrad,
> ...
> [Power] does use bsdinstall to install.  How is entropy loaded at startup,
> which causes the problem noted in github?

There are a couple very early load sources.  loader(8) will load
early-boot entropy from /boot/entropy and pass it to the kernel as a
fake module (entropy_cache_load in loader.conf(5)), similar to
cpu_microcode early load.

The fallback option is random(4) itself groping into the filesystem
during early auto-conf (SI_SUB_RANDOM:SI_ORDER_FOURTH, IIRC) to access
/boot/entropy directly.

> If it's loaded before
> filesystems get mounted, that could be a problem for us, because /boot
> is on a different filesystem (msdosfs, to be read by petitboot).
> Petitboot also does not have a way to preload modules, so all we have
> at startup, until spawning init, is the kernel.

Yes, that seems potentially problematic.  Can the Power kernel access
the non-msdosfs root filesystem?  Let's follow-up offline about
PPC-specific early entropy seeding.  I would much prefer we figure out
a way to provide early entropy to Power than disabling or crippling
every early random consumer on the arch.  Do you know what the Linux
folks do?

On Power with darn, we could probably just spin in SI_ORDER_FOURTH
until we have enough darn output to seed random.  Similar for x86 CI
images, I guess; though they do not have the loader problem, some
people have non-bsdinstall installation methods.

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: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

2019-04-16 Thread Conrad Meyer
On Tue, Apr 16, 2019 at 9:33 AM Warner Losh  wrote:
> In that case, we're better off having a MD routine that gets called if 
> there's no loader-provided entropy pool.

Yes, this is more or less the same plan I had.  There's no need to add
anything MD specific; we already abstract MD random sources behind the
harvest mechanism.

> (and requiring an NV store is not even an option to require, so don't go 
> there).

Systems lacking both an NV store and an entropy source available
during mi_startup (i.e., not interrupts...) cannot safely provide
entropy in early boot.  On those systems, we must disable random
consumption during early boot.

> What we can't do is just hang if the loader can't provide an entropy pool.

I think we're all on the same page there.

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"


Re: svn commit: r346263 - head/contrib/tcpdump

2019-04-16 Thread Conrad Meyer
On Tue, Apr 16, 2019 at 6:20 AM Shawn Webb  wrote:
> Is there any documentation anywhere telling users that Capsicum
> support will be disabled under certain circumstances?

Hi Shawn,

I don't think documenting that makes much sense in general.  It would
be extremely burdensome to fully document and quickly become
desynchronized from the code.  It's comparable to OpenBSD pledging
differently in different paths of programs.

To me, "for now," suggests that this is perhaps a temporary workaround
and maybe we can do something better in the future.

Take care,
Conrad

P.S., When do you plan to update your Easy Feature Comparison page to
reflect that FreeBSD has the same procfs and "boot hardening" as HBSD?
___
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: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

2019-04-16 Thread Conrad Meyer
Hi Ruslan,

On Tue, Apr 16, 2019 at 8:38 AM Ruslan Bukin  wrote:
>
> Hi I just got this:
>
> ...
> _sleep() at random_harvest_deregister_source+0x132
> random_harvest_deregister_source() at read_random+0xc4
> read_random() at vn_fsync_buf+0x594
> vn_fsync_buf() at arc4rand+0xd4
> arc4rand() at sched_tdname+0x4c
> sched_tdname() at mi_startup+0x20c
> mi_startup() at 0xffc001a6
> KDB: enter: panic


The stack is clearly bogus or missing some frames; can you attach GDB
on this system (or an emulator) and get a full stack?  The step(s) I'm
missing are mi_startup -> sched_tdname, and sched_tdname ->
arc4rand().  What's consuming random during early boot on riscv?

(The vn_fsync_buf frame is also confusing and probably incorrect?  A
real stack would be helpful.)  Maybe it's just __stack_chk_init, given
mi_startup, like the other reproductions.  I will need to take a step
back from email to address that.)

> We don't have loader(8) support for RISC-V and we don't have any hardware 
> with random number generators yet. Most of our fpga/hardware has no way to 
> have rootfs at all (we use mdroot).

Is it possible to inject entropy into the mdroot?  If not, it seems
like anything that consumes random during early boot on riscv must be
disabled.

> We use BBL bootloader to boot freebsd. BBL embeds freebsd kernel to the BBL 
> binary on a compile time (similar way how we embed mdroot to kernel). Once 
> BBL initialized itself it jumps to the pre-defined address of payload which 
> is freebsd kernel.
>
> So I'm pondering what is our current option, i.e. how to feed entropy in this 
> case ?

Can a running system rebuild the mdroot or BBL?  Or do they reside on
RO flash of some kind?  If so, it would be possible to rewrite the BBL
or mdroot with entropy injected for the next boot, I think.

Otherwise, the straightforward solution is to simply disable anything
that attempts to consume random early in boot on such devices with no
hardware entropy source and no early filesystem access.

Anything that is tripping on this was silently feeding itself with
predictable, non-random data prior to this change.

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: r346282 - in head: . share/man/man9 sys/dev/random sys/sys

2019-04-16 Thread Conrad Meyer
Author: cem
Date: Tue Apr 16 17:12:17 2019
New Revision: 346282
URL: https://svnweb.freebsd.org/changeset/base/346282

Log:
  random(4): Add is_random_seeded(9) KPI
  
  The imagined use is for early boot consumers of random to be able to make
  decisions based on whether random is available yet or not.  One such
  consumer seems to be __stack_chk_init(), which runs immediately after random
  is initialized.  A follow-up patch will attempt to address that.
  
  Reported by:  many
  Reviewed by:  delphij (except man page)
  Approved by:  secteam(delphij)
  Differential Revision:https://reviews.freebsd.org/D19926

Modified:
  head/UPDATING
  head/share/man/man9/Makefile
  head/share/man/man9/random.9
  head/sys/dev/random/random_infra.c
  head/sys/dev/random/randomdev.c
  head/sys/dev/random/randomdev.h
  head/sys/sys/param.h
  head/sys/sys/random.h

Modified: head/UPDATING
==
--- head/UPDATING   Tue Apr 16 16:49:34 2019(r346281)
+++ head/UPDATING   Tue Apr 16 17:12:17 2019(r346282)
@@ -31,6 +31,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
disable the most expensive debugging functionality run
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
 
+20190416:
+   The loadable random module KPI has changed; the random_infra_init()
+   routine now requires a 3rd function pointer for a bool (*)(void)
+   method that returns true if the random device is seeded (and
+   therefore unblocked).
+
 20190404:
r345895 reverts r320698. This implies that an nfsuserd(8) daemon
built from head sources between r320757 (July 6, 2017) and

Modified: head/share/man/man9/Makefile
==
--- head/share/man/man9/MakefileTue Apr 16 16:49:34 2019
(r346281)
+++ head/share/man/man9/MakefileTue Apr 16 17:12:17 2019
(r346282)
@@ -1668,6 +1668,7 @@ MLINKS+=psignal.9 gsignal.9 \
psignal.9 tdsignal.9
 MLINKS+=random.9 arc4rand.9 \
random.9 arc4random.9 \
+   random.9 is_random_seeded.9 \
random.9 read_random.9 \
random.9 read_random_uio.9 \
random.9 srandom.9

Modified: head/share/man/man9/random.9
==
--- head/share/man/man9/random.9Tue Apr 16 16:49:34 2019
(r346281)
+++ head/share/man/man9/random.9Tue Apr 16 17:12:17 2019
(r346282)
@@ -26,13 +26,14 @@
 .\"
 .\" $FreeBSD$
 .\" "
-.Dd April 15, 2019
+.Dd April 16, 2019
 .Dt RANDOM 9
 .Os
 .Sh NAME
 .Nm arc4rand ,
 .Nm arc4random ,
 .Nm arc4random_buf ,
+.Nm is_random_seeded ,
 .Nm random ,
 .Nm read_random ,
 .Nm read_random_uio ,
@@ -48,6 +49,8 @@
 .Fn arc4rand "void *ptr" "u_int length" "int reseed"
 .Pp
 .In sys/random.h
+.Ft bool
+.Fn is_random_seeded "void"
 .Ft void
 .Fn read_random "void *buffer" "int count"
 .Ft int
@@ -106,6 +109,13 @@ is not used directly;
 instead, use the
 .Fn arc4rand
 family of functions.
+.Pp
+The
+.Fn is_random_seeded
+function can be used to check in advance if
+.Fn read_random
+will block.
+(If random is seeded, it will not block.)
 .Pp
 The
 .Fn read_random_uio

Modified: head/sys/dev/random/random_infra.c
==
--- head/sys/dev/random/random_infra.c  Tue Apr 16 16:49:34 2019
(r346281)
+++ head/sys/dev/random/random_infra.c  Tue Apr 16 17:12:17 2019
(r346282)
@@ -63,12 +63,20 @@ null_read_random(void *dummy __unused, u_int dummy2 __
panic("%s: no random module is loaded", __func__);
 }
 
+static bool
+null_is_random_seeded(void)
+{
+   return (false);
+}
+
 struct random_readers {
int (*read_random_uio)(struct uio *, bool);
void(*read_random)(void *, u_int);
+   bool(*is_random_seeded)(void);
 } random_reader_context = {
(int (*)(struct uio *, bool))nullop,
null_read_random,
+   null_is_random_seeded,
 };
 
 struct sx randomdev_config_lock;
@@ -82,12 +90,15 @@ random_infra_sysinit(void *dummy __unused)
 SYSINIT(random_device_h_init, SI_SUB_RANDOM, SI_ORDER_FIRST, 
random_infra_sysinit, NULL);
 
 void
-random_infra_init(int (*p_random_read_uio)(struct uio *, bool), void 
(*p_random_read)(void *, u_int))
+random_infra_init(int (*p_random_read_uio)(struct uio *, bool),
+void (*p_random_read)(void *, u_int),
+bool (*p_is_random_seeded)(void))
 {
 
RANDOM_CONFIG_X_LOCK();
random_reader_context.read_random_uio = p_random_read_uio;
random_reader_context.read_random = p_random_read;
+   random_reader_context.is_random_seeded = p_is_random_seeded;
RANDOM_CONFIG_X_UNLOCK();
 }
 
@@ -98,6 +109,7 @@ random_infra_uninit(void)
RANDOM_CONFIG_X_LOCK();
random_reader_context.read_random_uio = (int (*)(struct uio *, 
bool))nullop;

svn commit: r346292 - in head: . sys/kern

2019-04-16 Thread Conrad Meyer
Author: cem
Date: Tue Apr 16 18:47:20 2019
New Revision: 346292
URL: https://svnweb.freebsd.org/changeset/base/346292

Log:
  stack_protector: Add tunable to bypass random cookies
  
  This is a stopgap measure to unbreak installer/VM/embedded boot issues
  introduced (or at least exposed by) in r346250.
  
  Add the new tunable, "security.stack_protect.permit_nonrandom_cookies," in
  order to continue boot with insecure non-random stack cookies if the random
  device is unavailable.
  
  For now, enable it by default.  This is NOT safe.  It will be disabled by
  default in a future revision.
  
  There is follow-on work planned to use fast random sources (e.g., RDRAND on
  x86 and DARN on Power) to seed when the early entropy file cannot be
  provided, for whatever reason.  Please see D19928.
  
  Some better hacks may be used to make the non-random __stack_chk_guard
  slightly less predictable (from delphij@ and mjg@); those suggestions are
  left for a future revision.  I think it may also be plausible to move stack
  guard initialization far later in the boot process; potentially it could be
  moved all the way to just before userspace is started.
  
  Reported by:  many
  Reviewed by:  delphij, emaste, imp (all w/ caveat: this is a stopgap fix)
  Security: yes
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D19927

Modified:
  head/UPDATING
  head/sys/kern/stack_protector.c

Modified: head/UPDATING
==
--- head/UPDATING   Tue Apr 16 18:32:07 2019(r346291)
+++ head/UPDATING   Tue Apr 16 18:47:20 2019(r346292)
@@ -32,6 +32,13 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
 
 20190416:
+   The tunable "security.stack_protect.permit_nonrandom_cookies" may be
+   set to a non-zero value to boot systems that do not provide early
+   entropy.  Otherwise, such systems may see the panic message:
+   "cannot initialize stack cookies because random device is not yet
+   seeded."
+
+20190416:
The loadable random module KPI has changed; the random_infra_init()
routine now requires a 3rd function pointer for a bool (*)(void)
method that returns true if the random device is seeded (and

Modified: head/sys/kern/stack_protector.c
==
--- head/sys/kern/stack_protector.c Tue Apr 16 18:32:07 2019
(r346291)
+++ head/sys/kern/stack_protector.c Tue Apr 16 18:47:20 2019
(r346292)
@@ -4,12 +4,28 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
 long __stack_chk_guard[8] = {};
 void __stack_chk_fail(void);
 
+/*
+ * XXX This default is unsafe!!!  We intend to change it after resolving issues
+ * with early entropy in the installer; some kinds of systems that do not use
+ * loader(8), such as riscv, aarch64, and power; and perhaps others that I am
+ * forgetting off the top of my head.
+ */
+static bool permit_nonrandom_cookies = true;
+
+SYSCTL_NODE(_security, OID_AUTO, stack_protect, CTLFLAG_RW, 0,
+"-fstack-protect support");
+SYSCTL_BOOL(_security_stack_protect, OID_AUTO, permit_nonrandom_cookies,
+CTLFLAG_RDTUN, _nonrandom_cookies, 0,
+"Allow stack guard to be used without real random cookies");
+
 void
 __stack_chk_fail(void)
 {
@@ -23,8 +39,37 @@ __stack_chk_init(void *dummy __unused)
size_t i;
long guard[nitems(__stack_chk_guard)];
 
-   arc4rand(guard, sizeof(guard), 0);
-   for (i = 0; i < nitems(guard); i++)
-   __stack_chk_guard[i] = guard[i];
+   if (is_random_seeded()) {
+   arc4rand(guard, sizeof(guard), 0);
+   for (i = 0; i < nitems(guard); i++)
+   __stack_chk_guard[i] = guard[i];
+   return;
+   }
+
+   if (permit_nonrandom_cookies) {
+   printf("%s: WARNING: Initializing stack protection with "
+   "non-random cookies!\n", __func__);
+   printf("%s: WARNING: This severely limits the benefit of "
+   "-fstack-protector!\n", __func__);
+
+   /*
+* The emperor is naked, but I rolled some dice and at least
+* these values aren't zero.
+*/
+   __stack_chk_guard[0] = (long)0xe7318d5959af899full;
+   __stack_chk_guard[1] = (long)0x35a9481c089348bfull;
+   __stack_chk_guard[2] = (long)0xde657fdc04117255ull;
+   __stack_chk_guard[3] = (long)0x0dd44c61c22e4a6bull;
+   __stack_chk_guard[4] = (long)0x0a5869a354edb0a5ull;
+   __stack_chk_guard[5] = (long)0x05cebfed255b5232ull;
+   __stack_chk_guard[6] = (long)0x270ffac137c4c72full;
+   __stack_chk_guard[7] = (long)0xd8141a789bad478dull;
+ 

Re: svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

2019-04-16 Thread Conrad Meyer
Hi Warner,

On Tue, Apr 16, 2019 at 8:47 AM Warner Losh  wrote:
> On Tue, Apr 16, 2019 at 9:16 AM Ian Lepore  wrote:
>> Isn't a file full of data which is distributed in identical form to
>> everyone the exact opposite of entropy?

Ian has the right idea.

> It's just to bootstrap entropy for installs. The CI stuff doesn't matter if 
> that's the same since the CI images aren't exposed to the internet in any way 
> that would make it matter. The normal install would have the same seeds of 
> entropy, but diverge from there fairly quickly. The stuff that's used early 
> in the install is the don't care sort of things that won't matter in the 
> installer (which then creates it's own entropy that's different for every 
> install).

I agree that it would be safe, although potentially misleading and
potentially dangerous, to create a fake entropy file for the installer
images.  We need to be careful *not* to embed such files in .img files
which are installed by 'dd' directly to a disk or flash or VM, for
example.  It would be catastrophic to distribute the same entropy file
to all FreeBSD AWS images.

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"


Re: svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

2019-04-17 Thread Conrad Meyer
On Mon, Apr 15, 2019 at 11:40 AM Conrad Meyer  wrote:
>
> Author: cem
> Date: Mon Apr 15 18:40:36 2019
> New Revision: 346250
> URL: https://svnweb.freebsd.org/changeset/base/346250
>
> Log:
>   random(4): Block read_random(9) on initial seeding

Hi,

For anyone interested in a change to restore the previous behavior
(optionally, but on by default for now), please see
https://reviews.freebsd.org/D19944 .

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: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

2019-04-17 Thread Conrad Meyer
Hey Adrian,

As discussed with John and Warner upthread, I hope to have a patch out
for review later today to give folks a knob to disable this.  It may
even make sense to default it on, at least for !x86.  I am happy to CC
you on review if you like.

Take care,
Conrad

On Wed, Apr 17, 2019 at 11:22 AM Adrian Chadd  wrote:
>
>
>
> On Mon, 15 Apr 2019 at 11:40, Conrad Meyer  wrote:
>>
>> Author: cem
>> Date: Mon Apr 15 18:40:36 2019
>> New Revision: 346250
>> URL: https://svnweb.freebsd.org/changeset/base/346250
>>
>> Log:
>>   random(4): Block read_random(9) on initial seeding
>
>
> Sniffle, this broke on my mips boards whilst debugging why I'm seeing 
> transmit crashes and other bad behaviours. if_arge has some hacks to randomly 
> allocate mac addresses if the board doesn't supply them. This is going to be 
> a common thing to deal with during board bring-up before you do things like, 
> I dunno, make storage work. I'm going to fix if_arge to use the new API to 
> generate MAC addresses but there'll be other places where this will bite you.
>
> Please reconsider this a bit. I know people are trying to improve our 
> security and cryptography support. But some of us are trying to use FreeBSD 
> code in fun places and maybe occasionally do some more porting work. :-)
>
>
> -adrian
>
>
___
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: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

2019-04-17 Thread Conrad Meyer
Hi Warner,

On Wed, Apr 17, 2019 at 10:16 AM Warner Losh  wrote:
> I'm going to put a very fine point on this: any hard-requirement of entropy 
> sources is a non-starter. If you require that, your commit will be backed out 
> and/or hacked around by the addition of a nob in the future. It will happen. 
> Don't pretend you can say 'but things weren't random enough' will carry the 
> day. It will not.
>
> That's why I specifically requested a MD routine to be called when there's no 
> source of entropy: that will let special needs folks do the right thing. It's 
> also why I asked for a way to say "don't ever block waiting for entropy, 
> soldier on the best you can, but set some variable that can be exposed to 
> userland so that early in /etc/rc automation can be written to decide what to 
> do when that condition exists: generate entropy and reboot, report it to some 
> central control, nothing" since that will give the tools for different 
> reactions.
>
> For our application it is *NEVER* OK to block the boot because there's not 
> enough randomness. We'd rather solider on with crappy randomness and want the 
> boot to proceed not matter what. We want the information that we had to make 
> compromises along the way to make it happen so we can decide the right course 
> of action for our appliances.

I think John's proposed big knob to disable hard-requirement of
entropy, and a warning on dmesg, pretty much covers your applications'
needs.  Do you agree?

The random framework has already got ways to register random sources;
special needs MD folks can always register their own fako fast random
source.  I.e., the randomdev entropy intake framework is already
general with room for MD-specific drivers (of which several exist
today).

Take care,
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: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

2019-04-17 Thread Conrad Meyer
Hi John,

On Wed, Apr 17, 2019 at 9:01 AM John Baldwin  wrote:
> You're missing the point which is that you've added potential blocking in a 
> lot of
> places by changing the semantics of arc4random.

I get it.  The thing is, it's a weird blocking semantic.  It's not the
same as any other blocking semantic we have elsewhere in the kernel.
It can't happen in any particular call.  Once it unblocks, it's
nonblocking forever after.  So if the caller a priori knows that
random is seeded, it's not a blocking operation.

> Unless you're intending to
> hand-audit all of them (as well as future uses), I think having the existing
> API be "safe" (and blocking) but use WITNESS_WARN is a way to catch existing
> and future locking problems.

This would essentially just force auditing, no?  I guess it helps
highlight instances that are (a) actually inside a locked region and
(b) run by users.  I'm on board with this approach.  My only concern
is that we will have false positives (and continue to have false
positives after true positives are made safe).  One thing we could do
is teach WITNESS about random's seeded/not status.

Let's take away: I'll owe you a differential implementing some version
of this proposal, as well as a separate one for the giant
unsafe-random knob, and we can discuss the technical details offline.
Expect something today, if at all possible.

> The EWOULDBLOCK API is something a developer
> would choose and it means they would be aware of the constraint and need to
> deal with it, either by handling EWOULDBLOCK in some way, or deferring use
> until seeded, etc.

Ok; if it is attached to a specific need, and it has
'__attribute__((warn_unused_result))' attached to it, I'm tentatively
ok with the idea.  I don't want to add additional interfaces that
don't get used, or make it easy to accidentally get non-results.

Best regards,
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: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

2019-04-16 Thread Conrad Meyer
On Tue, Apr 16, 2019 at 4:31 PM John Baldwin  wrote:
> bhyveload is effectively the loader in this case.  It runs the normal loader
> scripts and logic and so would load the guests's /boot/entropy and pass it
> to the guest kernel as metadata just like the regular loader.

Right, except it doesn't seem to do things like nuke /boot/nextboot.conf :-(.

> In addition, bhyve also supports virtio-rng which is another way to provide
> entropy to guest OS's.  That's why in my reply I focused on qemu for mips
> (or riscv) as for x86 hypervisors there are existing, somewhat-standarized
> solutions for the hypervisor to provide entropy to the guest.

Perhaps cryptographically random stack-protector cookies are simply
inappropriate for MIPS or RISCV.  Do we have any other examples of
kernel random consumers blocking after that immediate hiccup is
overcome?

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"


Re: svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

2019-04-16 Thread Conrad Meyer
On Tue, Apr 16, 2019 at 4:28 PM John Baldwin  wrote:
> Yes, but we need some kind of non-blocking API, not an 
> unconditionally-blocking API
> that deadlocks.

I'm not sure we do.  It would be sufficient to check once at subsystem
initialization time.  There's no race condition such that we block
again once we're seeded.

As far as APIs go, read_random_uio is nonblocking, although not an
arc4random interface (and quite cumbersome to set up and use).

> Eh, I thought that we periodically pulled in new entropy to generate a new 
> chacha20
> key for the PRNG and that could be blocking as well when I was last reading 
> this
> code, or is that not correct?

No, that's incorrect.  We periodically pull new Fortuna (devrandom)
output to reseed chacha20 in arc4random, but once Fortuna is "seeded,"
it *never* blocks ever again.

> Or maybe arc4random passes in a flag to disable
> reseeding so it isn't blocking once the PRNG has been seeded at least once?

As above, *re*seeding arc4random never blocks.

> Still, what I would suggest is to have the existing arc4random() use 
> WITNESS_WARN.
> We could provide an alternative API that is non-blocking and returns 
> EWOULDBLOCK.

I think the alternative EWOULDBLOCK proposal is worse than
WITNESS_WARN.  But I highlighted some problems with WITNESS_WARN in my
earlier email; how would you resolve them?

> Code that trips over the warning would have to be changed to use the 
> non-blocking
> API and then deal with EWOULDBLOCK.

Or it could just check that the random device is seeded, prior to
using arc4random?

> One way of dealing with that would be to
> check the is_random_seeded() flag earlier in the function, subsystem, whatever
> and then the code could assert that the non-blocking API never failed.

That's more or less the status quo with no-error arc4random, no?

> There are things like virtio-rng for modern x86 VM environments, but those 
> don't
> exist on things like the MIPS MALTA machine.

They probably probe later than SI_SUB_RANDOM too :-(.

> I also don't actually care at all (as in
> absolutely zero) about the entropy of keys generated for a test qemu instance 
> I fire up
> on my desktop that doesn't permit inbound access from the outside world.  
> Having some
> kind of tunable / kernel option for those use cases (that isn't the default) 
> doesn't
> seem unreasonable.

Sure.  It would probably be ok to have a knob for that.  We would want
to be careful about naming it / documenting it; the thing about knobs
is people tend to twiddle them.

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"


Re: svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

2019-04-16 Thread Conrad Meyer
On Tue, Apr 16, 2019 at 2:32 PM John Baldwin  wrote:
> There are definitely places arc4random is used where sleeping is not allowed.

Sure.

> ipsec generating nonces for AES-CBC is one example I can think of off the
> top of my head.

IVs for AES-CBC are also a great example of a case we should be seeded for.

> I think it might be useful to add an explicit WITNESS_WARN
> in arc4random to catch these cases so they can be found and reasoned about.

Well, we kind of want that, but we also want the warning to disappear
if the consumer has correctly reasoned about it.  E.g., if the thread
has verified seeded status with is_random_seeded(), it is no longer
possible for a arc4random consumption to block.  Right?  I think that
may be difficult to integrate with the WITNESS_WARN, so even if all
consumers are correctly implemented, we will not eliminate the witness
warnings.  Do you have any ideas?  The only dumb proposal I have is
burning a flag in td_flags for "this thread checked
is_random_seeded(), and it returned true."

> Note that I actually often run into unseeded systems when doing development
> using qemu for non-x86 architectures.  For example, when booting mips from
> qemu, there is no loader, the kernel just starts, and since the endian is
> opposite, I frequently regenerate the filesystem using makefs.

Right.  Perhaps we could incorporate boot/entropy generation into
makefs?  Or pass host entropy into some kernel accessible region (env
var, whatever) via qemu?  The latter is sort of a general problem for
VMs.  You want to be able to snapshot and clone a VM without producing
reproducible RNG state, but Fortuna doesn't handle that explicitly
(aside from future entropy differences and forward secrecy causing
quick divergence).

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: r346187 - in head/usr.bin/hexdump: . tests

2019-04-13 Thread Conrad Meyer
Author: cem
Date: Sat Apr 13 16:51:48 2019
New Revision: 346187
URL: https://svnweb.freebsd.org/changeset/base/346187

Log:
  hexdump(1): Exit gracefully on format strings missing conversion
  
  PR:   237263
  Submitted by: Bojan Petrovic 

Modified:
  head/usr.bin/hexdump/hexdump.h
  head/usr.bin/hexdump/parse.c
  head/usr.bin/hexdump/tests/hexdump_test.sh

Modified: head/usr.bin/hexdump/hexdump.h
==
--- head/usr.bin/hexdump/hexdump.h  Sat Apr 13 13:59:01 2019
(r346186)
+++ head/usr.bin/hexdump/hexdump.h  Sat Apr 13 16:51:48 2019
(r346187)
@@ -88,6 +88,7 @@ void   addfile(const char *);
 voidbadcnt(const char *);
 voidbadconv(const char *);
 voidbadfmt(const char *);
+voidbadnoconv(void);
 voidbadsfmt(void);
 voidbpad(PR *);
 voidconv_c(PR *, u_char *, size_t);

Modified: head/usr.bin/hexdump/parse.c
==
--- head/usr.bin/hexdump/parse.cSat Apr 13 13:59:01 2019
(r346186)
+++ head/usr.bin/hexdump/parse.cSat Apr 13 16:51:48 2019
(r346187)
@@ -169,7 +169,10 @@ size(FS *fs)
 * skip any special chars -- save precision in
 * case it's a %s format.
 */
-   while (strchr(spec + 1, *++fmt));
+   while (*++fmt != 0 && strchr(spec + 1, *fmt) != NULL)
+   ;
+   if (*fmt == 0)
+   badnoconv();
if (*fmt == '.' && isdigit(*++fmt)) {
prec = atoi(fmt);
while (isdigit(*++fmt));
@@ -241,10 +244,16 @@ rewrite(FS *fs)
if (fu->bcnt) {
sokay = USEBCNT;
/* Skip to conversion character. */
-   for (++p1; strchr(spec, *p1); ++p1);
+   while (*++p1 != 0 && strchr(spec, *p1) != NULL)
+   ;
+   if (*p1 == 0)
+   badnoconv();
} else {
/* Skip any special chars, field width. */
-   while (strchr(spec + 1, *++p1));
+   while (*++p1 != 0 && strchr(spec + 1, *p1) != 
NULL)
+   ;
+   if (*p1 == 0)
+   badnoconv();
if (*p1 == '.' && isdigit(*++p1)) {
sokay = USEPREC;
prec = atoi(p1);
@@ -511,4 +520,10 @@ void
 badconv(const char *ch)
 {
errx(1, "%%%s: bad conversion character", ch);
+}
+
+void
+badnoconv(void)
+{
+   errx(1, "missing conversion character");
 }

Modified: head/usr.bin/hexdump/tests/hexdump_test.sh
==
--- head/usr.bin/hexdump/tests/hexdump_test.sh  Sat Apr 13 13:59:01 2019
(r346186)
+++ head/usr.bin/hexdump/tests/hexdump_test.sh  Sat Apr 13 16:51:48 2019
(r346187)
@@ -176,6 +176,19 @@ x_flag_body()
hexdump -x "$(atf_get_srcdir)/d_hexdump_c.in"
 }
 
+atf_test_case no_conv_err
+no_conv_err()
+{
+   atf_set "descr" "Verify missing conversion char error handling"
+}
+no_conv_err_body()
+{
+   atf_check -s exit:1 -e ignore \
+   hexdump -e '"%"'
+   atf_check -s exit:1 -e ignore \
+   hexdump -e '4/2 "%"'
+}
+
 atf_init_test_cases()
 {
atf_add_test_case b_flag
@@ -188,4 +201,5 @@ atf_init_test_cases()
atf_add_test_case s_flag
atf_add_test_case v_flag
atf_add_test_case x_flag
+   atf_add_test_case no_conv_err
 }
___
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: r346175 - head/usr.bin/sort

2019-04-12 Thread Conrad Meyer
Author: cem
Date: Sat Apr 13 04:42:17 2019
New Revision: 346175
URL: https://svnweb.freebsd.org/changeset/base/346175

Log:
  sort(1): Memoize MD5 computation to reduce repeated computation
  
  Experimentally, reduces sort -R time of a 148160 line corpus from about
  3.15s to about 0.93s on this particular system.
  
  There's probably room for improvement using some digest other than md5, but
  I don't want to look at sort(1) anymore.  Some discussion of other possible
  improvements in the Test Plan section of the Differential.
  
  PR:   230792
  Reviewed by:  jhb (earlier version)
  Differential Revision:https://reviews.freebsd.org/D19885

Modified:
  head/usr.bin/sort/coll.c
  head/usr.bin/sort/coll.h
  head/usr.bin/sort/sort.c

Modified: head/usr.bin/sort/coll.c
==
--- head/usr.bin/sort/coll.cSat Apr 13 04:03:18 2019(r346174)
+++ head/usr.bin/sort/coll.cSat Apr 13 04:42:17 2019(r346175)
@@ -981,6 +981,15 @@ hnumcoll(struct key_value *kv1, struct key_value *kv2,
return (numcoll_impl(kv1, kv2, offset, true));
 }
 
+/* Use hint space to memoize md5 computations, at least. */
+static void
+randomcoll_init_hint(struct key_value *kv, void *hash)
+{
+
+   memcpy(kv->hint->v.Rh.cached, hash, sizeof(kv->hint->v.Rh.cached));
+   kv->hint->status = HS_INITIALIZED;
+}
+
 /*
  * Implements random sort (-R).
  */
@@ -991,6 +1000,7 @@ randomcoll(struct key_value *kv1, struct key_value *kv
struct bwstring *s1, *s2;
MD5_CTX ctx1, ctx2;
unsigned char hash1[MD5_DIGEST_LENGTH], hash2[MD5_DIGEST_LENGTH];
+   int cmp;
 
s1 = kv1->k;
s2 = kv2->k;
@@ -1003,6 +1013,14 @@ randomcoll(struct key_value *kv1, struct key_value *kv
if (s1 == s2)
return (0);
 
+   if (kv1->hint->status == HS_INITIALIZED &&
+   kv2->hint->status == HS_INITIALIZED) {
+   cmp = memcmp(kv1->hint->v.Rh.cached,
+   kv2->hint->v.Rh.cached, sizeof(kv1->hint->v.Rh.cached));
+   if (cmp != 0)
+   return (cmp);
+   }
+
memcpy(, _ctx, sizeof(MD5_CTX));
memcpy(, _ctx, sizeof(MD5_CTX));
 
@@ -1011,6 +1029,11 @@ randomcoll(struct key_value *kv1, struct key_value *kv
 
MD5Final(hash1, );
MD5Final(hash2, );
+
+   if (kv1->hint->status == HS_UNINITIALIZED)
+   randomcoll_init_hint(kv1, hash1);
+   if (kv2->hint->status == HS_UNINITIALIZED)
+   randomcoll_init_hint(kv2, hash2);
 
return (memcmp(hash1, hash2, sizeof(hash1)));
 }

Modified: head/usr.bin/sort/coll.h
==
--- head/usr.bin/sort/coll.hSat Apr 13 04:03:18 2019(r346174)
+++ head/usr.bin/sort/coll.hSat Apr 13 04:42:17 2019(r346175)
@@ -65,6 +65,17 @@ struct M_hint
 };
 
 /*
+ * Sort hint data for -R
+ *
+ * This stores the first 12 bytes of the digest rather than the full output to
+ * avoid increasing the size of the 'key_hint' object via the 'v' union.
+ */
+struct R_hint
+{
+   unsigned charcached[12];
+};
+
+/*
  * Status of a sort hint object
  */
 typedef enum
@@ -83,6 +94,7 @@ struct key_hint
struct n_hint   nh;
struct g_hint   gh;
struct M_hint   Mh;
+   struct R_hint   Rh;
}   v;
 };
 

Modified: head/usr.bin/sort/sort.c
==
--- head/usr.bin/sort/sort.cSat Apr 13 04:03:18 2019(r346174)
+++ head/usr.bin/sort/sort.cSat Apr 13 04:42:17 2019(r346175)
@@ -583,6 +583,7 @@ set_sort_modifier(struct sort_mods *sm, int c)
break;
case 'R':
sm->Rflag = true;
+   need_hint = true;
need_random = true;
break;
case 'M':
___
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: r347888 - in head/sys/mips: include mips

2019-05-16 Thread Conrad Meyer
Author: cem
Date: Thu May 16 19:10:48 2019
New Revision: 347888
URL: https://svnweb.freebsd.org/changeset/base/347888

Log:
  mips: Implement basic pmap_kenter_device, pmap_kremove_device
  
  Unbreak mips.BERI_DE4_SDROOT build, which uses device xdma. Device xdma
  depends on the pmap_kenter_device APIs.
  
  Reported by:  tinderbox (local)
  Sponsored by: Dell EMC Isilon

Modified:
  head/sys/mips/include/pmap.h
  head/sys/mips/mips/pmap.c

Modified: head/sys/mips/include/pmap.h
==
--- head/sys/mips/include/pmap.hThu May 16 19:09:41 2019
(r347887)
+++ head/sys/mips/include/pmap.hThu May 16 19:10:48 2019
(r347888)
@@ -177,7 +177,9 @@ void pmap_unmapdev(vm_offset_t, vm_size_t);
 vm_offset_t pmap_steal_memory(vm_size_t size);
 void pmap_kenter(vm_offset_t va, vm_paddr_t pa);
 void pmap_kenter_attr(vm_offset_t va, vm_paddr_t pa, vm_memattr_t attr);
+void pmap_kenter_device(vm_offset_t, vm_size_t, vm_paddr_t);
 void pmap_kremove(vm_offset_t va);
+void pmap_kremove_device(vm_offset_t, vm_size_t);
 void *pmap_kenter_temporary(vm_paddr_t pa, int i);
 void pmap_kenter_temporary_free(vm_paddr_t pa);
 void pmap_flush_pvcache(vm_page_t m);

Modified: head/sys/mips/mips/pmap.c
==
--- head/sys/mips/mips/pmap.c   Thu May 16 19:09:41 2019(r347887)
+++ head/sys/mips/mips/pmap.c   Thu May 16 19:10:48 2019(r347888)
@@ -854,6 +854,44 @@ pmap_kenter(vm_offset_t va, vm_paddr_t pa)
pmap_kenter_attr(va, pa, VM_MEMATTR_DEFAULT);
 }
 
+void
+pmap_kenter_device(vm_offset_t va, vm_size_t size, vm_paddr_t pa)
+{
+
+   KASSERT((size & PAGE_MASK) == 0,
+   ("%s: device mapping not page-sized", __func__));
+
+   for (; size > 0; size -= PAGE_SIZE) {
+   /*
+* XXXCEM: this is somewhat inefficient on SMP systems in that
+* every single page is individually TLB-invalidated via
+* rendezvous (pmap_update_page()), instead of invalidating the
+* entire range via a single rendezvous.
+*/
+   pmap_kenter_attr(va, pa, VM_MEMATTR_UNCACHEABLE);
+   va += PAGE_SIZE;
+   pa += PAGE_SIZE;
+   }
+}
+
+void
+pmap_kremove_device(vm_offset_t va, vm_size_t size)
+{
+
+   KASSERT((size & PAGE_MASK) == 0,
+   ("%s: device mapping not page-sized", __func__));
+
+   /*
+* XXXCEM: Similar to pmap_kenter_device, this is inefficient on SMP,
+* in that pages are invalidated individually instead of a single range
+* rendezvous.
+*/
+   for (; size > 0; size -= PAGE_SIZE) {
+   pmap_kremove(va);
+   va += PAGE_SIZE;
+   }
+}
+
 /*
  * remove a page from the kernel pagetables
  */
___
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: r347639 - head/sys/x86/x86

2019-05-15 Thread Conrad Meyer
Author: cem
Date: Thu May 16 01:32:54 2019
New Revision: 347639
URL: https://svnweb.freebsd.org/changeset/base/347639

Log:
  x86: Correctly identify bhyve hypervisor
  
  Spotted after a similar report by Olivier Cochard-Labbé.
  
  Sponsored by: Dell EMC Isilon

Modified:
  head/sys/x86/x86/identcpu.c

Modified: head/sys/x86/x86/identcpu.c
==
--- head/sys/x86/x86/identcpu.c Thu May 16 01:09:13 2019(r347638)
+++ head/sys/x86/x86/identcpu.c Thu May 16 01:32:54 2019(r347639)
@@ -1365,7 +1365,7 @@ identify_hypervisor(void)
vm_guest = VM_GUEST_HV;
else if (strcmp(hv_vendor, "KVMKVMKVM") == 0)
vm_guest = VM_GUEST_KVM;
-   else if (strcmp(hv_vendor, "bhyve bhyve") == 0)
+   else if (strcmp(hv_vendor, "bhyve bhyve ") == 0)
vm_guest = VM_GUEST_BHYVE;
}
return;
___
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: r348255 - head/sys/kern

2019-05-24 Thread Conrad Meyer
Author: cem
Date: Fri May 24 22:33:14 2019
New Revision: 348255
URL: https://svnweb.freebsd.org/changeset/base/348255

Log:
  Disable intr_storm_threshold mechanism by default
  
  The ixl.4 manual page has documented that the threshold falsely detects
  interrupt storms on 40Gbit NICs as long ago as 2015, and we have seen
  similar false positives with the ioat(4) DMA device (which can push GB/s).
  
  For example, synthetic load can be generated with tools/tools/ioat
  'ioatcontrol 0 200 8192 1 1000' (allocate 200x8kB buffers, generate an
  interrupt for each one, and do this for 1000 milliseconds).  With
  storm-detection disabled, the Broadwell-EP version of this device is capable
  of generating ~350k real interrupts per second.
  
  The following historical context comes from jhb@: Originally, the threshold
  worked around incorrect routing of PCI INTx interrupts on single-CPU systems
  which would end up in a hard hang during boot.  Since the threshold was
  added, our PCI interrupt routing was improved, most PCI interrupts use
  edge-triggered MSI instead of level-triggered INTx, and typical systems have
  multiple CPUs available to service interrupts.
  
  On the off chance that the threshold is useful in the future, it remains
  available as a tunable and sysctl.
  
  Reviewed by:  jhb
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D20401

Modified:
  head/sys/kern/kern_intr.c

Modified: head/sys/kern/kern_intr.c
==
--- head/sys/kern/kern_intr.c   Fri May 24 22:30:40 2019(r348254)
+++ head/sys/kern/kern_intr.c   Fri May 24 22:33:14 2019(r348255)
@@ -91,7 +91,7 @@ struct proc *intrproc;
 
 static MALLOC_DEFINE(M_ITHREAD, "ithread", "Interrupt Threads");
 
-static int intr_storm_threshold = 1000;
+static int intr_storm_threshold = 0;
 SYSCTL_INT(_hw, OID_AUTO, intr_storm_threshold, CTLFLAG_RWTUN,
 _storm_threshold, 0,
 "Number of consecutive interrupts before storm protection is enabled");
___
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: r348262 - head/sys/dev/virtio/pci

2019-05-24 Thread Conrad Meyer
Author: cem
Date: Sat May 25 01:59:24 2019
New Revision: 348262
URL: https://svnweb.freebsd.org/changeset/base/348262

Log:
  virtio_pci(4): Fix typo in read_ivar method
  
  Prior to this revision, vtpci's BUS_READ_IVAR method on VIRTIO_IVAR_SUBVENDOR
  accidentally returned the PCI subdevice.
  
  The typo seems to have been introduced with the original commit adding
  VIRTIO_IVAR_{{SUB,}DEVICE,{SUB,}VENDOR} to virtio_pci.  The commit log and 
code
  strongly suggest that the ivar was intended to return the subvendor rather 
than
  the subdevice; it was likely just a copy/paste mistake.
  
  Go ahead and rectify that.

Modified:
  head/sys/dev/virtio/pci/virtio_pci.c

Modified: head/sys/dev/virtio/pci/virtio_pci.c
==
--- head/sys/dev/virtio/pci/virtio_pci.cSat May 25 01:58:00 2019
(r348261)
+++ head/sys/dev/virtio/pci/virtio_pci.cSat May 25 01:59:24 2019
(r348262)
@@ -408,7 +408,7 @@ vtpci_read_ivar(device_t dev, device_t child, int inde
*result = pci_get_device(dev);
break;
case VIRTIO_IVAR_SUBVENDOR:
-   *result = pci_get_subdevice(dev);
+   *result = pci_get_subvendor(dev);
break;
default:
return (ENOENT);
___
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: r348309 - head/usr.sbin/kldxref

2019-05-27 Thread Conrad Meyer
Author: cem
Date: Mon May 27 17:33:20 2019
New Revision: 348309
URL: https://svnweb.freebsd.org/changeset/base/348309

Log:
  kldxref(8): Sort MDT_MODULE info first in linker.hints output
  
  MDT_MODULE info is required to be ordered before any other MDT metadata for
  a given kld because it serves as an implicit record boundary between
  distinct klds for linker.hints consumers.  kldxref(8) has previously relied
  on the assumption that MDT_MODULE was ordered relative to other module
  metadata in kld objects by source code ordering.
  
  However, C does not require implementations to emit file scope objects in
  any particular order, and it seems that GCC 6.4.0 and/or binutils 2.32 ld
  may reorder emitted objects with respect to source code ordering.
  
  So: just take two passes over a given .ko's module metadata, scanning for
  the MDT_MODULE on the first pass and the other metadata on subsequent
  passes.  It's not super expensive and not exactly a performance-critical
  piece of code.  This ensures MDT_MODULE is always ordered before
  MDT_PNP_INFO and other MDTs, regardless of compiler/linker movement.  As a
  fringe benefit, it removes the requirement that care be taken to always
  order MODULE_PNP_INFO after DRIVER_MODULE in source code.
  
  Reviewed by:  emaste, imp
  Differential Revision:https://reviews.freebsd.org/D20405

Modified:
  head/usr.sbin/kldxref/kldxref.c

Modified: head/usr.sbin/kldxref/kldxref.c
==
--- head/usr.sbin/kldxref/kldxref.c Mon May 27 17:14:46 2019
(r348308)
+++ head/usr.sbin/kldxref/kldxref.c Mon May 27 17:33:20 2019
(r348309)
@@ -549,9 +549,9 @@ read_kld(char *filename, char *kldname)
 {
struct mod_metadata md;
struct elf_file ef;
-   void **p, **orgp;
+   void **p;
int error, eftype;
-   long start, finish, entries;
+   long start, finish, entries, i;
char cval[MAXMODNAME + 1];
 
if (verbose || dflag)
@@ -575,18 +575,53 @@ read_kld(char *filename, char *kldname)
));
check(EF_SEG_READ_ENTRY_REL(, start, sizeof(*p) * entries,
(void *)));
-   orgp = p;
-   while(entries--) {
-   check(EF_SEG_READ_REL(, (Elf_Off)*p, sizeof(md),
+   /*
+* Do a first pass to find MDT_MODULE.  It is required to be
+* ordered first in the output linker.hints stream because it
+* serves as an implicit record boundary between distinct klds
+* in the stream.  Other MDTs only make sense in the context of
+* a specific MDT_MODULE.
+*
+* Some compilers (e.g., GCC 6.4.0 xtoolchain) or binutils
+* (e.g., GNU binutils 2.32 objcopy/ld.bfd) can reorder
+* MODULE_METADATA set entries relative to the source ordering.
+* This is permitted by the C standard; memory layout of
+* file-scope objects is left implementation-defined.  There is
+* no requirement that source code ordering is retained.
+*
+* Handle that here by taking two passes to ensure MDT_MODULE
+* records are emitted to linker.hints before other MDT records
+* in the same kld.
+*/
+   for (i = 0; i < entries; i++) {
+   check(EF_SEG_READ_REL(, (Elf_Off)p[i], sizeof(md),
));
-   p++;
check(EF_SEG_READ_STRING(, (Elf_Off)md.md_cval,
sizeof(cval), cval));
-   parse_entry(, cval, , kldname);
+   if (md.md_type == MDT_MODULE) {
+   parse_entry(, cval, , kldname);
+   break;
+   }
}
+   if (error != 0) {
+   warnc(error, "error while reading %s", filename);
+   break;
+   }
+
+   /*
+* Second pass for all !MDT_MODULE entries.
+*/
+   for (i = 0; i < entries; i++) {
+   check(EF_SEG_READ_REL(, (Elf_Off)p[i], sizeof(md),
+   ));
+   check(EF_SEG_READ_STRING(, (Elf_Off)md.md_cval,
+   sizeof(cval), cval));
+   if (md.md_type != MDT_MODULE)
+   parse_entry(, cval, , kldname);
+   }
if (error != 0)
warnc(error, "error while reading %s", filename);
-   free(orgp);
+   free(p);
} while(0);
EF_CLOSE();
return (error);
___
svn-src-all@freebsd.org mailing list

svn commit: r348293 - head/sys/crypto/aesni

2019-05-26 Thread Conrad Meyer
Author: cem
Date: Mon May 27 00:47:51 2019
New Revision: 348293
URL: https://svnweb.freebsd.org/changeset/base/348293

Log:
  aesni(4): Fix trivial type typo
  
  This fixes the kernel build with xtoolchain-gcc (6.4.0).
  
  X-MFC-With:   r348268

Modified:
  head/sys/crypto/aesni/aesni_ccm.c

Modified: head/sys/crypto/aesni/aesni_ccm.c
==
--- head/sys/crypto/aesni/aesni_ccm.c   Mon May 27 00:43:43 2019
(r348292)
+++ head/sys/crypto/aesni/aesni_ccm.c   Mon May 27 00:47:51 2019
(r348293)
@@ -58,7 +58,7 @@
 static inline __m128i
 xor_and_encrypt(__m128i a, __m128i b, const unsigned char *k, int nr)
 {
-   __m128 retval = _mm_xor_si128(a, b);
+   __m128i retval = _mm_xor_si128(a, b);
 
retval = AESNI_ENC(retval, k, nr);
return (retval);
___
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: r348292 - head/sys/sys

2019-05-26 Thread Conrad Meyer
Author: cem
Date: Mon May 27 00:43:43 2019
New Revision: 348292
URL: https://svnweb.freebsd.org/changeset/base/348292

Log:
  sys/bufobj.h: Avoid using C++ reserved keyword 'private'
  
  No functional change (except for out-of-tree C++ kmods).

Modified:
  head/sys/sys/bufobj.h

Modified: head/sys/sys/bufobj.h
==
--- head/sys/sys/bufobj.h   Sun May 26 23:04:21 2019(r348291)
+++ head/sys/sys/bufobj.h   Mon May 27 00:43:43 2019(r348292)
@@ -127,7 +127,7 @@ struct bufobj {
 #defineASSERT_BO_LOCKED(bo)rw_assert(BO_LOCKPTR((bo)), RA_LOCKED)
 #defineASSERT_BO_UNLOCKED(bo)  rw_assert(BO_LOCKPTR((bo)), RA_UNLOCKED)
 
-void bufobj_init(struct bufobj *bo, void *private);
+void bufobj_init(struct bufobj *bo, void *priv);
 void bufobj_wdrop(struct bufobj *bo);
 void bufobj_wref(struct bufobj *bo);
 void bufobj_wrefl(struct bufobj *bo);
___
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: r348294 - head/share/man/man4

2019-05-26 Thread Conrad Meyer
Author: cem
Date: Mon May 27 00:51:27 2019
New Revision: 348294
URL: https://svnweb.freebsd.org/changeset/base/348294

Log:
  virtio.4: Add missing devices and Xr
  
  This page could probably use further improvement.

Modified:
  head/share/man/man4/virtio.4

Modified: head/share/man/man4/virtio.4
==
--- head/share/man/man4/virtio.4Mon May 27 00:47:51 2019
(r348293)
+++ head/share/man/man4/virtio.4Mon May 27 00:51:27 2019
(r348294)
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd January 22, 2012
+.Dd May 26, 2019
 .Dt VIRTIO 4
 .Os
 .Sh NAME
@@ -64,28 +64,37 @@ interrupt notifications needed to interact with the hy
 .Fx
 supports the following VirtIO devices:
 .Bl -hang -offset indent -width 
-.It Nm Ethernet
+.It Sy Ethernet
 An emulated Ethernet device is provided by the
 .Xr vtnet 4
 device driver.
-.It Nm Block
+.It Sy Block
 An emulated disk controller is provided by the
 .Xr virtio_blk 4
 device driver.
-.It Nm SCSI
-An emulated SCSI HBA is provided by the
-.Xr virtio_scsi 4
-device driver.
-.It Nm Balloon
+.It Sy Console
+Provided by the
+.Xr virtio_console 4
+driver.
+.It Sy Entropy
+Provided by the
+.Xr virtio_random 4
+driver.
+.It Sy Balloon
 A pseudo-device to allow the VM to release memory back to the hypervisor is
 provided by the
 .Xr virtio_balloon 4
 device driver.
+.It Sy SCSI
+An emulated SCSI HBA is provided by the
+.Xr virtio_scsi 4
+device driver.
 .El
 .Sh SEE ALSO
 .Xr virtio_balloon 4 ,
 .Xr virtio_blk 4 ,
 .Xr virtio_console 4 ,
+.Xr virtio_random 4 ,
 .Xr virtio_scsi 4 ,
 .Xr vtnet 4
 .Sh HISTORY
___
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: r348295 - head/sys/dev/virtio/random

2019-05-26 Thread Conrad Meyer
Author: cem
Date: Mon May 27 00:55:46 2019
New Revision: 348295
URL: https://svnweb.freebsd.org/changeset/base/348295

Log:
  virtio_random(4): Remove unneeded reference to device
  
  The device_t always references the softc, so we can pass the device and
  obtain the softc instead of the other way around.

Modified:
  head/sys/dev/virtio/random/virtio_random.c

Modified: head/sys/dev/virtio/random/virtio_random.c
==
--- head/sys/dev/virtio/random/virtio_random.c  Mon May 27 00:51:27 2019
(r348294)
+++ head/sys/dev/virtio/random/virtio_random.c  Mon May 27 00:55:46 2019
(r348295)
@@ -46,7 +46,6 @@ __FBSDID("$FreeBSD$");
 #include 
 
 struct vtrnd_softc {
-   device_t vtrnd_dev;
uint64_t vtrnd_features;
struct callout   vtrnd_callout;
struct virtqueue*vtrnd_vq;
@@ -58,8 +57,8 @@ static intvtrnd_probe(device_t);
 static int vtrnd_attach(device_t);
 static int vtrnd_detach(device_t);
 
-static voidvtrnd_negotiate_features(struct vtrnd_softc *);
-static int vtrnd_alloc_virtqueue(struct vtrnd_softc *);
+static voidvtrnd_negotiate_features(device_t);
+static int vtrnd_alloc_virtqueue(device_t);
 static voidvtrnd_harvest(struct vtrnd_softc *);
 static voidvtrnd_timer(void *);
 
@@ -129,14 +128,13 @@ vtrnd_attach(device_t dev)
int error;
 
sc = device_get_softc(dev);
-   sc->vtrnd_dev = dev;
 
callout_init(>vtrnd_callout, 1);
 
virtio_set_feature_desc(dev, vtrnd_feature_desc);
-   vtrnd_negotiate_features(sc);
+   vtrnd_negotiate_features(dev);
 
-   error = vtrnd_alloc_virtqueue(sc);
+   error = vtrnd_alloc_virtqueue(dev);
if (error) {
device_printf(dev, "cannot allocate virtqueue\n");
goto fail;
@@ -164,24 +162,21 @@ vtrnd_detach(device_t dev)
 }
 
 static void
-vtrnd_negotiate_features(struct vtrnd_softc *sc)
+vtrnd_negotiate_features(device_t dev)
 {
-   device_t dev;
-   uint64_t features;
+   struct vtrnd_softc *sc;
 
-   dev = sc->vtrnd_dev;
-   features = VTRND_FEATURES;
-
-   sc->vtrnd_features = virtio_negotiate_features(dev, features);
+   sc = device_get_softc(dev);
+   sc->vtrnd_features = virtio_negotiate_features(dev, VTRND_FEATURES);
 }
 
 static int
-vtrnd_alloc_virtqueue(struct vtrnd_softc *sc)
+vtrnd_alloc_virtqueue(device_t dev)
 {
-   device_t dev;
+   struct vtrnd_softc *sc;
struct vq_alloc_info vq_info;
 
-   dev = sc->vtrnd_dev;
+   sc = device_get_softc(dev);
 
VQ_ALLOC_INFO_INIT(_info, 0, NULL, sc, >vtrnd_vq,
"%s request", device_get_nameunit(dev));
___
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: r348611 - in head/sys: conf kern

2019-06-04 Thread Conrad Meyer
On Tue, Jun 4, 2019 at 7:15 AM Shawn Webb  wrote:
>
> On Tue, Jun 04, 2019 at 01:07:10PM +, Ed Maste wrote:
> > Author: emaste
> > Date: Tue Jun  4 13:07:10 2019
> > New Revision: 348611
> > URL: https://svnweb.freebsd.org/changeset/base/348611
> >
> > Log:
> >   Expose the kernel's build-ID through sysctl
> >
> >   After our migration (of certain architectures) to lld the kernel is built
> >   with a unique build-ID.  Make it available via a sysctl and uname(1) to
> >   allow the user to identify their running kernel.
>
> Does this impact reproducible builds at all?

Not at all, 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: r348629 - head/usr.sbin/daemon

2019-06-04 Thread Conrad Meyer
Author: cem
Date: Tue Jun  4 16:07:01 2019
New Revision: 348629
URL: https://svnweb.freebsd.org/changeset/base/348629

Log:
  daemon(8): Don't block SIGTERM during restart delay
  
  I believe this was introduced in the original '-r' commit, r231911 (2012).
  At the time, the scope was limited to a 1 second sleep.  r332518 (2018)
  added '-R', which increased the potential duration of the affected interval
  (from 1 to N seconds) by permitting arbitrary restart intervals.
  
  Instead, handle SIGTERM normally during restart-sleep, when the monitored
  process is not running, and shut down promptly.
  
  (I noticed this behavior when debugging a child process that exited quickly
  under the 'daemon -r -R 30' environment.  'kill ' had no
  immediate effect and the monitor process slept until the next restart
  attempt.  This was annoying.)
  
  Reviewed by:  allanjude, imp, markj
  Differential Revision:https://reviews.freebsd.org/D20509

Modified:
  head/usr.sbin/daemon/daemon.c

Modified: head/usr.sbin/daemon/daemon.c
==
--- head/usr.sbin/daemon/daemon.c   Tue Jun  4 15:44:31 2019
(r348628)
+++ head/usr.sbin/daemon/daemon.c   Tue Jun  4 16:07:01 2019
(r348629)
@@ -359,12 +359,13 @@ restart:
}
}
}
+   if (restart && !terminate)
+   daemon_sleep(restart, 0);
if (sigprocmask(SIG_BLOCK, _term, NULL)) {
warn("sigprocmask");
goto exit;
}
if (restart && !terminate) {
-   daemon_sleep(restart, 0);
close(pfd[0]);
pfd[0] = -1;
goto restart;
@@ -384,7 +385,8 @@ static void
 daemon_sleep(time_t secs, long nsecs)
 {
struct timespec ts = { secs, nsecs };
-   while (nanosleep(, ) == -1) {
+
+   while (!terminate && nanosleep(, ) == -1) {
if (errno != EINTR)
err(1, "nanosleep");
}
___
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: r348419 - in head: crypto/heimdal/lib/ipc share/man/man4 sys/compat/linux sys/kern sys/sys usr.sbin/mountd

2019-06-04 Thread Conrad Meyer
On Tue, Jun 4, 2019 at 6:31 PM Bruce Evans  wrote:
> On Tue, 4 Jun 2019, Gleb Smirnoff wrote:
> > Why don't use C99 in 2019 instead of preprocessor define? Should be
> >
> >   union {
> >   void*_cr_unused1;   /* compatibility with old ucred */
> >   pid_t   cr_pid;
> >   };
>
> Anonymous unions are a gnu89 extension.  Only broken C99 compilers like
> clang -std=c99 accept them.
>
> [Pedantic tangent elided.]

Gleb simply misspoke.  Anonymous unions are part of the standard C11,
rather than C99, language; §6.7.2.1, (13).

The point stands; it's 2019 and the feature has been part of the
working language long prior to its standardization in 2011.

Cheers,
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: r348337 - head/share/man/man9

2019-05-28 Thread Conrad Meyer
Author: cem
Date: Tue May 28 20:44:23 2019
New Revision: 348337
URL: https://svnweb.freebsd.org/changeset/base/348337

Log:
  style.9: Correct usage's definition to match its declaration
  
  Suggested by: emaste
  Reviewed by:  delphij, imp, rgrimes, vangyzen (earlier version)
  Sponsored by: Dell EMC Isilon
  Differential Revision:(part of D20448)

Modified:
  head/share/man/man9/style.9

Modified: head/share/man/man9/style.9
==
--- head/share/man/man9/style.9 Tue May 28 20:14:33 2019(r348336)
+++ head/share/man/man9/style.9 Tue May 28 20:44:23 2019(r348337)
@@ -26,7 +26,7 @@
 .\"From: @(#)style 1.14 (Berkeley) 4/28/95
 .\" $FreeBSD$
 .\"
-.Dd November 1, 2018
+.Dd May 28, 2019
 .Dt STYLE 9
 .Os
 .Sh NAME
@@ -777,7 +777,7 @@ vaf(const char *fmt, ...)
 }
 
 static void
-usage()
+usage(void)
 {
/* Insert an empty line if the function has no local variables. */
 .Ed
___
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: r348489 - in head/sys: conf dev/random dev/virtio/random

2019-05-31 Thread Conrad Meyer
Author: cem
Date: Sat Jun  1 01:22:21 2019
New Revision: 348489
URL: https://svnweb.freebsd.org/changeset/base/348489

Log:
  random(4): Fix RANDOM_LOADABLE build
  
  I introduced an obvious compiler error in r346282, so this change fixes
  that.
  
  Unfortunately, RANDOM_LOADABLE isn't covered by our existing tinderbox, and
  it seems like there were existing latent linking problems.  I believe these
  were introduced on accident in r338324 during reduction of the boolean
  expression(s) adjacent to randomdev.c and hash.c.  It seems the
  RANDOM_LOADABLE build breakage has gone unnoticed for nine months.
  
  This change correctly annotates randomdev.c and hash.c with !random_loadable
  to match the pre-r338324 logic; and additionally updates the HWRNG drivers
  in MD 'files.*', which depend on random_device symbols, with
  !random_loadable (it is invalid for the kernel to depend on symbols from a
  module).
  
  (The expression for both randomdev.c and hash.c was the same, prior to
  r338324: "optional random random_yarrow | random !random_yarrow
  !random_loadable".  I.e., "random && (yarrow || !loadable)."  When Yarrow
  was removed ("yarrow := False"), the expression was incorrectly reduced to
  "optional random" when it should have retained "random && !loadable".)
  
  Additionally, I discovered that virtio_random was missing a MODULE_DEPEND on
  random_device, which breaks kld load/link of the driver on RANDOM_LOADABLE
  kernels.  Address that issue as well.
  
  PR:   238223
  Reported by:  Eir Nym 
  Reviewed by:  delphij, markm
  Approved by:  secteam(delphij)
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D20466

Modified:
  head/sys/conf/files
  head/sys/conf/files.amd64
  head/sys/conf/files.arm64
  head/sys/conf/files.i386
  head/sys/conf/files.powerpc
  head/sys/dev/random/random_infra.c
  head/sys/dev/virtio/random/virtio_random.c

Modified: head/sys/conf/files
==
--- head/sys/conf/files Sat Jun  1 01:08:40 2019(r348488)
+++ head/sys/conf/files Sat Jun  1 01:22:21 2019(r348489)
@@ -2758,9 +2758,9 @@ rt2860.fw optional rt2860fw | ralfw   
\
clean   "rt2860.fw"
 dev/random/random_infra.c  optional random
 dev/random/random_harvestq.c   optional random
-dev/random/randomdev.c optional random
+dev/random/randomdev.c optional random !random_loadable
 dev/random/fortuna.c   optional random !random_loadable
-dev/random/hash.c  optional random
+dev/random/hash.c  optional random !random_loadable
 dev/rc/rc.coptional rc
 dev/rccgpio/rccgpio.c  optional rccgpio gpio
 dev/re/if_re.c optional re

Modified: head/sys/conf/files.amd64
==
--- head/sys/conf/files.amd64   Sat Jun  1 01:08:40 2019(r348488)
+++ head/sys/conf/files.amd64   Sat Jun  1 01:22:21 2019(r348489)
@@ -368,8 +368,8 @@ dev/nvme/nvme_sysctl.c  optionalnvme
 dev/nvme/nvme_test.c   optionalnvme
 dev/nvme/nvme_util.c   optionalnvme
 dev/nvram/nvram.c  optionalnvram isa
-dev/random/ivy.c   optionalrdrand_rng
-dev/random/nehemiah.c  optionalpadlock_rng
+dev/random/ivy.c   optionalrdrand_rng !random_loadable
+dev/random/nehemiah.c  optionalpadlock_rng !random_loadable
 dev/qlxge/qls_dbg.coptionalqlxge pci
 dev/qlxge/qls_dump.c   optionalqlxge pci
 dev/qlxge/qls_hw.c optionalqlxge pci

Modified: head/sys/conf/files.arm64
==
--- head/sys/conf/files.arm64   Sat Jun  1 01:08:40 2019(r348488)
+++ head/sys/conf/files.arm64   Sat Jun  1 01:22:21 2019(r348489)
@@ -87,7 +87,7 @@ arm/broadcom/bcm2835/bcm2835_ft5406.c optional evdev 
 arm/broadcom/bcm2835/bcm2835_gpio.coptional gpio soc_brcm_bcm2837 
fdt
 arm/broadcom/bcm2835/bcm2835_intr.coptional soc_brcm_bcm2837 fdt
 arm/broadcom/bcm2835/bcm2835_mbox.coptional soc_brcm_bcm2837 fdt
-arm/broadcom/bcm2835/bcm2835_rng.c optional random 
soc_brcm_bcm2837 fdt
+arm/broadcom/bcm2835/bcm2835_rng.c optional random 
!random_loadable soc_brcm_bcm2837 fdt
 arm/broadcom/bcm2835/bcm2835_sdhci.c   optional sdhci soc_brcm_bcm2837 
fdt
 arm/broadcom/bcm2835/bcm2835_sdhost.c  optional sdhci soc_brcm_bcm2837 
fdt
 arm/broadcom/bcm2835/bcm2835_spi.c optional bcm2835_spi 
soc_brcm_bcm2837 fdt

Modified: head/sys/conf/files.i386
==
--- head/sys/conf/files.i386Sat Jun  1 01:08:40 2019

svn commit: r348594 - head/share/man/man9

2019-06-03 Thread Conrad Meyer
Author: cem
Date: Mon Jun  3 23:57:29 2019
New Revision: 348594
URL: https://svnweb.freebsd.org/changeset/base/348594

Log:
  style.9: Codify tolerance for eliding blank lines
  
  Consensus seems to be that eliding blank lines for functions with no local
  variables is acceptable.  Codify that explicitly in the style document.
  
  Reported by:  jhb
  Reviewed by:  delphij, imp, vangyzen (earlier version); rgrimes
  With feedback from:   kib
  Differential Revision:https://reviews.freebsd.org/D20448

Modified:
  head/share/man/man9/style.9

Modified: head/share/man/man9/style.9
==
--- head/share/man/man9/style.9 Mon Jun  3 23:24:07 2019(r348593)
+++ head/share/man/man9/style.9 Mon Jun  3 23:57:29 2019(r348594)
@@ -26,7 +26,7 @@
 .\"From: @(#)style 1.14 (Berkeley) 4/28/95
 .\" $FreeBSD$
 .\"
-.Dd May 28, 2019
+.Dd June 3, 2019
 .Dt STYLE 9
 .Os
 .Sh NAME
@@ -779,8 +779,19 @@ vaf(const char *fmt, ...)
 static void
 usage(void)
 {
-   /* Insert an empty line if the function has no local variables. */
+   /* Optional blank line goes here. */
 .Ed
+.Pp
+Optionally, insert a blank line at the beginning of functions with no local
+variables.
+Older versions of this
+.Nm
+document required the blank line convention, so it is widely used in existing
+code.
+.Pp
+Do not insert a blank line at the beginning of functions with local variables.
+Instead, these should have local variable declarations first, followed by one
+blank line, followed by the first statement.
 .Pp
 Use
 .Xr printf 3 ,
___
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: r348595 - head/sys/dev/virtio/random

2019-06-03 Thread Conrad Meyer
Author: cem
Date: Tue Jun  4 00:01:37 2019
New Revision: 348595
URL: https://svnweb.freebsd.org/changeset/base/348595

Log:
  virtio_random(4): Fix random(4) integration
  
  random(4) masks unregistered entropy sources.  Prior to this revision,
  virtio_random(4) did not correctly register a random_source and did not
  function as a source of entropy.
  
  Random source registration for loadable pure sources requires registering a
  poll callback, which is invoked periodically by random(4)'s harvestq
  kthread.  The periodic poll makes virtio_random(4)'s periodic entropy
  collection redundant, so this revision removes the callout.
  
  The current random source API is somewhat limiting, so simply fail to attach
  any virtio_random devices if one is already registered as a source.  This
  scenario is expected to be uncommon.
  
  While here, handle the possibility of short reads from the hypervisor random
  device gracefully / correctly.  It is not clear why a hypervisor would
  return a short read or if it is allowed by spec, but we may as well handle
  it.
  
  Reviewed by:  bryanv (earlier version), markm
  Security: yes (note: many other "pure" random sources remain broken)
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D20419

Modified:
  head/sys/dev/virtio/random/virtio_random.c

Modified: head/sys/dev/virtio/random/virtio_random.c
==
--- head/sys/dev/virtio/random/virtio_random.c  Mon Jun  3 23:57:29 2019
(r348594)
+++ head/sys/dev/virtio/random/virtio_random.c  Tue Jun  4 00:01:37 2019
(r348595)
@@ -33,21 +33,24 @@ __FBSDID("$FreeBSD$");
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 
+#include 
+#include 
 #include 
 #include 
 
 struct vtrnd_softc {
uint64_t vtrnd_features;
-   struct callout   vtrnd_callout;
struct virtqueue*vtrnd_vq;
 };
 
@@ -59,8 +62,8 @@ static intvtrnd_detach(device_t);
 
 static voidvtrnd_negotiate_features(device_t);
 static int vtrnd_alloc_virtqueue(device_t);
-static voidvtrnd_harvest(struct vtrnd_softc *);
-static voidvtrnd_timer(void *);
+static int vtrnd_harvest(struct vtrnd_softc *, void *, size_t *);
+static unsignedvtrnd_read(void *, unsigned);
 
 #define VTRND_FEATURES 0
 
@@ -68,6 +71,15 @@ static struct virtio_feature_desc vtrnd_feature_desc[]
{ 0, NULL }
 };
 
+static struct random_source random_vtrnd = {
+   .rs_ident = "VirtIO Entropy Adapter",
+   .rs_source = RANDOM_PURE_VIRTIO,
+   .rs_read = vtrnd_read,
+};
+
+/* Kludge for API limitations of random(4). */
+static _Atomic(struct vtrnd_softc *) g_vtrnd_softc;
+
 static device_method_t vtrnd_methods[] = {
/* Device methods. */
DEVMETHOD(device_probe, vtrnd_probe),
@@ -125,13 +137,11 @@ vtrnd_probe(device_t dev)
 static int
 vtrnd_attach(device_t dev)
 {
-   struct vtrnd_softc *sc;
+   struct vtrnd_softc *sc, *exp;
int error;
 
sc = device_get_softc(dev);
 
-   callout_init(>vtrnd_callout, 1);
-
virtio_set_feature_desc(dev, vtrnd_feature_desc);
vtrnd_negotiate_features(dev);
 
@@ -141,7 +151,13 @@ vtrnd_attach(device_t dev)
goto fail;
}
 
-   callout_reset(>vtrnd_callout, 5 * hz, vtrnd_timer, sc);
+   exp = NULL;
+   if (!atomic_compare_exchange_strong_explicit(_vtrnd_softc, , sc,
+   memory_order_release, memory_order_acquire)) {
+   error = EEXIST;
+   goto fail;
+   }
+   random_source_register(_vtrnd);
 
 fail:
if (error)
@@ -156,9 +172,20 @@ vtrnd_detach(device_t dev)
struct vtrnd_softc *sc;
 
sc = device_get_softc(dev);
+   KASSERT(
+   atomic_load_explicit(_vtrnd_softc, memory_order_acquire) == sc,
+   ("only one global instance at a time"));
 
-   callout_drain(>vtrnd_callout);
+   random_source_deregister(_vtrnd);
+   atomic_store_explicit(_vtrnd_softc, NULL, memory_order_release);
 
+   /*
+* Unfortunately, deregister does not guarantee our source callback
+* will not be invoked after it returns.  Use a kludge to prevent some,
+* but not all, possible races.
+*/
+   tsleep_sbt(_vtrnd_softc, 0, "vtrnddet", mstosbt(50), 0, C_HARDCLOCK);
+
return (0);
 }
 
@@ -185,44 +212,64 @@ vtrnd_alloc_virtqueue(device_t dev)
return (virtio_alloc_virtqueues(dev, 0, 1, _info));
 }
 
-static void
-vtrnd_harvest(struct vtrnd_softc *sc)
+static int
+vtrnd_harvest(struct vtrnd_softc *sc, void *buf, size_t *sz)
 {
struct sglist_seg segs[1];
struct sglist sg;
struct virtqueue *vq;
-   uint32_t value;
+   uint32_t value[HARVESTSIZE] __aligned(sizeof(uint32_t) * HARVESTSIZE);
+   uint32_t rdlen;
int error;
 

svn commit: r348598 - in head/sys/dev/virtio: . mmio pci

2019-06-03 Thread Conrad Meyer
Author: cem
Date: Tue Jun  4 02:34:59 2019
New Revision: 348598
URL: https://svnweb.freebsd.org/changeset/base/348598

Log:
  virtio(4): Expose PNP metadata through newbus
  
  Expose the same fields and widths from both vtio buses, even though they
  don't quite line up; several virtio drivers can attach to both buses,
  and sharing a PNP info table for both seems more convenient.
  
  In practice, I doubt any virtio driver really needs to match on anything
  other than bus and device_type (eliminating the unused entries for
  vtmmio), and also in practice device_type is << 2^16 (so far, values
  range from 1 to 20).  So it might be fine to only expose a 16-bit
  device_type for PNP purposes.  On the other hand, I don't see much harm
  in overkill here.
  
  Reviewed by:  bryanv, markj (earlier version)
  Differential Revision:https://reviews.freebsd.org/D20406

Modified:
  head/sys/dev/virtio/mmio/virtio_mmio.c
  head/sys/dev/virtio/pci/virtio_pci.c
  head/sys/dev/virtio/virtio.c
  head/sys/dev/virtio/virtio.h

Modified: head/sys/dev/virtio/mmio/virtio_mmio.c
==
--- head/sys/dev/virtio/mmio/virtio_mmio.c  Tue Jun  4 01:00:30 2019
(r348597)
+++ head/sys/dev/virtio/mmio/virtio_mmio.c  Tue Jun  4 02:34:59 2019
(r348598)
@@ -145,6 +145,7 @@ static device_method_t vtmmio_methods[] = {
/* Bus interface. */
DEVMETHOD(bus_driver_added,   vtmmio_driver_added),
DEVMETHOD(bus_child_detached, vtmmio_child_detached),
+   DEVMETHOD(bus_child_pnpinfo_str,  virtio_child_pnpinfo_str),
DEVMETHOD(bus_read_ivar,  vtmmio_read_ivar),
DEVMETHOD(bus_write_ivar, vtmmio_write_ivar),
 
@@ -331,6 +332,14 @@ vtmmio_read_ivar(device_t dev, device_t child, int ind
break;
case VIRTIO_IVAR_VENDOR:
*result = vtmmio_read_config_4(sc, VIRTIO_MMIO_VENDOR_ID);
+   break;
+   case VIRTIO_IVAR_SUBVENDOR:
+   case VIRTIO_IVAR_DEVICE:
+   /*
+* Dummy value for fields not present in this bus.  Used by
+* bus-agnostic virtio_child_pnpinfo_str.
+*/
+   *result = 0;
break;
default:
return (ENOENT);

Modified: head/sys/dev/virtio/pci/virtio_pci.c
==
--- head/sys/dev/virtio/pci/virtio_pci.cTue Jun  4 01:00:30 2019
(r348597)
+++ head/sys/dev/virtio/pci/virtio_pci.cTue Jun  4 02:34:59 2019
(r348598)
@@ -200,6 +200,7 @@ static device_method_t vtpci_methods[] = {
/* Bus interface. */
DEVMETHOD(bus_driver_added,   vtpci_driver_added),
DEVMETHOD(bus_child_detached, vtpci_child_detached),
+   DEVMETHOD(bus_child_pnpinfo_str,  virtio_child_pnpinfo_str),
DEVMETHOD(bus_read_ivar,  vtpci_read_ivar),
DEVMETHOD(bus_write_ivar, vtpci_write_ivar),
 

Modified: head/sys/dev/virtio/virtio.c
==
--- head/sys/dev/virtio/virtio.cTue Jun  4 01:00:30 2019
(r348597)
+++ head/sys/dev/virtio/virtio.cTue Jun  4 02:34:59 2019
(r348598)
@@ -263,6 +263,30 @@ virtio_write_device_config(device_t dev, bus_size_t of
offset, dst, len);
 }
 
+int
+virtio_child_pnpinfo_str(device_t busdev __unused, device_t child, char *buf,
+size_t buflen)
+{
+
+   /*
+* All of these PCI fields will be only 16 bits, but on the vtmmio bus
+* the corresponding fields (only "vendor" and "device_type") are 32
+* bits.  Many virtio drivers can attach below either bus.
+* Gratuitously expand these two fields to 32-bits to allow sharing PNP
+* match table data between the mostly-similar buses.
+*
+* Subdevice and device_type are redundant in both buses, so I don't
+* see a lot of PNP utility in exposing the same value under a
+* different name.
+*/
+   snprintf(buf, buflen, "vendor=0x%08x device=0x%04x subvendor=0x%04x "
+   "device_type=0x%08x", (unsigned)virtio_get_vendor(child),
+   (unsigned)virtio_get_device(child),
+   (unsigned)virtio_get_subvendor(child),
+   (unsigned)virtio_get_device_type(child));
+   return (0);
+}
+
 static int
 virtio_modevent(module_t mod, int type, void *unused)
 {

Modified: head/sys/dev/virtio/virtio.h
==
--- head/sys/dev/virtio/virtio.hTue Jun  4 01:00:30 2019
(r348597)
+++ head/sys/dev/virtio/virtio.hTue Jun  4 02:34:59 2019
(r348598)
@@ -81,6 +81,8 @@ void   virtio_stop(device_t dev);
 int virtio_config_generation(device_t 

svn commit: r348599 - in head/sys/dev/virtio: . balloon block console network random scsi

2019-06-03 Thread Conrad Meyer
Author: cem
Date: Tue Jun  4 02:37:11 2019
New Revision: 348599
URL: https://svnweb.freebsd.org/changeset/base/348599

Log:
  virtio(4): Add PNP match metadata for virtio devices
  
  Register MODULE_PNP_INFO for virtio devices using the newbus PNP information
  provided by the previous commit.  Matching can be quite simple; existing
  probe routines only matched on bus (implicit) and device_type.  The same
  matching criteria are retained exactly, but is now also available to
  devmatch(8).
  
  Reviewed by:  bryanv, markj; imp (earlier version)
  Differential Revision:https://reviews.freebsd.org/D20407

Modified:
  head/sys/dev/virtio/balloon/virtio_balloon.c
  head/sys/dev/virtio/block/virtio_blk.c
  head/sys/dev/virtio/console/virtio_console.c
  head/sys/dev/virtio/network/if_vtnet.c
  head/sys/dev/virtio/random/virtio_random.c
  head/sys/dev/virtio/scsi/virtio_scsi.c
  head/sys/dev/virtio/virtio.h

Modified: head/sys/dev/virtio/balloon/virtio_balloon.c
==
--- head/sys/dev/virtio/balloon/virtio_balloon.cTue Jun  4 02:34:59 
2019(r348598)
+++ head/sys/dev/virtio/balloon/virtio_balloon.cTue Jun  4 02:37:11 
2019(r348599)
@@ -158,16 +158,14 @@ DRIVER_MODULE(virtio_balloon, virtio_pci, vtballoon_dr
 MODULE_VERSION(virtio_balloon, 1);
 MODULE_DEPEND(virtio_balloon, virtio, 1, 1, 1);
 
+VIRTIO_SIMPLE_PNPTABLE(virtio_balloon, VIRTIO_ID_BALLOON,
+"VirtIO Balloon Adapter");
+VIRTIO_SIMPLE_PNPINFO(virtio_pci, virtio_balloon);
+
 static int
 vtballoon_probe(device_t dev)
 {
-
-   if (virtio_get_device_type(dev) != VIRTIO_ID_BALLOON)
-   return (ENXIO);
-
-   device_set_desc(dev, "VirtIO Balloon Adapter");
-
-   return (BUS_PROBE_DEFAULT);
+   return (VIRTIO_SIMPLE_PROBE(dev, virtio_balloon));
 }
 
 static int

Modified: head/sys/dev/virtio/block/virtio_blk.c
==
--- head/sys/dev/virtio/block/virtio_blk.c  Tue Jun  4 02:34:59 2019
(r348598)
+++ head/sys/dev/virtio/block/virtio_blk.c  Tue Jun  4 02:37:11 2019
(r348599)
@@ -261,6 +261,10 @@ DRIVER_MODULE(virtio_blk, virtio_pci, vtblk_driver, vt
 MODULE_VERSION(virtio_blk, 1);
 MODULE_DEPEND(virtio_blk, virtio, 1, 1, 1);
 
+VIRTIO_SIMPLE_PNPTABLE(virtio_blk, VIRTIO_ID_BLOCK, "VirtIO Block Adapter");
+VIRTIO_SIMPLE_PNPINFO(virtio_mmio, virtio_blk);
+VIRTIO_SIMPLE_PNPINFO(virtio_pci, virtio_blk);
+
 static int
 vtblk_modevent(module_t mod, int type, void *unused)
 {
@@ -285,13 +289,7 @@ vtblk_modevent(module_t mod, int type, void *unused)
 static int
 vtblk_probe(device_t dev)
 {
-
-   if (virtio_get_device_type(dev) != VIRTIO_ID_BLOCK)
-   return (ENXIO);
-
-   device_set_desc(dev, "VirtIO Block Adapter");
-
-   return (BUS_PROBE_DEFAULT);
+   return (VIRTIO_SIMPLE_PROBE(dev, virtio_blk));
 }
 
 static int

Modified: head/sys/dev/virtio/console/virtio_console.c
==
--- head/sys/dev/virtio/console/virtio_console.cTue Jun  4 02:34:59 
2019(r348598)
+++ head/sys/dev/virtio/console/virtio_console.cTue Jun  4 02:37:11 
2019(r348599)
@@ -261,6 +261,10 @@ DRIVER_MODULE(virtio_console, virtio_pci, vtcon_driver
 MODULE_VERSION(virtio_console, 1);
 MODULE_DEPEND(virtio_console, virtio, 1, 1, 1);
 
+VIRTIO_SIMPLE_PNPTABLE(virtio_console, VIRTIO_ID_CONSOLE,
+"VirtIO Console Adapter");
+VIRTIO_SIMPLE_PNPINFO(virtio_pci, virtio_console);
+
 static int
 vtcon_modevent(module_t mod, int type, void *unused)
 {
@@ -305,13 +309,7 @@ vtcon_drain_all(void)
 static int
 vtcon_probe(device_t dev)
 {
-
-   if (virtio_get_device_type(dev) != VIRTIO_ID_CONSOLE)
-   return (ENXIO);
-
-   device_set_desc(dev, "VirtIO Console Adapter");
-
-   return (BUS_PROBE_DEFAULT);
+   return (VIRTIO_SIMPLE_PROBE(dev, virtio_console));
 }
 
 static int

Modified: head/sys/dev/virtio/network/if_vtnet.c
==
--- head/sys/dev/virtio/network/if_vtnet.c  Tue Jun  4 02:34:59 2019
(r348598)
+++ head/sys/dev/virtio/network/if_vtnet.c  Tue Jun  4 02:37:11 2019
(r348599)
@@ -325,6 +325,10 @@ MODULE_DEPEND(vtnet, virtio, 1, 1, 1);
 MODULE_DEPEND(vtnet, netmap, 1, 1, 1);
 #endif /* DEV_NETMAP */
 
+VIRTIO_SIMPLE_PNPTABLE(vtnet, VIRTIO_ID_NETWORK, "VirtIO Networking Adapter");
+VIRTIO_SIMPLE_PNPINFO(virtio_mmio, vtnet);
+VIRTIO_SIMPLE_PNPINFO(virtio_pci, vtnet);
+
 static int
 vtnet_modevent(module_t mod, int type, void *unused)
 {
@@ -361,13 +365,7 @@ vtnet_modevent(module_t mod, int type, void *unused)
 static int
 vtnet_probe(device_t dev)
 {
-
-   if (virtio_get_device_type(dev) != VIRTIO_ID_NETWORK)
-   return (ENXIO);
-
-   device_set_desc(dev, "VirtIO Networking Adapter");
-
-   return 

svn commit: r349137 - in head: etc/mtree sys/dev/random tests/sys tests/sys/devrandom

2019-06-17 Thread Conrad Meyer
Author: cem
Date: Mon Jun 17 14:59:45 2019
New Revision: 349137
URL: https://svnweb.freebsd.org/changeset/base/349137

Log:
  random(4): Add regression tests for uint128 implementation, Chacha CTR
  
  Add some basic regression tests to verify behavior of both uint128
  implementations at typical boundary conditions, to run on all architectures.
  
  Test uint128 increment behavior of Chacha in keystream mode, as used by
  'kern.random.use_chacha20_cipher=1' (r344913) to verify assumptions at edge
  cases.  These assumptions are critical to the safety of using Chacha as a
  PRF in Fortuna (as implemented).
  
  (Chacha's use in arc4random is safe regardless of these tests, as it is
  limited to far less than 4 billion blocks of output in that API.)
  
  Reviewed by:  markm
  Approved by:  secteam(gordon)
  Differential Revision:https://reviews.freebsd.org/D20392

Added:
  head/tests/sys/devrandom/
  head/tests/sys/devrandom/Makefile   (contents, props changed)
  head/tests/sys/devrandom/uint128_test.c   (contents, props changed)
Modified:
  head/etc/mtree/BSD.tests.dist
  head/sys/dev/random/hash.c
  head/sys/dev/random/hash.h
  head/tests/sys/Makefile

Modified: head/etc/mtree/BSD.tests.dist
==
--- head/etc/mtree/BSD.tests.dist   Mon Jun 17 14:42:27 2019
(r349136)
+++ head/etc/mtree/BSD.tests.dist   Mon Jun 17 14:59:45 2019
(r349137)
@@ -722,6 +722,8 @@
 ..
 ..
 ..
+devrandom
+..
 dtrace
 ..
 fifo

Modified: head/sys/dev/random/hash.c
==
--- head/sys/dev/random/hash.c  Mon Jun 17 14:42:27 2019(r349136)
+++ head/sys/dev/random/hash.c  Mon Jun 17 14:59:45 2019(r349137)
@@ -37,12 +37,16 @@ __FBSDID("$FreeBSD$");
 #else /* !_KERNEL */
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
-#include "unit_test.h"
+#define KASSERT(x, y)  assert(x)
+#define CTASSERT(x)_Static_assert(x, "CTASSERT " #x)
 #endif /* _KERNEL */
 
 #define CHACHA_EMBED

Modified: head/sys/dev/random/hash.h
==
--- head/sys/dev/random/hash.h  Mon Jun 17 14:42:27 2019(r349136)
+++ head/sys/dev/random/hash.h  Mon Jun 17 14:59:45 2019(r349137)
@@ -54,7 +54,7 @@ union randomdev_key {
struct chacha_ctx chacha;
 };
 
-extern bool fortuna_chachamode;
+extern bool random_chachamode;
 
 void randomdev_hash_init(struct randomdev_hash *);
 void randomdev_hash_iterate(struct randomdev_hash *, const void *, size_t);

Modified: head/tests/sys/Makefile
==
--- head/tests/sys/Makefile Mon Jun 17 14:42:27 2019(r349136)
+++ head/tests/sys/Makefile Mon Jun 17 14:59:45 2019(r349137)
@@ -10,6 +10,7 @@ TESTS_SUBDIRS+=   ${_audit}
 TESTS_SUBDIRS+=auditpipe
 TESTS_SUBDIRS+=capsicum
 TESTS_SUBDIRS+=${_cddl}
+TESTS_SUBDIRS+=devrandom
 TESTS_SUBDIRS+=fifo
 TESTS_SUBDIRS+=file
 TESTS_SUBDIRS+=fs

Added: head/tests/sys/devrandom/Makefile
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/tests/sys/devrandom/Makefile   Mon Jun 17 14:59:45 2019
(r349137)
@@ -0,0 +1,26 @@
+# $FreeBSD$
+
+.include 
+
+SDEVRANDOM=${SRCTOP}/sys/dev/random
+.PATH: ${SDEVRANDOM}
+
+TESTSDIR=  ${TESTSBASE}/sys/devrandom
+WARNS?=6
+
+CFLAGS+=   -I${SRCTOP}/sys
+
+ATF_TESTS_C+=  uint128_test
+
+# Test Chacha CTR behavior <-> uint128
+LDADD.uint128_test+=   ${SDEVRANDOM}/hash.c
+LDFLAGS.uint128_test+= -Wno-unused-parameter
+
+# hash.c deps:
+LIBADD.uint128_test+=  md  # SHA256
+LDADD.uint128_test+=   ${SRCTOP}/sys/crypto/rijndael/rijndael-alg-fst.c
+LDADD.uint128_test+=   ${SRCTOP}/sys/crypto/rijndael/rijndael-api-fst.c
+LDFLAGS.uint128_test+= -Wno-cast-align
+
+
+.include 

Added: head/tests/sys/devrandom/uint128_test.c
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/tests/sys/devrandom/uint128_test.c Mon Jun 17 14:59:45 2019
(r349137)
@@ -0,0 +1,225 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2019 Conrad Meyer 
+ * All rights reserved.
+ *
+ * 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, this list of conditions

svn commit: r349138 - in head: sys/dev/random tests/sys/devrandom

2019-06-17 Thread Conrad Meyer
Author: cem
Date: Mon Jun 17 15:09:12 2019
New Revision: 349138
URL: https://svnweb.freebsd.org/changeset/base/349138

Log:
  random(4): Generalize algorithm-independent APIs
  
  At a basic level, remove assumptions about the underlying algorithm (such as
  output block size and reseeding requirements) from the algorithm-independent
  logic in randomdev.c.  Chacha20 does not have many of the restrictions that
  AES-ICM does as a PRF (Pseudo-Random Function), because it has a cipher
  block size of 512 bits.  The motivation is that by generalizing the API,
  Chacha is not penalized by the limitations of AES.
  
  In READ_RANDOM_UIO, first attempt to NOWAIT allocate a large enough buffer
  for the entire user request, or the maximal input we'll accept between
  signal checking, whichever is smaller.  The idea is that the implementation
  of any randomdev algorithm is then free to divide up large requests in
  whatever fashion it sees fit.
  
  As part of this, two responsibilities from the "algorithm-generic" randomdev
  code are pushed down into the Fortuna ra_read implementation (and any other
  future or out-of-tree ra_read implementations):
  
1. If an algorithm needs to rekey every N bytes, it is responsible for
handling that in ra_read(). (I.e., Fortuna's 1MB rekey interval for AES
block generation.)
  
2. If an algorithm uses a block cipher that doesn't tolerate partial-block
requests (again, e.g., AES), it is also responsible for handling that in
ra_read().
  
  Several APIs are changed from u_int buffer length to the more canonical
  size_t.  Several APIs are changed from taking a blockcount to a bytecount,
  to permit PRFs like Chacha20 to directly generate quantities of output that
  are not multiples of RANDOM_BLOCKSIZE (AES block size).
  
  The Fortuna algorithm is changed to NOT rekey every 1MiB when in Chacha20
  mode (kern.random.use_chacha20_cipher="1").  This is explicitly supported by
  the math in FS §9.4 (Ferguson, Schneier, and Kohno; "Cryptography
  Engineering"), as well as by their conclusion: "If we had a block cipher
  with a 256-bit [or greater] block size, then the collisions would not
  have been an issue at all."
  
  For now, continue to break up reads into PAGE_SIZE chunks, as they were
  before.  So, no functional change, mostly.
  
  Reviewed by:  markm
  Approved by:  secteam(delphij)
  Differential Revision:https://reviews.freebsd.org/D20312

Modified:
  head/sys/dev/random/fortuna.c
  head/sys/dev/random/hash.c
  head/sys/dev/random/hash.h
  head/sys/dev/random/other_algorithm.c
  head/sys/dev/random/randomdev.c
  head/sys/dev/random/randomdev.h
  head/tests/sys/devrandom/uint128_test.c

Modified: head/sys/dev/random/fortuna.c
==
--- head/sys/dev/random/fortuna.c   Mon Jun 17 14:59:45 2019
(r349137)
+++ head/sys/dev/random/fortuna.c   Mon Jun 17 15:09:12 2019
(r349138)
@@ -128,7 +128,7 @@ static uint8_t zero_region[RANDOM_ZERO_BLOCKSIZE];
 #endif
 
 static void random_fortuna_pre_read(void);
-static void random_fortuna_read(uint8_t *, u_int);
+static void random_fortuna_read(uint8_t *, size_t);
 static bool random_fortuna_seeded(void);
 static bool random_fortuna_seeded_internal(void);
 static void random_fortuna_process_event(struct harvest_event *);
@@ -306,49 +306,45 @@ random_fortuna_reseed_internal(uint32_t *entropy_data,
 }
 
 /*-
- * FS - GenerateBlocks()
- * Generate a number of complete blocks of random output.
- */
-static __inline void
-random_fortuna_genblocks(uint8_t *buf, u_int blockcount)
-{
-
-   RANDOM_RESEED_ASSERT_LOCK_OWNED();
-   KASSERT(!uint128_is_zero(fortuna_state.fs_counter), ("FS: C != 0"));
-
-   /*
-* Fills buf with RANDOM_BLOCKSIZE * blockcount bytes of keystream.
-* Increments fs_counter as it goes.
-*/
-   randomdev_keystream(_state.fs_key, _state.fs_counter,
-   buf, blockcount);
-}
-
-/*-
  * FS - PseudoRandomData()
- * This generates no more than 2^20 bytes of data, and cleans up its
- * internal state when finished. It is assumed that a whole number of
- * blocks are available for writing; any excess generated will be
- * ignored.
+ *
+ * If Chacha20 is used, output size is unrestricted.  If AES-CTR is used,
+ * output size MUST be <= 1MB and a multiple of RANDOM_BLOCKSIZE.  The
+ * reasoning for this is discussed in FS 9.4; the significant distinction
+ * between the two ciphers is that AES has a *block* size of 128 bits while
+ * Chacha has a *block* size of 512 bits.
  */
 static __inline void
-random_fortuna_genrandom(uint8_t *buf, u_int bytecount)
+random_fortuna_genrandom(uint8_t *buf, size_t bytecount)
 {
-   uint8_t temp[RANDOM_BLOCKSIZE * RANDOM_KEYS_PER_BLOCK];
-   u_int blockcount;
+   uint8_t newkey[RANDOM_KEYSIZE];
 
RANDOM_RESEED_ASSERT_LOCK_OWNED();
+
/*-
-* FS - assert(n < 2^20 (== 1 MB)
+* FS - 

svn commit: r349154 - in head: sys/dev/random tests/sys/devrandom

2019-06-17 Thread Conrad Meyer
Author: cem
Date: Mon Jun 17 20:29:13 2019
New Revision: 349154
URL: https://svnweb.freebsd.org/changeset/base/349154

Log:
  random(4): Fortuna: allow increased concurrency
  
  Add experimental feature to increase concurrency in Fortuna.  As this
  diverges slightly from canonical Fortuna, and due to the security
  sensitivity of random(4), it is off by default.  To enable it, set the
  tunable kern.random.fortuna.concurrent_read="1".  The rest of this commit
  message describes the behavior when enabled.
  
  Readers continue to update shared Fortuna state under global mutex, as they
  do in the status quo implementation of the algorithm, but shift the actual
  PRF generation out from under the global lock.  This massively reduces the
  CPU time readers spend holding the global lock, allowing for increased
  concurrency on SMP systems and less bullying of the harvestq kthread.
  
  It is somewhat of a deviation from FS  I think the primary difference is
  that the specific sequence of AES keys will differ if READ_RANDOM_UIO is
  accessed concurrently (as the 2nd thread to take the mutex will no longer
  receive a key derived from rekeying the first thread).  However, I believe
  the goals of rekeying AES are maintained: trivially, we continue to rekey
  every 1MB for the statistical property; and each consumer gets a
  forward-secret, independent AES key for their PRF.
  
  Since Chacha doesn't need to rekey for sequences of any length, this change
  makes no difference to the sequence of Chacha keys and PRF generated when
  Chacha is used in place of AES.
  
  On a GENERIC 4-thread VM (so, INVARIANTS/WITNESS, numbers not necessarily
  representative), 3x concurrent AES performance jumped from ~55 MiB/s per
  thread to ~197 MB/s per thread.  Concurrent Chacha20 at 3 threads went from
  roughly ~113 MB/s per thread to ~430 MB/s per thread.
  
  Prior to this change, the system was extremely unresponsive with 3-4
  concurrent random readers; each thread had high variance in latency and
  throughput, depending on who got lucky and won the lock.  "rand_harvestq"
  thread CPU use was high (double digits), seemingly due to spinning on the
  global lock.
  
  After the change, concurrent random readers and the system in general are
  much more responsive, and rand_harvestq CPU use dropped to basically zero.
  
  Tests are added to the devrandom suite to ensure the uint128_add64 primitive
  utilized by unlocked read functions to specification.
  
  Reviewed by:  markm
  Approved by:  secteam(delphij)
  Relnotes: yes
  Differential Revision:https://reviews.freebsd.org/D20313

Modified:
  head/sys/dev/random/fortuna.c
  head/sys/dev/random/fortuna.h
  head/sys/dev/random/hash.c
  head/sys/dev/random/hash.h
  head/sys/dev/random/uint128.h
  head/tests/sys/devrandom/uint128_test.c

Modified: head/sys/dev/random/fortuna.c
==
--- head/sys/dev/random/fortuna.c   Mon Jun 17 20:11:02 2019
(r349153)
+++ head/sys/dev/random/fortuna.c   Mon Jun 17 20:29:13 2019
(r349154)
@@ -61,6 +61,7 @@ __FBSDID("$FreeBSD$");
 #include "unit_test.h"
 #endif /* _KERNEL */
 
+#include 
 #include 
 #include 
 
@@ -75,7 +76,10 @@ __FBSDID("$FreeBSD$");
 /* Defined in FS */
 #defineRANDOM_FORTUNA_NPOOLS 32/* The number of 
accumulation pools */
 #defineRANDOM_FORTUNA_DEFPOOLSIZE 64   /* The default pool 
size/length for a (re)seed */
-#defineRANDOM_FORTUNA_MAX_READ (1 << 20)   /* Max bytes in a 
single read */
+#defineRANDOM_FORTUNA_MAX_READ (1 << 20)   /* Max bytes from AES 
before rekeying */
+#defineRANDOM_FORTUNA_BLOCKS_PER_KEY (1 << 16) /* Max blocks from AES 
before rekeying */
+CTASSERT(RANDOM_FORTUNA_BLOCKS_PER_KEY * RANDOM_BLOCKSIZE ==
+RANDOM_FORTUNA_MAX_READ);
 
 /*
  * The allowable range of RANDOM_FORTUNA_DEFPOOLSIZE. The default value is 
above.
@@ -120,6 +124,26 @@ static struct fortuna_state {
mtx_t fs_mtx;
 } fortuna_state;
 
+/*
+ * Experimental concurrent reads feature.  For now, disabled by default.  But
+ * we may enable it in the future.
+ *
+ * The benefit is improved concurrency in Fortuna.  That is reflected in two
+ * related aspects:
+ *
+ * 1. Concurrent devrandom readers can achieve similar throughput to a single
+ *reader thread.
+ *
+ * 2. The rand_harvestq process spends much less time spinning when one or more
+ *readers is processing a large request.  Partially this is due to
+ *rand_harvestq / ra_event_processor design, which only passes one event at
+ *a time to the underlying algorithm.  Each time, Fortuna must take its
+ *global state mutex, potentially blocking on a reader.  Our adaptive
+ *mutexes assume that a lock holder currently on CPU will release the lock
+ *quickly, and spin if the owning thread is currently running.
+ */
+static bool fortuna_concurrent_read __read_frequently 

svn commit: r349176 - head/sys/dev/random

2019-06-18 Thread Conrad Meyer
Author: cem
Date: Tue Jun 18 18:50:58 2019
New Revision: 349176
URL: https://svnweb.freebsd.org/changeset/base/349176

Log:
  random(4): Fix a regression in short AES mode reads
  
  In r349154, random device reads of size < 16 bytes (AES block size) were
  accidentally broken to loop forever.  Correct the loop condition for small
  reads.
  
  Reported by:  pho
  Reviewed by:  delphij
  Approved by:  secteam(delphij)
  Differential Revision:https://reviews.freebsd.org/D20686

Modified:
  head/sys/dev/random/fortuna.c

Modified: head/sys/dev/random/fortuna.c
==
--- head/sys/dev/random/fortuna.c   Tue Jun 18 17:51:30 2019
(r349175)
+++ head/sys/dev/random/fortuna.c   Tue Jun 18 18:50:58 2019
(r349176)
@@ -489,7 +489,7 @@ random_fortuna_genbytes(uint8_t *buf, size_t bytecount
if (!random_chachamode)
chunk_size = rounddown(chunk_size, RANDOM_BLOCKSIZE);
 
-   while (bytecount >= chunk_size) {
+   while (bytecount >= chunk_size && chunk_size > 0) {
randomdev_keystream(p_key, p_counter, buf, chunk_size);
 
buf += chunk_size;
___
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: r348847 - head/sys/sys

2019-06-10 Thread Conrad Meyer
Hi Warner,

That doesn't seem responsive to the question.

On Mon, Jun 10, 2019 at 6:49 AM Warner Losh  wrote:
>
>
>
> On Mon, Jun 10, 2019, 7:44 AM Conrad Meyer  wrote:
>>
>> On Mon, Jun 10, 2019 at 2:10 AM Tijl Coosemans  wrote:
>> > On Mon, 10 Jun 2019 05:28:04 + (UTC) Dmitry Chagin
>> >  wrote:
>> > > ...
>> > > URL: https://svnweb.freebsd.org/changeset/base/348847
>> > > Log:
>> > >   Use C11 anonymous unions.
>> > >
>> > > Modified: head/sys/sys/ucred.h
>> > ...
>> >
>> > Isn't this a userland header that should work with non-C11 compilers?
>>
>> Hi Tijl,
>>
>> Why would one expect userland headers to work with non-C11 (gnu89) compilers?
>
>
> Because those compilers can choose non c11 variants of the language?
>
> 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"


svn commit: r349254 - head

2019-06-20 Thread Conrad Meyer
Author: cem
Date: Fri Jun 21 00:33:45 2019
New Revision: 349254
URL: https://svnweb.freebsd.org/changeset/base/349254

Log:
  Fixup UPDATING text for r349253
  
  Requested by: delphij

Modified:
  head/UPDATING

Modified: head/UPDATING
==
--- head/UPDATING   Fri Jun 21 00:16:30 2019(r349253)
+++ head/UPDATING   Fri Jun 21 00:33:45 2019(r349254)
@@ -32,8 +32,8 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
 
 20190620:
-   The "device random" option has been removed.  Entropy collection and
-   the /dev/random device are no longer an optional component.
+   Entropy collection and the /dev/random device are no longer optional
+   components.  The "device random" option has been removed.
Implementations of distilling algorithms can still be made loadable
with "options RANDOM_LOADABLE" (e.g., random_fortuna.ko).
 
___
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: r349256 - head/libexec/rc/rc.d

2019-06-20 Thread Conrad Meyer
Author: cem
Date: Fri Jun 21 02:37:54 2019
New Revision: 349256
URL: https://svnweb.freebsd.org/changeset/base/349256

Log:
  rc.d/motd: Update motd more robustly
  
  Use appropriate fsyncs to persist the rewritten /etc/motd file, when a
  rewrite is performed.
  
  Reported by:  Jonathan Walton 
  Reviewed by:  allanjude, vangyzen
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D20701

Modified:
  head/libexec/rc/rc.d/motd

Modified: head/libexec/rc/rc.d/motd
==
--- head/libexec/rc/rc.d/motd   Fri Jun 21 00:52:30 2019(r349255)
+++ head/libexec/rc/rc.d/motd   Fri Jun 21 02:37:54 2019(r349256)
@@ -37,11 +37,15 @@ motd_start()
uname -v | sed -e 's,^\([^#]*\) #\(.* 
[1-2][0-9][0-9][0-9]\).*/\([^\]*\) $,\1 (\3) #\2,' > ${T}
awk '{if (NR == 1) {if ($1 == "FreeBSD") {next} else {print "\n"$0}} 
else {print}}' < /etc/motd >> ${T}
 
-   cmp -s $T /etc/motd || {
-   cp $T /etc/motd
+   if ! cmp -s $T /etc/motd; then
+   mv -f $T /etc/.motd.tmp
+   fsync /etc/.motd.tmp
+   mv -f /etc/.motd.tmp /etc/motd
chmod ${PERMS} /etc/motd
-   }
-   rm -f $T
+   fsync /etc
+   else
+   rm -f $T
+   fi
 
check_startmsgs && 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"


svn commit: r349253 - in head: . release/picobsd/bridge release/picobsd/qemu share/man/man4 sys/amd64/conf sys/arm/conf sys/arm64/conf sys/conf sys/i386/conf sys/mips/conf sys/mips/mediatek sys/pow...

2019-06-20 Thread Conrad Meyer
Author: cem
Date: Fri Jun 21 00:16:30 2019
New Revision: 349253
URL: https://svnweb.freebsd.org/changeset/base/349253

Log:
  sys: Remove DEV_RANDOM device option
  
  Remove 'device random' from kernel configurations that reference it (most).
  Replace perhaps mistaken 'nodevice random' in two MIPS configs with 'options
  RANDOM_LOADABLE' instead.  Document removal in UPDATING; update NOTES and
  random.4.
  
  Reviewed by:  delphij, markm (previous version)
  Approved by:  secteam(delphij)
  Differential Revision:https://reviews.freebsd.org/D19918

Modified:
  head/UPDATING
  head/release/picobsd/bridge/PICOBSD
  head/release/picobsd/qemu/PICOBSD
  head/share/man/man4/random.4
  head/sys/amd64/conf/GENERIC
  head/sys/amd64/conf/MINIMAL
  head/sys/arm/conf/ALPINE
  head/sys/arm/conf/ARMADA38X
  head/sys/arm/conf/ARMADAXP
  head/sys/arm/conf/DB-78XXX
  head/sys/arm/conf/DB-88F5XXX
  head/sys/arm/conf/DB-88F6XXX
  head/sys/arm/conf/DOCKSTAR
  head/sys/arm/conf/DREAMPLUG-1001
  head/sys/arm/conf/EFIKA_MX
  head/sys/arm/conf/GENERIC
  head/sys/arm/conf/IMX53
  head/sys/arm/conf/IMX6
  head/sys/arm/conf/RPI-B
  head/sys/arm/conf/RT1310
  head/sys/arm/conf/SHEEVAPLUG
  head/sys/arm/conf/SOCFPGA
  head/sys/arm/conf/TEGRA124
  head/sys/arm/conf/TS7800
  head/sys/arm/conf/VERSATILEPB
  head/sys/arm/conf/VYBRID
  head/sys/arm/conf/ZEDBOARD
  head/sys/arm64/conf/GENERIC
  head/sys/conf/NOTES
  head/sys/conf/files
  head/sys/conf/files.arm64
  head/sys/conf/files.powerpc
  head/sys/conf/options
  head/sys/i386/conf/GENERIC
  head/sys/i386/conf/MINIMAL
  head/sys/mips/conf/BCM
  head/sys/mips/conf/DIR-825B1
  head/sys/mips/conf/ERL
  head/sys/mips/conf/JZ4780
  head/sys/mips/conf/OCTEON1
  head/sys/mips/conf/PB92
  head/sys/mips/conf/PICOSTATION_M2HP
  head/sys/mips/conf/WZR-300HP
  head/sys/mips/conf/WZR-HPAG300H
  head/sys/mips/conf/X1000
  head/sys/mips/conf/std.AR5312
  head/sys/mips/conf/std.AR5315
  head/sys/mips/conf/std.AR_MIPS_BASE
  head/sys/mips/conf/std.BERI
  head/sys/mips/conf/std.MALTA
  head/sys/mips/conf/std.XLP
  head/sys/mips/mediatek/std.mediatek
  head/sys/mips/mediatek/std.rt2880
  head/sys/powerpc/conf/GENERIC
  head/sys/powerpc/conf/GENERIC64
  head/sys/powerpc/conf/MPC85XX
  head/sys/powerpc/conf/MPC85XXSPE
  head/sys/powerpc/conf/QORIQ64
  head/sys/powerpc/conf/dpaa/DPAA
  head/sys/riscv/conf/GENERIC
  head/sys/sparc64/conf/GENERIC
  head/sys/sys/random.h
  head/tools/tools/nanobsd/pcengines/ALIX_DSK
  head/tools/tools/tinybsd/conf/bridge/TINYBSD
  head/tools/tools/tinybsd/conf/default/TINYBSD
  head/tools/tools/tinybsd/conf/firewall/TINYBSD
  head/tools/tools/tinybsd/conf/minimal/TINYBSD
  head/tools/tools/tinybsd/conf/vpn/TINYBSD
  head/tools/tools/tinybsd/conf/wireless/TINYBSD
  head/tools/tools/tinybsd/conf/wrap/TINYBSD

Modified: head/UPDATING
==
--- head/UPDATING   Fri Jun 21 00:01:12 2019(r349252)
+++ head/UPDATING   Fri Jun 21 00:16:30 2019(r349253)
@@ -31,6 +31,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
disable the most expensive debugging functionality run
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
 
+20190620:
+   The "device random" option has been removed.  Entropy collection and
+   the /dev/random device are no longer an optional component.
+   Implementations of distilling algorithms can still be made loadable
+   with "options RANDOM_LOADABLE" (e.g., random_fortuna.ko).
+
 20190612:
Clang, llvm, lld, lldb, compiler-rt, libc++, libunwind and openmp have
been upgraded to 8.0.1.  Please see the 20141231 entry below for

Modified: head/release/picobsd/bridge/PICOBSD
==
--- head/release/picobsd/bridge/PICOBSD Fri Jun 21 00:01:12 2019
(r349252)
+++ head/release/picobsd/bridge/PICOBSD Fri Jun 21 00:16:30 2019
(r349253)
@@ -50,7 +50,6 @@ deviceif_bridge
 # qemu, so we set HZ explicitly.
 optionsHZ=1000
 
-device random  # used by ssh
 device pci
 
 # Floppy drives

Modified: head/release/picobsd/qemu/PICOBSD
==
--- head/release/picobsd/qemu/PICOBSD   Fri Jun 21 00:01:12 2019
(r349252)
+++ head/release/picobsd/qemu/PICOBSD   Fri Jun 21 00:16:30 2019
(r349253)
@@ -56,7 +56,6 @@ deviceif_bridge
 # qemu, so we set HZ explicitly.
 optionsHZ=1000
 
-device random  # used by ssh
 device pci
 
 # Floppy drives

Modified: head/share/man/man4/random.4
==
--- head/share/man/man4/random.4Fri Jun 21 00:01:12 2019
(r349252)
+++ head/share/man/man4/random.4Fri Jun 21 00:16:30 2019
(r349253)
@@ -30,7 +30,6 @@
 

Re: svn commit: r349151 - in head: lib/libufs stand/libsa sys/conf sys/dev/iscsi sys/dev/iscsi_initiator sys/dev/liquidio sys/dev/usb/net sys/fs/ext2fs sys/fs/nandfs sys/geom/part sys/geom/raid sys/ke

2019-06-22 Thread Conrad Meyer
Hi Xin Li,

On Mon, Jun 17, 2019 at 12:49 PM Xin LI  wrote:
>
> Author: delphij
> Date: Mon Jun 17 19:49:08 2019
> New Revision: 349151
> URL: https://svnweb.freebsd.org/changeset/base/349151
>
> Log:
>   Separate kernel crc32() implementation to its own header (gsb_crc32.h) and
>   rename the source to gsb_crc32.c.
>
>   This is a prerequisite of unifying kernel zlib instances.
>
>...
> Modified: head/sys/libkern/x86/crc32_sse42.c
> ==
> --- head/sys/libkern/x86/crc32_sse42.c  Mon Jun 17 17:35:55 2019
> (r349150)
> +++ head/sys/libkern/x86/crc32_sse42.c  Mon Jun 17 19:49:08 2019
> (r349151)
> @@ -29,14 +29,14 @@ __FBSDID("$FreeBSD$");
>  /*
>   * This file is compiled in userspace in order to run ATF unit tests.
>   */
> -#ifdef USERSPACE_TESTING
> +#ifndef _KERNEL

This change and following identical changes revert a request by kib@
in https://reviews.freebsd.org/D9342 .  (When this revision was
initially proposed in  , it was '#ifndef _KERNEL' — kib@ requested the
use of a different preprocessor macro.)

Cheers,
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: r348854 - head/libexec/rc/rc.d

2019-06-10 Thread Conrad Meyer
Author: cem
Date: Mon Jun 10 13:34:18 2019
New Revision: 348854
URL: https://svnweb.freebsd.org/changeset/base/348854

Log:
  /etc/rc.d/local: Fix typo in description
  
  PR:   238448
  Submitted by: Marián Černý 

Modified:
  head/libexec/rc/rc.d/local

Modified: head/libexec/rc/rc.d/local
==
--- head/libexec/rc/rc.d/local  Mon Jun 10 13:17:39 2019(r348853)
+++ head/libexec/rc/rc.d/local  Mon Jun 10 13:34:18 2019(r348854)
@@ -11,7 +11,7 @@
 . /etc/rc.subr
 
 name="local"
-desc="Run /etc/rc.local and /etc/shutdown.local"
+desc="Run /etc/rc.local and /etc/rc.shutdown.local"
 start_cmd="local_start"
 stop_cmd="local_stop"
 
___
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: r348847 - head/sys/sys

2019-06-10 Thread Conrad Meyer
On Mon, Jun 10, 2019 at 2:10 AM Tijl Coosemans  wrote:
> On Mon, 10 Jun 2019 05:28:04 + (UTC) Dmitry Chagin
>  wrote:
> > ...
> > URL: https://svnweb.freebsd.org/changeset/base/348847
> > Log:
> >   Use C11 anonymous unions.
> >
> > Modified: head/sys/sys/ucred.h
> ...
>
> Isn't this a userland header that should work with non-C11 compilers?

Hi Tijl,

Why would one expect userland headers to work with non-C11 (gnu89) compilers?

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: r348847 - head/sys/sys

2019-06-10 Thread Conrad Meyer
On Mon, Jun 10, 2019 at 9:17 AM Bruce Evans  wrote:
> Only headers and libraries should support -std=c89.   has
> lots of support for compilers and POSIX versions going back to K C,
> and only the K parts are completely broken.

Is this due to specific policy, or just inertia?  (No one has bothered
to remove the old bits?)  The older parts being totally broken
suggests sheer inertia.

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: r347473 - head/sys/netinet/netdump

2019-05-10 Thread Conrad Meyer
Author: cem
Date: Fri May 10 23:12:59 2019
New Revision: 347473
URL: https://svnweb.freebsd.org/changeset/base/347473

Log:
  netdump: Ref the interface we're attached to
  
  Serialize netdump configuration / deconfiguration, and discard our
  configuration when the affiliated interface goes away by monitoring
  ifnet_departure_event.
  
  Reviewed by:  markj, with input from vangyzen@ (earlier version)
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D20206

Modified:
  head/sys/netinet/netdump/netdump_client.c

Modified: head/sys/netinet/netdump/netdump_client.c
==
--- head/sys/netinet/netdump/netdump_client.c   Fri May 10 23:12:37 2019
(r347472)
+++ head/sys/netinet/netdump/netdump_client.c   Fri May 10 23:12:59 2019
(r347473)
@@ -93,6 +93,8 @@ static int netdump_configure(struct diocskerneldump_a
struct thread *);
 static int  netdump_dumper(void *priv __unused, void *virtual,
vm_offset_t physical __unused, off_t offset, size_t length);
+static bool netdump_enabled(void);
+static int  netdump_enabled_sysctl(SYSCTL_HANDLER_ARGS);
 static int  netdump_ether_output(struct mbuf *m, struct ifnet *ifp,
struct ether_addr dst, u_short etype);
 static void netdump_handle_arp(struct mbuf **mb);
@@ -102,11 +104,13 @@ static int netdump_ioctl(struct cdev *dev 
__unused, u
 static int  netdump_modevent(module_t mod, int type, void *priv);
 static void netdump_network_poll(void);
 static void netdump_pkt_in(struct ifnet *ifp, struct mbuf *m);
+static void netdump_reinit_internal(struct ifnet *ifp);
 static int  netdump_send(uint32_t type, off_t offset, unsigned char *data,
uint32_t datalen);
 static int  netdump_send_arp(in_addr_t dst);
 static int  netdump_start(struct dumperinfo *di);
 static int  netdump_udp_output(struct mbuf *m);
+static void netdump_unconfigure(void);
 
 /* Must be at least as big as the chunks dumpsys() gives us. */
 static unsigned char nd_buf[MAXDUMPPGS * PAGE_SIZE];
@@ -131,8 +135,17 @@ static struct {
 #definend_gateway  nd_conf.ndc_gateway.in4
 
 /* General dynamic settings. */
+static struct sx nd_conf_lk;
+SX_SYSINIT(nd_conf, _conf_lk, "netdump configuration lock");
+#define NETDUMP_WLOCK()sx_xlock(_conf_lk)
+#define NETDUMP_WUNLOCK()  sx_xunlock(_conf_lk)
+#define NETDUMP_RLOCK()sx_slock(_conf_lk)
+#define NETDUMP_RUNLOCK()  sx_sunlock(_conf_lk)
+#define NETDUMP_ASSERT_WLOCKED()   sx_assert(_conf_lk, SA_XLOCKED)
+#define NETDUMP_ASSERT_LOCKED()sx_assert(_conf_lk, 
SA_LOCKED)
 static struct ether_addr nd_gw_mac;
 static struct ifnet *nd_ifp;
+static eventhandler_tag nd_detach_cookie;
 static uint16_t nd_server_port = NETDUMP_PORT;
 
 FEATURE(netdump, "Netdump client support");
@@ -144,10 +157,8 @@ static int nd_debug;
 SYSCTL_INT(_net_netdump, OID_AUTO, debug, CTLFLAG_RWTUN,
 _debug, 0,
 "Debug message verbosity");
-static int nd_enabled;
-SYSCTL_INT(_net_netdump, OID_AUTO, enabled, CTLFLAG_RD,
-_enabled, 0,
-"netdump configuration status");
+SYSCTL_PROC(_net_netdump, OID_AUTO, enabled, CTLFLAG_RD | CTLTYPE_INT,
+_ifp, 0, netdump_enabled_sysctl, "I", "netdump configuration status");
 static char nd_path[MAXPATHLEN];
 SYSCTL_STRING(_net_netdump, OID_AUTO, path, CTLFLAG_RW,
 nd_path, sizeof(nd_path),
@@ -165,6 +176,29 @@ SYSCTL_INT(_net_netdump, OID_AUTO, arp_retries, CTLFLA
 _arp_retries, 0,
 "Number of ARP attempts before giving up");
 
+static bool
+netdump_enabled(void)
+{
+
+   NETDUMP_ASSERT_LOCKED();
+   return (nd_ifp != NULL);
+}
+
+static int
+netdump_enabled_sysctl(SYSCTL_HANDLER_ARGS)
+{
+   int en, error;
+
+   NETDUMP_RLOCK();
+   en = netdump_enabled();
+   NETDUMP_RUNLOCK();
+
+   error = SYSCTL_OUT(req, , sizeof(en));
+   if (error != 0 || req->newptr == NULL)
+   return (error);
+   return (EPERM);
+}
+
 /*
  * Checks for netdump support on a network interface
  *
@@ -248,7 +282,7 @@ netdump_udp_output(struct mbuf *m)
struct udpiphdr *ui;
struct ip *ip;
 
-   MPASS(nd_ifp != NULL);
+   MPASS(netdump_enabled());
 
M_PREPEND(m, sizeof(struct udpiphdr), M_NOWAIT);
if (m == NULL) {
@@ -306,7 +340,7 @@ netdump_send_arp(in_addr_t dst)
struct arphdr *ah;
int pktlen;
 
-   MPASS(nd_ifp != NULL);
+   MPASS(netdump_enabled());
 
/* Fill-up a broadcast address. */
memset(, 0xFF, ETHER_ADDR_LEN);
@@ -409,7 +443,7 @@ netdump_send(uint32_t type, off_t offset, unsigned cha
rcvd_acks = 0;
retries = 0;
 
-   MPASS(nd_ifp != NULL);
+   MPASS(netdump_enabled());
 
 retransmit:
/* Chunks can be too big to fit in 

svn commit: r347471 - head/sys/netinet/netdump

2019-05-10 Thread Conrad Meyer
Author: cem
Date: Fri May 10 23:10:22 2019
New Revision: 347471
URL: https://svnweb.freebsd.org/changeset/base/347471

Log:
  netdump: Fix boot-time configuration typo
  
  Boot-time netdump configuration is much more useful if one can configure the
  client and gateway addresses.  Fix trivial typo.
  
  (Long-standing bug, I believe it dates to the original netdump commit.)
  
  Spotted by:   one of vangyzen@ or markj@
  Sponsored by: Dell EMC Isilon

Modified:
  head/sys/netinet/netdump/netdump_client.c

Modified: head/sys/netinet/netdump/netdump_client.c
==
--- head/sys/netinet/netdump/netdump_client.c   Fri May 10 23:10:22 2019
(r347470)
+++ head/sys/netinet/netdump/netdump_client.c   Fri May 10 23:10:22 2019
(r347471)
@@ -1394,11 +1394,11 @@ netdump_modevent(module_t mod __unused, int what, void
freeenv(arg);
}
if ((arg = kern_getenv("net.dump.client")) != NULL) {
-   inet_aton(arg, _server.in4);
+   inet_aton(arg, _client.in4);
freeenv(arg);
}
if ((arg = kern_getenv("net.dump.gateway")) != NULL) {
-   inet_aton(arg, _server.in4);
+   inet_aton(arg, _gateway.in4);
freeenv(arg);
}
conf.kda_af = AF_INET;
___
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: r347467 - head/sys/netinet/netdump

2019-05-10 Thread Conrad Meyer
Author: cem
Date: Fri May 10 21:55:11 2019
New Revision: 347467
URL: https://svnweb.freebsd.org/changeset/base/347467

Log:
  netdump: Don't store sensitive key data we don't need
  
  Prior to this revision, struct diocskerneldump_arg (and struct netdump_conf
  with embedded diocskerneldump_arg before r347192), were copied in their
  entirety to the global 'nd_conf' variable.  Also prior to this revision,
  de-configuring netdump would *not* remove the the key material from global
  nd_conf.
  
  As part of Encrypted Kernel Crash Dumps (EKCD), which was developed
  contemporaneously with netdump but happened to land first, the
  diocskerneldump_arg structure will contain sensitive key material
  (kda_key[]) when encrypted dumps are configured.
  
  Netdump doesn't have any use for the key data -- encryption is handled in
  the core dumper code -- so in this revision, we no longer store it.
  
  Unfortunately, I think this leak dates to the initial import of netdump in
  r333283; so it's present in FreeBSD 12.0.
  
  Fortunately, the impact *seems* relatively minor.  Any new *netdump*
  configuration would overwrite the key material; for active encrypted netdump
  configurations, the key data stored was just a duplicate of the key material
  already in the core dumper code; and no user interface (other than
  /dev/kmem) actually exposed the leaked material to userspace.
  
  Reviewed by:  markj, rpokala (earlier commit message)
  MFC after:2 weeks
  Security: yes (minor)
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D20233

Modified:
  head/sys/netinet/netdump/netdump_client.c

Modified: head/sys/netinet/netdump/netdump_client.c
==
--- head/sys/netinet/netdump/netdump_client.c   Fri May 10 21:51:17 2019
(r347466)
+++ head/sys/netinet/netdump/netdump_client.c   Fri May 10 21:55:11 2019
(r347467)
@@ -119,10 +119,16 @@ static uint64_t rcvd_acks;
 CTASSERT(sizeof(rcvd_acks) * NBBY == NETDUMP_MAX_IN_FLIGHT);
 
 /* Configuration parameters. */
-static struct diocskerneldump_arg nd_conf;
-#definend_server   nd_conf.kda_server.in4
-#definend_client   nd_conf.kda_client.in4
-#definend_gateway  nd_conf.kda_gateway.in4
+static struct {
+   char ndc_iface[IFNAMSIZ];
+   union kd_ip  ndc_server;
+   union kd_ip  ndc_client;
+   union kd_ip  ndc_gateway;
+   uint8_t  ndc_af;
+} nd_conf;
+#definend_server   nd_conf.ndc_server.in4
+#definend_client   nd_conf.ndc_client.in4
+#definend_gateway  nd_conf.ndc_gateway.in4
 
 /* General dynamic settings. */
 static struct ether_addr nd_gw_mac;
@@ -1087,8 +1093,20 @@ netdump_configure(struct diocskerneldump_arg *conf, st
return (ENODEV);
 
nd_ifp = ifp;
+
netdump_reinit(ifp);
-   memcpy(_conf, conf, sizeof(nd_conf));
+#define COPY_SIZED(elm) do {   \
+   _Static_assert(sizeof(nd_conf.ndc_ ## elm) ==   \
+   sizeof(conf->kda_ ## elm), "elm " __XSTRING(elm) " mismatch"); \
+   memcpy(_conf.ndc_ ## elm, >kda_ ## elm,\
+   sizeof(nd_conf.ndc_ ## elm));   \
+} while (0)
+   COPY_SIZED(iface);
+   COPY_SIZED(server);
+   COPY_SIZED(client);
+   COPY_SIZED(gateway);
+   COPY_SIZED(af);
+#undef COPY_SIZED
nd_enabled = 1;
return (0);
 }
@@ -1193,7 +1211,7 @@ netdump_ioctl(struct cdev *dev __unused, u_long cmd, c
error = ENXIO;
break;
}
-   if (nd_conf.kda_af != AF_INET) {
+   if (nd_conf.ndc_af != AF_INET) {
error = EOPNOTSUPP;
break;
}
@@ -1225,7 +1243,7 @@ netdump_ioctl(struct cdev *dev __unused, u_long cmd, c
memcpy(>kda_server, _server, sizeof(nd_server));
memcpy(>kda_client, _client, sizeof(nd_client));
memcpy(>kda_gateway, _gateway, sizeof(nd_gateway));
-   conf->kda_af = nd_conf.kda_af;
+   conf->kda_af = nd_conf.ndc_af;
conf = NULL;
break;
 
@@ -1397,7 +1415,7 @@ netdump_modevent(module_t mod __unused, int what, void
 
bzero(, sizeof(kda));
kda.kda_index = KDA_REMOVE_DEV;
-   (void)dumper_remove(nd_conf.kda_iface, );
+   (void)dumper_remove(nd_conf.ndc_iface, );
 
netdump_mbuf_drain();
nd_enabled = 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: r347546 - head/sys/dev/random

2019-05-13 Thread Conrad Meyer
Author: cem
Date: Mon May 13 19:35:35 2019
New Revision: 347546
URL: https://svnweb.freebsd.org/changeset/base/347546

Log:
  Fortuna: Fix false negatives in is_random_seeded()
  
  (1) We may have had sufficient entropy to consider Fortuna seeded, but the
  random_fortuna_seeded() function would produce a false negative if
  fs_counter was still zero.  This condition could arise after
  random_harvestq_prime() processed the /boot/entropy file and before any
  read-type operation invoked "pre_read()."  Fortuna's fs_counter variable is
  only incremented (if certain conditions are met) by reseeding, which is
  invoked by random_fortuna_pre_read().
  
  is_random_seeded(9) was introduced in r346282, but the function was unused
  prior to r346358, which introduced this regression.  The regression broke
  initial seeding of arc4random(9) and broke periodic reseeding[A], until 
something
  other than arc4random(9) invoked read_random(9) or read_random_uio(9) 
directly.
  (Such as userspace getrandom(2) or read(2) of /dev/random.  By default,
  /etc/rc.d/random does this during multiuser start-up.)
  
  (2) The conditions under which Fortuna will reseed (including initial seeding)
  are: (a) sufficient "entropy" (by sheer byte count; default 64) is collected
  in the zeroth pool (of 32 pools), and (b) it has been at least 100ms since
  the last reseed (to prevent trivial DoS; part of FS design).  Prior to
  this revision, initial seeding might have been prevented if the reseed
  function was invoked during the first 100ms of boot.
  
  This revision addresses both of these issues.  If random_fortuna_seeded()
  observes a zero fs_counter, it invokes random_fortuna_pre_read() and checks
  again.  This addresses the problem where entropy actually was sufficient,
  but nothing had attempted a read -> pre_read yet.
  
  The second change is to disable the 100ms reseed guard when Fortuna has
  never been seeded yet (fs_lasttime == 0).  The guard is intended to prevent
  gratuitous subsequent reseeds, not initial seeding!
  
  Machines running CURRENT between r346358 and this revision are encouraged to
  refresh when possible.  Keys generated by userspace with /dev/random or
  getrandom(9) during this timeframe are safe, but any long-term session keys
  generated by kernel arc4random consumers are potentially suspect.
  
  [A]: Broken in the sense that is_random_seeded(9) false negatives would cause
  arc4random(9) to (re-)seed with weak entropy (SHA256(cyclecount ||
  FreeBSD_version)).
  
  PR:   237869
  Reported by:  delphij, dim
  Reviewed by:  delphij
  Approved by:  secteam(delphij)
  X-MFC-With:   r346282, r346358 (if ever)
  Security: yes
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D20239

Modified:
  head/sys/dev/random/fortuna.c

Modified: head/sys/dev/random/fortuna.c
==
--- head/sys/dev/random/fortuna.c   Mon May 13 19:31:09 2019
(r347545)
+++ head/sys/dev/random/fortuna.c   Mon May 13 19:35:35 2019
(r347546)
@@ -130,6 +130,7 @@ static uint8_t zero_region[RANDOM_ZERO_BLOCKSIZE];
 static void random_fortuna_pre_read(void);
 static void random_fortuna_read(uint8_t *, u_int);
 static bool random_fortuna_seeded(void);
+static bool random_fortuna_seeded_internal(void);
 static void random_fortuna_process_event(struct harvest_event *);
 static void random_fortuna_init_alg(void *);
 static void random_fortuna_deinit_alg(void *);
@@ -277,7 +278,7 @@ random_fortuna_reseed_internal(uint32_t *entropy_data,
 
RANDOM_RESEED_ASSERT_LOCK_OWNED();
 
-   seeded = random_fortuna_seeded();
+   seeded = random_fortuna_seeded_internal();
if (seeded) {
randomdev_getkey(_state.fs_key, , );
KASSERT(keysz == RANDOM_KEYSIZE, ("%s: key size %zu not %u",
@@ -377,8 +378,12 @@ random_fortuna_pre_read(void)
 
if (fortuna_state.fs_pool[0].fsp_length < fortuna_state.fs_minpoolsize
 #ifdef _KERNEL
-   /* FS - Use 'getsbinuptime()' to prevent reseed-spamming. */
-   || (now - fortuna_state.fs_lasttime <= SBT_1S/10)
+   /*
+* FS - Use 'getsbinuptime()' to prevent reseed-spamming, but do
+* not block initial seeding (fs_lasttime == 0).
+*/
+   || (__predict_true(fortuna_state.fs_lasttime != 0) &&
+   now - fortuna_state.fs_lasttime <= SBT_1S/10)
 #endif
) {
RANDOM_RESEED_UNLOCK();
@@ -460,7 +465,13 @@ SYSCTL_BOOL(_kern_random, OID_AUTO, block_seeded_statu
 "unavailable.");
 #endif
 
-bool
+static bool
+random_fortuna_seeded_internal(void)
+{
+   return (!uint128_is_zero(fortuna_state.fs_counter));
+}
+
+static bool
 random_fortuna_seeded(void)
 {
 
@@ -469,5 +480,14 @@ random_fortuna_seeded(void)
return (false);
 #endif
 
-   return (!uint128_is_zero(fortuna_state.fs_counter));
+   if 

svn commit: r347555 - in head: . sys/kern

2019-05-13 Thread Conrad Meyer
Author: cem
Date: Mon May 13 23:37:44 2019
New Revision: 347555
URL: https://svnweb.freebsd.org/changeset/base/347555

Log:
  Revert r346292 (permit_nonrandom_stackcookies)
  
  We have a better, more comprehensive knob for this now:
  kern.random.initial_seeding.bypass_before_seeding=1.
  
  Requested by: delphij
  Sponsored by: Dell EMC Isilon

Modified:
  head/UPDATING
  head/sys/kern/stack_protector.c

Modified: head/UPDATING
==
--- head/UPDATING   Mon May 13 23:30:06 2019(r347554)
+++ head/UPDATING   Mon May 13 23:37:44 2019(r347555)
@@ -76,13 +76,6 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
produce warnings in dmesg when the conditions are met.
 
 20190416:
-   The tunable "security.stack_protect.permit_nonrandom_cookies" may be
-   set to a non-zero value to boot systems that do not provide early
-   entropy.  Otherwise, such systems may see the panic message:
-   "cannot initialize stack cookies because random device is not yet
-   seeded."
-
-20190416:
The loadable random module KPI has changed; the random_infra_init()
routine now requires a 3rd function pointer for a bool (*)(void)
method that returns true if the random device is seeded (and

Modified: head/sys/kern/stack_protector.c
==
--- head/sys/kern/stack_protector.c Mon May 13 23:30:06 2019
(r347554)
+++ head/sys/kern/stack_protector.c Mon May 13 23:37:44 2019
(r347555)
@@ -4,28 +4,12 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 
 long __stack_chk_guard[8] = {};
 void __stack_chk_fail(void);
 
-/*
- * XXX This default is unsafe!!!  We intend to change it after resolving issues
- * with early entropy in the installer; some kinds of systems that do not use
- * loader(8), such as riscv, aarch64, and power; and perhaps others that I am
- * forgetting off the top of my head.
- */
-static bool permit_nonrandom_cookies = true;
-
-SYSCTL_NODE(_security, OID_AUTO, stack_protect, CTLFLAG_RW, 0,
-"-fstack-protect support");
-SYSCTL_BOOL(_security_stack_protect, OID_AUTO, permit_nonrandom_cookies,
-CTLFLAG_RDTUN, _nonrandom_cookies, 0,
-"Allow stack guard to be used without real random cookies");
-
 void
 __stack_chk_fail(void)
 {
@@ -39,37 +23,8 @@ __stack_chk_init(void *dummy __unused)
size_t i;
long guard[nitems(__stack_chk_guard)];
 
-   if (is_random_seeded()) {
-   arc4rand(guard, sizeof(guard), 0);
-   for (i = 0; i < nitems(guard); i++)
-   __stack_chk_guard[i] = guard[i];
-   return;
-   }
-
-   if (permit_nonrandom_cookies) {
-   printf("%s: WARNING: Initializing stack protection with "
-   "non-random cookies!\n", __func__);
-   printf("%s: WARNING: This severely limits the benefit of "
-   "-fstack-protector!\n", __func__);
-
-   /*
-* The emperor is naked, but I rolled some dice and at least
-* these values aren't zero.
-*/
-   __stack_chk_guard[0] = (long)0xe7318d5959af899full;
-   __stack_chk_guard[1] = (long)0x35a9481c089348bfull;
-   __stack_chk_guard[2] = (long)0xde657fdc04117255ull;
-   __stack_chk_guard[3] = (long)0x0dd44c61c22e4a6bull;
-   __stack_chk_guard[4] = (long)0x0a5869a354edb0a5ull;
-   __stack_chk_guard[5] = (long)0x05cebfed255b5232ull;
-   __stack_chk_guard[6] = (long)0x270ffac137c4c72full;
-   __stack_chk_guard[7] = (long)0xd8141a789bad478dull;
-   _Static_assert(nitems(__stack_chk_guard) == 8,
-   "__stack_chk_guard doesn't have 8 items");
-   return;
-   }
-
-   panic("%s: cannot initialize stack cookies because random device is "
-   "not yet seeded", __func__);
+   arc4rand(guard, sizeof(guard), 0);
+   for (i = 0; i < nitems(guard); i++)
+   __stack_chk_guard[i] = guard[i];
 }
 SYSINIT(stack_chk, SI_SUB_RANDOM, SI_ORDER_ANY, __stack_chk_init, 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: r348076 - head/sys/sys

2019-05-21 Thread Conrad Meyer
Author: cem
Date: Wed May 22 00:21:42 2019
New Revision: 348076
URL: https://svnweb.freebsd.org/changeset/base/348076

Log:
  Revert r348070
  
  Konstantin points out that lockmgr probably requires the whole lock.h anyway.
  
  Requested by: kib

Modified:
  head/sys/sys/lockmgr.h

Modified: head/sys/sys/lockmgr.h
==
--- head/sys/sys/lockmgr.h  Tue May 21 22:56:21 2019(r348075)
+++ head/sys/sys/lockmgr.h  Wed May 22 00:21:42 2019(r348076)
@@ -58,7 +58,7 @@
 #ifdef _KERNEL
 
 #if !defined(LOCK_FILE) || !defined(LOCK_LINE)
-#error "LOCK_FILE and LOCK_LINE not defined, include  before"
+#error "LOCK_FILE and LOCK_LINE not defined, include  before"
 #endif
 
 struct thread;
___
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: r348078 - head/usr.sbin/pmc

2019-05-21 Thread Conrad Meyer
Author: cem
Date: Wed May 22 01:22:33 2019
New Revision: 348078
URL: https://svnweb.freebsd.org/changeset/base/348078

Log:
  pmc: Fix stack std::string lifetime
  
  It's invalid to reference a C++ string's c_str() buffer after the object
  goes out of scope.  Adjust the scope of the string to match the use in
  write(2) to fix the misuse.
  
  CID:  1393383
  Reported by:  Coverity

Modified:
  head/usr.sbin/pmc/cmd_pmc_filter.cc

Modified: head/usr.sbin/pmc/cmd_pmc_filter.cc
==
--- head/usr.sbin/pmc/cmd_pmc_filter.cc Wed May 22 01:11:21 2019
(r348077)
+++ head/usr.sbin/pmc/cmd_pmc_filter.cc Wed May 22 01:22:33 2019
(r348078)
@@ -180,11 +180,12 @@ pmc_find_name(idmap & map, uint32_t id, char *list[LIS
 static void
 pmc_log_event(int fd, struct pmclog_ev *ev, bool json)
 {
+   string ret;
int len;
const void *buf;
 
if (json) {
-   string ret = event_to_json(ev);
+   ret = event_to_json(ev);
buf = ret.c_str();
len = ret.size();
} else {
___
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: r348130 - in head/sys/x86: include x86

2019-05-22 Thread Conrad Meyer
Author: cem
Date: Wed May 22 23:22:36 2019
New Revision: 348130
URL: https://svnweb.freebsd.org/changeset/base/348130

Log:
  Decode and name additional x86 feature bits
  
  These are all enumerated in Intel's ISA extension reference, 37th ed.
  
  Sponsored by: Dell EMC Isilon

Modified:
  head/sys/x86/include/specialreg.h
  head/sys/x86/x86/identcpu.c

Modified: head/sys/x86/include/specialreg.h
==
--- head/sys/x86/include/specialreg.h   Wed May 22 23:19:20 2019
(r348129)
+++ head/sys/x86/include/specialreg.h   Wed May 22 23:22:36 2019
(r348130)
@@ -433,29 +433,41 @@
 /*
  * CPUID instruction 7 Structured Extended Features, leaf 0 ecx info
  */
-#defineCPUID_STDEXT2_PREFETCHWT1 0x0001
-#defineCPUID_STDEXT2_UMIP  0x0004
-#defineCPUID_STDEXT2_PKU   0x0008
-#defineCPUID_STDEXT2_OSPKE 0x0010
-#defineCPUID_STDEXT2_WAITPKG   0x0020
-#defineCPUID_STDEXT2_GFNI  0x0100
-#defineCPUID_STDEXT2_RDPID 0x0040
-#defineCPUID_STDEXT2_CLDEMOTE  0x0200
-#defineCPUID_STDEXT2_MOVDIRI   0x0800
+#defineCPUID_STDEXT2_PREFETCHWT1   0x0001
+#defineCPUID_STDEXT2_AVX512VBMI0x0002
+#defineCPUID_STDEXT2_UMIP  0x0004
+#defineCPUID_STDEXT2_PKU   0x0008
+#defineCPUID_STDEXT2_OSPKE 0x0010
+#defineCPUID_STDEXT2_WAITPKG   0x0020
+#defineCPUID_STDEXT2_AVX512VBMI2   0x0040
+#defineCPUID_STDEXT2_GFNI  0x0100
+#defineCPUID_STDEXT2_VAES  0x0200
+#defineCPUID_STDEXT2_VPCLMULQDQ0x0400
+#defineCPUID_STDEXT2_AVX512VNNI0x0800
+#defineCPUID_STDEXT2_AVX512BITALG  0x1000
+#defineCPUID_STDEXT2_AVX512VPOPCNTDQ   0x4000
+#defineCPUID_STDEXT2_RDPID 0x0040
+#defineCPUID_STDEXT2_CLDEMOTE  0x0200
+#defineCPUID_STDEXT2_MOVDIRI   0x0800
 #defineCPUID_STDEXT2_MOVDIRI64B0x1000
-#defineCPUID_STDEXT2_SGXLC 0x4000
+#defineCPUID_STDEXT2_ENQCMD0x2000
+#defineCPUID_STDEXT2_SGXLC 0x4000
 
 /*
  * CPUID instruction 7 Structured Extended Features, leaf 0 edx info
  */
-#defineCPUID_STDEXT3_MD_CLEAR  0x0400
-#defineCPUID_STDEXT3_TSXFA 0x2000
-#defineCPUID_STDEXT3_IBPB  0x0400
-#defineCPUID_STDEXT3_STIBP 0x0800
-#defineCPUID_STDEXT3_L1D_FLUSH 0x1000
-#defineCPUID_STDEXT3_ARCH_CAP  0x2000
-#defineCPUID_STDEXT3_CORE_CAP  0x4000
-#defineCPUID_STDEXT3_SSBD  0x8000
+#defineCPUID_STDEXT3_AVX5124VNNIW  0x0004
+#defineCPUID_STDEXT3_AVX5124FMAPS  0x0008
+#defineCPUID_STDEXT3_AVX512VP2INTERSECT0x0100
+#defineCPUID_STDEXT3_MD_CLEAR  0x0400
+#defineCPUID_STDEXT3_TSXFA 0x2000
+#defineCPUID_STDEXT3_PCONFIG   0x0004
+#defineCPUID_STDEXT3_IBPB  0x0400
+#defineCPUID_STDEXT3_STIBP 0x0800
+#defineCPUID_STDEXT3_L1D_FLUSH 0x1000
+#defineCPUID_STDEXT3_ARCH_CAP  0x2000
+#defineCPUID_STDEXT3_CORE_CAP  0x4000
+#defineCPUID_STDEXT3_SSBD  0x8000
 
 /* MSR IA32_ARCH_CAP(ABILITIES) bits */
 #defineIA32_ARCH_CAP_RDCL_NO   0x0001

Modified: head/sys/x86/x86/identcpu.c
==
--- head/sys/x86/x86/identcpu.c Wed May 22 23:19:20 2019(r348129)
+++ head/sys/x86/x86/identcpu.c Wed May 22 23:22:36 2019(r348130)
@@ -983,11 +983,18 @@ printcpuinfo(void)
   "\004PKU"
   "\005OSPKE"
   "\006WAITPKG"
+  "\007AVX512VBMI2"
   "\011GFNI"
+  "\012VAES"
+  "\013VPCLMULQDQ"
+  "\014AVX512VNNI"
+  "\015AVX512BITALG"
+  "\016AVX512VPOPCNTDQ"
   "\027RDPID"
   "\032CLDEMOTE"
   "\034MOVDIRI"
   "\035MOVDIRI64B"
+  "\036ENQCMD"
   "\037SGXLC"
   );
}
@@ -996,8 +1003,12 @@ printcpuinfo(void)
printf("\n  

Re: svn commit: r348109 - in head/sys/x86: include x86

2019-05-22 Thread Conrad Meyer
On Wed, May 22, 2019 at 11:06 AM Andriy Gapon  wrote:
>
> On 22/05/2019 16:44, Andrew Gallatin wrote:
> >   This is needed for AMD SMCA processors, as SMCA uses different
> >   MSR address for access MCA banks.
>
> Just curious, what is SMCA?

Scalable MCA.  It's a set of AMD Fam17h MCA extensions.

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"


Re: svn commit: r347638 - in head: . etc lib/libc/gen

2019-05-22 Thread Conrad Meyer
Hi Brad,

Ping.  It's still broken.  Can you revert this please?

Thanks,
Conrad

On Thu, May 16, 2019 at 8:05 AM Conrad Meyer  wrote:
>
> Hi Brad,
>
> Can you revert this?  It seems to break every config-management tool
> we have (mergemaster, etcupdate, beinstall ...).
>
> Additionally, I don't believe this move has been justified — the cons
> seem to outweigh the pros, if there are any.  I skimmed the
> differential and it was not immediately obvious what the benefit was.
> The commit message describes what was changed, but not *why* you
> thought it was a good idea.
>
> Thanks,
> Conrad
>
> On Wed, May 15, 2019 at 6:09 PM Brad Davis  wrote:
> >
> > Author: brd
> > Date: Thu May 16 01:09:13 2019
> > New Revision: 347638
> > URL: https://svnweb.freebsd.org/changeset/base/347638
> >
> > Log:
> >   Move master.passwd and group to lib/libc/gen/
> >
> >   libc was picked as the destination location for these because of the 
> > syscalls
> >   that use these files as the lowest level place they are referenced.
> >
> >   Approved by:  will (mentor), rgrimes, manu
> >   Differential Revision:https://reviews.freebsd.org/D16728
> >
> > Added:
> >   head/lib/libc/gen/group
> >  - copied unchanged from r347637, head/etc/group
> >   head/lib/libc/gen/master.passwd
> >  - copied unchanged from r347637, head/etc/master.passwd
> > Deleted:
> >   head/etc/group
> >   head/etc/master.passwd
> > Modified:
> >   head/Makefile.inc1
> >   head/etc/Makefile
> >   head/lib/libc/gen/Makefile.inc
> >
> > Modified: head/Makefile.inc1
> > ==
> > --- head/Makefile.inc1  Thu May 16 00:53:54 2019(r347637)
> > +++ head/Makefile.inc1  Thu May 16 01:09:13 2019(r347638)
> > @@ -871,8 +871,8 @@ DB_FROM_SRC=yes
> >  .endif
> >
> >  .if defined(DB_FROM_SRC)
> > -INSTALLFLAGS+= -N ${.CURDIR}/etc
> > -MTREEFLAGS+=   -N ${.CURDIR}/etc
> > +INSTALLFLAGS+= -N ${.CURDIR}/lib/libc/gen
> > +MTREEFLAGS+=   -N ${.CURDIR}/lib/libc/gen
> >  .endif
> >  _INSTALL_DDIR= ${DESTDIR}/${DISTDIR}
> >  INSTALL_DDIR=  ${_INSTALL_DDIR:S://:/:g:C:/$::}
> >
> > Modified: head/etc/Makefile
> > ==
> > --- head/etc/Makefile   Thu May 16 00:53:54 2019(r347637)
> > +++ head/etc/Makefile   Thu May 16 01:09:13 2019(r347638)
> > @@ -15,7 +15,6 @@ SUBDIR+=sendmail
> >  .endif
> >
> >  BIN1=  \
> > -   group \
> > login.access \
> > rc.bsdextended \
> > rc.firewall \
> > @@ -65,21 +64,7 @@ distribution:
> >  .endif
> > cd ${.CURDIR}; \
> > ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 644 \
> > -   ${BIN1} ${DESTDIR}/etc; \
> > -   ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 600 \
> > -   master.passwd ${DESTDIR}/etc;
> > -
> > -.if ${MK_TCSH} == "no"
> > -   sed -i "" -e 's;/bin/csh;/bin/sh;' ${DESTDIR}/etc/master.passwd
> > -.endif
> > -   pwd_mkdb -i -p -d ${DESTDIR}/etc ${DESTDIR}/etc/master.passwd
> > -.if defined(NO_ROOT)
> > -   ( \
> > -   echo "./etc/passwd type=file mode=0644 uname=root 
> > gname=wheel"; \
> > -   echo "./etc/pwd.db type=file mode=0644 uname=root 
> > gname=wheel"; \
> > -   echo "./etc/spwd.db type=file mode=0600 uname=root 
> > gname=wheel"; \
> > -   ) | ${METALOG.add}
> > -.endif
> > +   ${BIN1} ${DESTDIR}/etc
> > ${_+_}cd ${.CURDIR}/gss; ${MAKE} install
> > ${_+_}cd ${.CURDIR}/mtree; ${MAKE} install
> > ${_+_}cd ${SRCTOP}/share/termcap; ${MAKE} etc-termcap
> >
> > Modified: head/lib/libc/gen/Makefile.inc
> > ==
> > --- head/lib/libc/gen/Makefile.inc  Thu May 16 00:53:54 2019
> > (r347637)
> > +++ head/lib/libc/gen/Makefile.inc  Thu May 16 01:09:13 2019
> > (r347638)
> > @@ -4,7 +4,8 @@
> >  # machine-independent gen sources
> >  .PATH: ${LIBC_SRCTOP}/${LIBC_ARCH}/gen ${LIBC_SRCTOP}/gen
> >
> > -CONFS= shells
> > +CONFS+=group master.passwd shells
> > +CONFSMODE_master.passwd=   600
> >
> >  SRCS+= __getosreldate.c \
> > __pthread_mutex_init_calloc_cb_stub.c \
> > @@ -543,

Re: svn commit: r348109 - in head/sys/x86: include x86

2019-05-22 Thread Conrad Meyer
On Wed, May 22, 2019 at 12:59 PM John Baldwin  wrote:

> On 5/22/19 12:12 PM, Conrad Meyer wrote:
> > On Wed, May 22, 2019 at 11:06 AM Andriy Gapon  wrote:
> >>
> >> On 22/05/2019 16:44, Andrew Gallatin wrote:
> >>>   This is needed for AMD SMCA processors, as SMCA uses different
> >>>   MSR address for access MCA banks.
> >>
> >> Just curious, what is SMCA?
> >
> > Scalable MCA.  It's a set of AMD Fam17h MCA extensions.
>
> How is it different aside from using different MSR numbers (which seems
> a bit gratuitous if that is really all the change is).
>
> --
> John Baldwin
>
It adds new MSRs as well, though those are not present in this first
change.  And adds some information not representable in the “legacy” MSRs.
Some more detail can be found in the linux patches, eg
https://lore.kernel.org/patchwork/patch/655889/ .
___
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: r348122 - in head/libexec: rc/rc.d save-entropy

2019-05-22 Thread Conrad Meyer
Author: cem
Date: Wed May 22 21:47:17 2019
New Revision: 348122
URL: https://svnweb.freebsd.org/changeset/base/348122

Log:
  save-entropy(8), rc.d/random: Set nodump flag
  
  Tag saved entropy files as "nodump," to signal that the files should not be
  backed up by dump(8) or other automated backup software that honors the file
  flag.
  
  Do not produce an error if the target file resides on a filesystem that does
  not support file flags (e.g., msdos /boot).
  
  Reviewed by:  delphij
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D20358

Modified:
  head/libexec/rc/rc.d/random
  head/libexec/save-entropy/save-entropy.sh

Modified: head/libexec/rc/rc.d/random
==
--- head/libexec/rc/rc.d/random Wed May 22 21:20:15 2019(r348121)
+++ head/libexec/rc/rc.d/random Wed May 22 21:47:17 2019(r348122)
@@ -25,6 +25,7 @@ save_dev_random()
for f ; do
debug "saving entropy to $f"
dd if=/dev/random of="$f" bs=4096 count=1 status=none &&
+   ( chflags nodump "$f" 2>/dev/null || : ) &&
chmod 600 "$f" &&
fsync "$f" "$(dirname "$f")"
done
@@ -99,7 +100,7 @@ random_stop()
[Nn][Oo])
;;
*)
-   echo -n 'Writing entropy file:'
+   echo -n 'Writing entropy file: '
rm -f ${entropy_file} 2> /dev/null
oumask=`umask`
umask 077
@@ -118,12 +119,7 @@ random_stop()
warn 'write failed (read-only fs?)'
;;
*)
-   dd if=/dev/random of=${entropy_file_confirmed} \
-   bs=4096 count=1 2> /dev/null ||
-   warn 'write failed (unwriteable file or full fs?)'
-   fsync "${entropy_file_confirmed}" \
-   "$(dirname "${entropy_file_confirmed}")" \
-   2> /dev/null
+   save_dev_random "${entropy_file_confirmed}"
echo '.'
;;
esac
@@ -134,7 +130,7 @@ random_stop()
[Nn][Oo])
;;
*)
-   echo -n 'Writing early boot entropy file:'
+   echo -n 'Writing early boot entropy file: '
rm -f ${entropy_boot_file} 2> /dev/null
oumask=`umask`
umask 077
@@ -146,12 +142,7 @@ random_stop()
warn 'write failed (read-only fs?)'
;;
*)
-   dd if=/dev/random of=${entropy_boot_file_confirmed} \
-   bs=4096 count=1 2> /dev/null ||
-   warn 'write failed (unwriteable file or full fs?)'
-   fsync "${entropy_boot_file_confirmed}" \
-   "$(dirname "${entropy_boot_file_confirmed}")" \
-   2> /dev/null
+   save_dev_random "${entropy_boot_file_confirmed}"
echo '.'
;;
esac

Modified: head/libexec/save-entropy/save-entropy.sh
==
--- head/libexec/save-entropy/save-entropy.sh   Wed May 22 21:20:15 2019
(r348121)
+++ head/libexec/save-entropy/save-entropy.sh   Wed May 22 21:47:17 2019
(r348122)
@@ -90,6 +90,7 @@ while [ ${n} -ge 1 ]; do
 done
 
 dd if=/dev/random of=saved-entropy.1 bs=${entropy_save_sz} count=1 2>/dev/null
+chflags nodump saved-entropy.1 2>/dev/null || :
 fsync saved-entropy.1 "."
 
 exit 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: r348199 - head/sys/dev/random

2019-05-23 Thread Conrad Meyer
Author: cem
Date: Thu May 23 21:02:27 2019
New Revision: 348199
URL: https://svnweb.freebsd.org/changeset/base/348199

Log:
  random(4): deduplicate explicit_bzero() in harvest
  
  Pull the responsibility for zeroing events, which is general to any
  conceivable implementation of a random device algorithm, out of the
  algorithm-specific Fortuna code and into the callers.  Most callers
  indirect through random_fortuna_process_event(), so add the logic there.
  Most callers already explicitly bzeroed the events they provided, so the
  logic in Fortuna was mostly redundant.
  
  Add one missing bzero in randomdev_accumulate().  Also, remove a redundant
  bzero in the same function -- randomdev_hash_finish() is obliged to bzero
  the hash state.
  
  Reviewed by:  delphij
  Approved by:  secteam(delphij)
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D20318

Modified:
  head/sys/dev/random/fortuna.c
  head/sys/dev/random/random_harvestq.c
  head/sys/dev/random/randomdev.c

Modified: head/sys/dev/random/fortuna.c
==
--- head/sys/dev/random/fortuna.c   Thu May 23 20:18:46 2019
(r348198)
+++ head/sys/dev/random/fortuna.c   Thu May 23 21:02:27 2019
(r348199)
@@ -254,7 +254,6 @@ random_fortuna_process_event(struct harvest_event *eve
fortuna_state.fs_pool[pl].fsp_length = MIN(RANDOM_FORTUNA_MAXPOOLSIZE,
fortuna_state.fs_pool[pl].fsp_length +
sizeof(event->he_somecounter) + event->he_size);
-   explicit_bzero(event, sizeof(*event));
RANDOM_RESEED_UNLOCK();
 }
 

Modified: head/sys/dev/random/random_harvestq.c
==
--- head/sys/dev/random/random_harvestq.c   Thu May 23 20:18:46 2019
(r348198)
+++ head/sys/dev/random/random_harvestq.c   Thu May 23 21:02:27 2019
(r348199)
@@ -163,6 +163,7 @@ random_harvestq_fast_process_event(struct harvest_even
 #if defined(RANDOM_LOADABLE)
RANDOM_CONFIG_S_UNLOCK();
 #endif
+   explicit_bzero(event, sizeof(*event));
 }
 
 static void
@@ -437,7 +438,6 @@ random_harvestq_prime(void *unused __unused)

harvest_context.hc_destination[RANDOM_CACHED]++;
memcpy(event.he_entropy, data + i, 
sizeof(event.he_entropy));
random_harvestq_fast_process_event();
-   explicit_bzero(, sizeof(event));
}
explicit_bzero(data, size);
if (bootverbose)
@@ -540,7 +540,6 @@ random_harvest_direct_(const void *entropy, u_int size
event.he_destination = harvest_context.hc_destination[origin]++;
memcpy(event.he_entropy, entropy, size);
random_harvestq_fast_process_event();
-   explicit_bzero(, sizeof(event));
 }
 
 void

Modified: head/sys/dev/random/randomdev.c
==
--- head/sys/dev/random/randomdev.c Thu May 23 20:18:46 2019
(r348198)
+++ head/sys/dev/random/randomdev.c Thu May 23 21:02:27 2019
(r348199)
@@ -321,7 +321,6 @@ randomdev_accumulate(uint8_t *buf, u_int count)
timestamp = (uint32_t)get_cyclecount();
randomdev_hash_iterate(, , sizeof(timestamp));
randomdev_hash_finish(, entropy_data);
-   explicit_bzero(, sizeof(hash));
for (i = 0; i < RANDOM_KEYSIZE_WORDS; i += 
sizeof(event.he_entropy)/sizeof(event.he_entropy[0])) {
event.he_somecounter = (uint32_t)get_cyclecount();
event.he_size = sizeof(event.he_entropy);
@@ -330,6 +329,7 @@ randomdev_accumulate(uint8_t *buf, u_int count)
memcpy(event.he_entropy, entropy_data + i, 
sizeof(event.he_entropy));
p_random_alg_context->ra_event_processor();
}
+   explicit_bzero(, sizeof(event));
explicit_bzero(entropy_data, sizeof(entropy_data));
 }
 
___
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: r348197 - in head: sbin/decryptcore sbin/dumpon sys/kern sys/sys

2019-05-23 Thread Conrad Meyer
Author: cem
Date: Thu May 23 20:12:24 2019
New Revision: 348197
URL: https://svnweb.freebsd.org/changeset/base/348197

Log:
  EKCD: Add Chacha20 encryption mode
  
  Add Chacha20 mode to Encrypted Kernel Crash Dumps.
  
  Chacha20 does not require messages to be multiples of block size, so it is
  valid to use the cipher on non-block-sized messages without the explicit
  padding AES-CBC would require.  Therefore, allow use with simultaneous dump
  compression.  (Continue to disallow use of AES-CBC EKCD with compression.)
  
  dumpon(8) gains a -C cipher flag to select between chacha and aes-cbc.
  It defaults to chacha if no -C option is provided.  The man page documents 
this
  behavior.
  
  Relnotes: sure
  Sponsored by: Dell EMC Isilon

Modified:
  head/sbin/decryptcore/decryptcore.c
  head/sbin/dumpon/dumpon.8
  head/sbin/dumpon/dumpon.c
  head/sys/kern/kern_shutdown.c
  head/sys/sys/kerneldump.h

Modified: head/sbin/decryptcore/decryptcore.c
==
--- head/sbin/decryptcore/decryptcore.c Thu May 23 20:04:22 2019
(r348196)
+++ head/sbin/decryptcore/decryptcore.c Thu May 23 20:12:24 2019
(r348197)
@@ -119,7 +119,8 @@ static bool
 decrypt(int ofd, const char *privkeyfile, const char *keyfile,
 const char *input)
 {
-   uint8_t buf[KERNELDUMP_BUFFER_SIZE], key[KERNELDUMP_KEY_MAX_SIZE];
+   uint8_t buf[KERNELDUMP_BUFFER_SIZE], key[KERNELDUMP_KEY_MAX_SIZE],
+   chachaiv[4 * 4];
EVP_CIPHER_CTX *ctx;
const EVP_CIPHER *cipher;
FILE *fp;
@@ -207,6 +208,9 @@ decrypt(int ofd, const char *privkeyfile, const char *
case KERNELDUMP_ENC_AES_256_CBC:
cipher = EVP_aes_256_cbc();
break;
+   case KERNELDUMP_ENC_CHACHA20:
+   cipher = EVP_chacha20();
+   break;
default:
pjdlog_error("Invalid encryption algorithm.");
goto failed;
@@ -222,7 +226,23 @@ decrypt(int ofd, const char *privkeyfile, const char *
RSA_free(privkey);
privkey = NULL;
 
-   EVP_DecryptInit_ex(ctx, cipher, NULL, key, kdk->kdk_iv);
+   if (kdk->kdk_encryption == KERNELDUMP_ENC_CHACHA20) {
+   /*
+* OpenSSL treats the IV as 4 little-endian 32 bit integers.
+*
+* The first two represent a 64-bit counter, where the low half
+* is the first 32-bit word.
+*
+* Start at counter block zero...
+*/
+   memset(chachaiv, 0, 4 * 2);
+   /*
+* And use the IV specified by the dump.
+*/
+   memcpy([4 * 2], kdk->kdk_iv, 4 * 2);
+   EVP_DecryptInit_ex(ctx, cipher, NULL, key, chachaiv);
+   } else
+   EVP_DecryptInit_ex(ctx, cipher, NULL, key, kdk->kdk_iv);
EVP_CIPHER_CTX_set_padding(ctx, 0);
 
explicit_bzero(key, sizeof(key));

Modified: head/sbin/dumpon/dumpon.8
==
--- head/sbin/dumpon/dumpon.8   Thu May 23 20:04:22 2019(r348196)
+++ head/sbin/dumpon/dumpon.8   Thu May 23 20:12:24 2019(r348197)
@@ -28,7 +28,7 @@
 .\" From: @(#)swapon.8 8.1 (Berkeley) 6/5/93
 .\" $FreeBSD$
 .\"
-.Dd May 21, 2019
+.Dd May 23, 2019
 .Dt DUMPON 8
 .Os
 .Sh NAME
@@ -39,6 +39,7 @@
 .Op Fl i Ar index
 .Op Fl r
 .Op Fl v
+.Op Fl C Ar cipher
 .Op Fl k Ar pubkey
 .Op Fl Z
 .Op Fl z
@@ -47,6 +48,7 @@
 .Op Fl i Ar index
 .Op Fl r
 .Op Fl v
+.Op Fl C Ar cipher
 .Op Fl k Ar pubkey
 .Op Fl Z
 .Op Fl z
@@ -129,6 +131,14 @@ The goal of the mechanism is to provide confidentialit
 The
 .Va pubkey
 file should be a PEM-formatted RSA key of at least 1024 bits.
+.It Fl C Ar cipher
+Select the symmetric algorithm used for encrypted kernel crash dump.
+The default is
+.Dq chacha20
+but
+.Dq aes256-cbc
+is also available.
+(AES256-CBC mode does not work in conjunction with compression.)
 .It Fl l
 List the currently configured dump device(s), or /dev/null if no devices are
 configured.
@@ -420,10 +430,6 @@ requires the
 .Dv GZIO
 option.
 .Sh BUGS
-It is currently not possible to configure both compression and encryption.
-The encrypted dump format assumes that the kernel dump size is a multiple
-of the cipher block size, which may not be true when the dump is compressed.
-.Pp
 Netdump only supports IPv4 at this time.
 .Sh SECURITY CONSIDERATIONS
 The current encrypted kernel core dump scheme does not provide integrity nor

Modified: head/sbin/dumpon/dumpon.c
==
--- head/sbin/dumpon/dumpon.c   Thu May 23 20:04:22 2019(r348196)
+++ head/sbin/dumpon/dumpon.c   Thu May 23 20:12:24 2019(r348197)
@@ -276,7 +276,16 @@ genkey(const char *pubkeyfile, struct diocskerneldump_
if (kdap->kda_encryptedkey == NULL)

svn commit: r348198 - head/sys/dev/uart

2019-05-23 Thread Conrad Meyer
Author: cem
Date: Thu May 23 20:18:46 2019
New Revision: 348198
URL: https://svnweb.freebsd.org/changeset/base/348198

Log:
  uart_cpu_acpi: Fix GCC build break from r348195
  
  extern declarations are redundant with those in uart_cpu.h, which this file
  includes.
  
  X-MFC-with:   r348195

Modified:
  head/sys/dev/uart/uart_cpu_acpi.c

Modified: head/sys/dev/uart/uart_cpu_acpi.c
==
--- head/sys/dev/uart/uart_cpu_acpi.c   Thu May 23 20:12:24 2019
(r348197)
+++ head/sys/dev/uart/uart_cpu_acpi.c   Thu May 23 20:18:46 2019
(r348198)
@@ -45,9 +45,6 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
-extern bus_space_tag_t uart_bus_space_io;
-extern bus_space_tag_t uart_bus_space_mem;
-
 static struct acpi_uart_compat_data *
 uart_cpu_acpi_scan(uint8_t interface_type)
 {
___
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: r348241 - head

2019-05-24 Thread Conrad Meyer
On Fri, May 24, 2019 at 9:24 AM Andrew Gallatin  wrote:
> Dumb question about this: Will it update toolchains, or just use what
> can find?

-DMAKE_JUST_KERNELS doesn't touch toolchains.  For that, there is the
less memorable build step:

export NCPU=$((1 * $(sysctl -n hw.ncpu) / 3)); make -sj${NCPU}
tinderbox JFLAG=-j${NCPU} UNIVERSE_TARGET=kernel-toolchain -DNO_CLEAN
___
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: r347967 - head/share/man/man4

2019-05-19 Thread Conrad Meyer
Author: cem
Date: Sun May 19 06:01:11 2019
New Revision: 347967
URL: https://svnweb.freebsd.org/changeset/base/347967

Log:
  nvd.4: Reference nda(4)
  
  Fix a totally minor typo in nvme.4 while here.

Modified:
  head/share/man/man4/nvd.4
  head/share/man/man4/nvme.4

Modified: head/share/man/man4/nvd.4
==
--- head/share/man/man4/nvd.4   Sun May 19 05:46:24 2019(r347966)
+++ head/share/man/man4/nvd.4   Sun May 19 06:01:11 2019(r347967)
@@ -33,7 +33,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd January 28, 2016
+.Dd May 18, 2019
 .Dt NVD 4
 .Os
 .Sh NAME
@@ -86,6 +86,7 @@ hw.nvd.delete_max=
 .Ed
 .Sh SEE ALSO
 .Xr GEOM 4 ,
+.Xr nda 4 ,
 .Xr nvme 4 ,
 .Xr geom 8 ,
 .Xr nvmecontrol 8 ,

Modified: head/share/man/man4/nvme.4
==
--- head/share/man/man4/nvme.4  Sun May 19 05:46:24 2019(r347966)
+++ head/share/man/man4/nvme.4  Sun May 19 06:01:11 2019(r347967)
@@ -130,7 +130,7 @@ The
 .Xr nvd 4
 driver performs better with smaller transactions and few TRIM
 commands.
-It sends all commands directly the drive immediately.
+It sends all commands directly to the drive immediately.
 The
 .Xr nda 4
 driver performs better with larger transactions and also collapses
___
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: r347984 - in head/sys: amd64/vmm/io arm/allwinner arm/allwinner/a10 arm/allwinner/clkng arm/arm arm/broadcom/bcm2835 arm/freescale/imx arm/mv arm/mv/armada arm/nvidia arm/nvidia/tegra12...

2019-05-19 Thread Conrad Meyer
Author: cem
Date: Mon May 20 00:38:23 2019
New Revision: 347984
URL: https://svnweb.freebsd.org/changeset/base/347984

Log:
  Extract eventfilter declarations to sys/_eventfilter.h
  
  This allows replacing "sys/eventfilter.h" includes with "sys/_eventfilter.h"
  in other header files (e.g., sys/{bus,conf,cpu}.h) and reduces header
  pollution substantially.
  
  EVENTHANDLER_DECLARE and EVENTHANDLER_LIST_DECLAREs were moved out of .c
  files into appropriate headers (e.g., sys/proc.h, powernv/opal.h).
  
  As a side effect of reduced header pollution, many .c files and headers no
  longer contain needed definitions.  The remainder of the patch addresses
  adding appropriate includes to fix those files.
  
  LOCK_DEBUG and LOCK_FILE_LINE_ARG are moved to sys/_lock.h, as required by
  sys/mutex.h since r326106 (but silently protected by header pollution prior
  to this change).
  
  No functional change (intended).  Of course, any out of tree modules that
  relied on header pollution for sys/eventhandler.h, sys/lock.h, or
  sys/mutex.h inclusion need to be fixed.  __FreeBSD_version has been bumped.

Added:
  head/sys/sys/_eventhandler.h   (contents, props changed)
Modified:
  head/sys/amd64/vmm/io/iommu.c
  head/sys/arm/allwinner/a10/a10_intc.c
  head/sys/arm/allwinner/a10_dmac.c
  head/sys/arm/allwinner/a31_dmac.c
  head/sys/arm/allwinner/aw_ccu.c
  head/sys/arm/allwinner/aw_reset.c
  head/sys/arm/allwinner/aw_rsb.c
  head/sys/arm/allwinner/aw_spi.c
  head/sys/arm/allwinner/aw_thermal.c
  head/sys/arm/allwinner/aw_wdog.c
  head/sys/arm/allwinner/clkng/aw_ccung.c
  head/sys/arm/arm/machdep.c
  head/sys/arm/arm/pl190.c
  head/sys/arm/broadcom/bcm2835/bcm2835_rng.c
  head/sys/arm/broadcom/bcm2835/bcm2835_wdog.c
  head/sys/arm/broadcom/bcm2835/bcm2836.c
  head/sys/arm/freescale/imx/imx_wdog.c
  head/sys/arm/mv/armada/thermal.c
  head/sys/arm/mv/armada/wdt.c
  head/sys/arm/mv/mv_spi.c
  head/sys/arm/mv/timer.c
  head/sys/arm/nvidia/tegra124/tegra124_machdep.c
  head/sys/arm/nvidia/tegra124/tegra124_pmc.c
  head/sys/arm/nvidia/tegra_xhci.c
  head/sys/arm/ti/ti_pruss.c
  head/sys/arm/ti/ti_wdt.c
  head/sys/arm/versatile/versatile_pci.c
  head/sys/arm/versatile/versatile_sic.c
  head/sys/arm64/arm64/gicv3_its.c
  head/sys/arm64/arm64/machdep.c
  head/sys/arm64/coresight/coresight.c
  head/sys/arm64/rockchip/clk/rk_cru.c
  head/sys/cam/cam_periph.h
  head/sys/cam/ctl/ctl_ha.c
  head/sys/cddl/compat/opensolaris/kern/opensolaris.c
  head/sys/contrib/ipfilter/netinet/ip_fil_freebsd.c
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c
  head/sys/crypto/aesni/aesni.c
  head/sys/crypto/armv8/armv8_crypto.c
  head/sys/crypto/blake2/blake2_cryptodev.c
  head/sys/crypto/ccp/ccp.c
  head/sys/crypto/ccp/ccp_hardware.c
  head/sys/ddb/db_command.c
  head/sys/dev/acpi_support/acpi_panasonic.c
  head/sys/dev/acpica/acpi.c
  head/sys/dev/acpica/acpi_lid.c
  head/sys/dev/acpica/acpi_thermal.c
  head/sys/dev/acpica/acpi_video.c
  head/sys/dev/acpica/acpivar.h
  head/sys/dev/adb/adb_kbd.c
  head/sys/dev/adb/adb_mouse.c
  head/sys/dev/amdsbwd/amdsbwd.c
  head/sys/dev/atkbdc/psm.c
  head/sys/dev/cardbus/cardbus.c
  head/sys/dev/cmx/cmx.c
  head/sys/dev/coretemp/coretemp.c
  head/sys/dev/cxgbe/cxgbei/cxgbei.c
  head/sys/dev/cxgbe/cxgbei/icl_cxgbei.c
  head/sys/dev/cxgbe/tom/t4_tls.c
  head/sys/dev/dcons/dcons_crom.c
  head/sys/dev/dcons/dcons_os.c
  head/sys/dev/dcons/dcons_os.h
  head/sys/dev/evdev/evdev_private.h
  head/sys/dev/extres/syscon/syscon_generic.c
  head/sys/dev/firewire/firewire.c
  head/sys/dev/firewire/fwohci.c
  head/sys/dev/ichwd/ichwd.c
  head/sys/dev/ida/ida_disk.c
  head/sys/dev/ida/ida_pci.c
  head/sys/dev/iir/iir_ctrl.c
  head/sys/dev/ioat/ioat.c
  head/sys/dev/ipmi/ipmi.c
  head/sys/dev/ipmi/ipmi_opal.c
  head/sys/dev/ips/ips.c
  head/sys/dev/iscsi/icl_soft_proxy.c
  head/sys/dev/iscsi_initiator/iscsivar.h
  head/sys/dev/iwm/if_iwm_notif_wait.c
  head/sys/dev/led/led.c
  head/sys/dev/liquidio/lio_bsd.h
  head/sys/dev/mfi/mfi_disk.c
  head/sys/dev/mfi/mfi_pci.c
  head/sys/dev/mfi/mfi_syspd.c
  head/sys/dev/mlx/mlxvar.h
  head/sys/dev/mmc/host/dwmmc.c
  head/sys/dev/mpr/mprvar.h
  head/sys/dev/mps/mpsvar.h
  head/sys/dev/mrsas/mrsas.h
  head/sys/dev/nmdm/nmdm.c
  head/sys/dev/ntb/if_ntb/if_ntb.c
  head/sys/dev/ntb/ntb_hw/ntb_hw_intel.c
  head/sys/dev/ow/ow.c
  head/sys/dev/pccard/pccard.c
  head/sys/dev/pci/pci.c
  head/sys/dev/pci/pci_iov.c
  head/sys/dev/pci/pci_pci.c
  head/sys/dev/pci/pcivar.h
  head/sys/dev/scc/scc_core.c
  head/sys/dev/scc/scc_dev_quicc.c
  head/sys/dev/scc/scc_dev_sab82532.c
  head/sys/dev/scc/scc_dev_z8530.c
  head/sys/dev/smartpqi/smartpqi_includes.h
  head/sys/dev/sound/pcm/sound.h
  head/sys/dev/tws/tws.h
  head/sys/dev/usb/net/if_cdce.c
  head/sys/dev/usb/net/if_usie.c
  head/sys/dev/usb/net/uhso.c
  head/sys/dev/usb/serial/u3g.c
  head/sys/dev/usb/usb_device.c
  head/sys/dev/usb/usbdi.h
  head/sys/dev/usb/wlan/if_run.c
  head/sys/dev/viawd/viawd.c
  head/sys/dev/vkbd/vkbd.c
  

svn commit: r347948 - in head: sbin/fdisk sys/sys/disk

2019-05-17 Thread Conrad Meyer
Author: cem
Date: Sat May 18 00:22:28 2019
New Revision: 347948
URL: https://svnweb.freebsd.org/changeset/base/347948

Log:
  Add DragonFly's partition number to fdisk(8) and diskmbr.h
  
  This change doesn't make any attempt to add support for these slices to the
  relevent GEOM classes.  Just register the number in fdisk and the canonical
  list of kernel macros (diskmbr.h).
  
  Obtained from:DragonFlyBSD (794d80aa519b394b3174f20776a) (small 
subset of)

Modified:
  head/sbin/fdisk/fdisk.c
  head/sys/sys/disk/mbr.h

Modified: head/sbin/fdisk/fdisk.c
==
--- head/sbin/fdisk/fdisk.c Fri May 17 22:14:30 2019(r347947)
+++ head/sbin/fdisk/fdisk.c Sat May 18 00:22:28 2019(r347948)
@@ -175,6 +175,7 @@ static const char *const part_types[256] = {
[0x63] = "System V/386 (such as ISC UNIX), GNU HURD or Mach",
[0x64] = "Novell Netware/286 2.xx",
[0x65] = "Novell Netware/386 3.xx",
+   [0x6C] = "DragonFlyBSD",
[0x70] = "DiskSecure Multi-Boot",
[0x75] = "PCIX",
[0x77] = "QNX4.x",

Modified: head/sys/sys/disk/mbr.h
==
--- head/sys/sys/disk/mbr.h Fri May 17 22:14:30 2019(r347947)
+++ head/sys/sys/disk/mbr.h Sat May 18 00:22:28 2019(r347948)
@@ -50,6 +50,7 @@
 #defineDOSPTYP_EXTLBA  0x0f/* DOS extended partition */
 #defineDOSPTYP_PPCBOOT 0x41/* PReP/CHRP boot partition */
 #defineDOSPTYP_LDM 0x42/* Win2k dynamic extended partition */
+#defineDOSPTYP_DFLYBSD 0x6c/* DragonFlyBSD partition type */
 #defineDOSPTYP_LINSWP  0x82/* Linux swap partition */
 #defineDOSPTYP_LINUX   0x83/* Linux partition */
 #defineDOSPTYP_LINLVM  0x8e/* Linux LVM partition */
___
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: r347984 - in head/sys: amd64/vmm/io arm/allwinner arm/allwinner/a10 arm/allwinner/clkng arm/arm arm/broadcom/bcm2835 arm/freescale/imx arm/mv arm/mv/armada arm/nvidia arm/nvidia/tegra1

2019-05-20 Thread Conrad Meyer
Hi Peter,

Thanks for reporting this.  I ran a full tinderbox on this change
(many many tinderboxes) and am not sure how I missed this.  I have to
run to an appointment now, but will fix these in a couple hours if no
one else beats me to it.  The fix is straightforward — include
.

Best,
Conrad

On Mon, May 20, 2019 at 12:21 PM Peter Jeremy  wrote:
>
> On 2019-May-20 00:38:23 +, Conrad Meyer  wrote:
> >Author: cem
> >Date: Mon May 20 00:38:23 2019
> >New Revision: 347984
> >URL: https://svnweb.freebsd.org/changeset/base/347984
> >
> >Log:
> >  Extract eventfilter declarations to sys/_eventfilter.h
> ...
> >  No functional change (intended).  Of course, any out of tree modules that
> >  relied on header pollution for sys/eventhandler.h, sys/lock.h, or
> >  sys/mutex.h inclusion need to be fixed.  __FreeBSD_version has been bumped.
>
> This seems to have broken at least netmap and netdump for me:
> /usr/src/sys/dev/netmap/netmap_freebsd.c:191:3: error: implicit declaration 
> of function 'EVENTHANDLER_REGISTER' is invalid in C99 
> [-Werror,-Wimplicit-function-declaration]
> EVENTHANDLER_REGISTER(ifnet_arrival_event,
> ^
> ...
> /usr/src/sys/netinet/netdump/netdump_client.c:1458:22: error: implicit 
> declaration of function 'EVENTHANDLER_REGISTER' is invalid in C99 
> [-Werror,-Wimplicit-function-declaration]
> nd_detach_cookie = 
> EVENTHANDLER_REGISTER(ifnet_departure_event,
>^
>
> --
> Peter Jeremy
___
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: r348067 - head/sys/kern

2019-05-21 Thread Conrad Meyer
Author: cem
Date: Tue May 21 21:26:14 2019
New Revision: 348067
URL: https://svnweb.freebsd.org/changeset/base/348067

Log:
  mqueuefs: Do not allow manipulation of the pseudo-dirents "." and ".."
  
  "." and ".." names are not maintained in the mqueuefs dirent datastructure and
  cannot be opened as mqueues.  Creating or removing them is invalid; return
  EINVAL instead of crashing.
  
  PR:   236836
  Submitted by: Torbjørn Birch Moltu 
  Discussed with:   jilles (earlier version)

Modified:
  head/sys/kern/uipc_mqueue.c

Modified: head/sys/kern/uipc_mqueue.c
==
--- head/sys/kern/uipc_mqueue.c Tue May 21 21:22:43 2019(r348066)
+++ head/sys/kern/uipc_mqueue.c Tue May 21 21:26:14 2019(r348067)
@@ -2042,6 +2042,12 @@ kern_kmq_open(struct thread *td, const char *upath, in
len = strlen(path);
if (len < 2 || path[0] != '/' || strchr(path + 1, '/') != NULL)
return (EINVAL);
+   /*
+* "." and ".." are magic directories, populated on the fly, and cannot
+* be opened as queues.
+*/
+   if (strcmp(path, "/.") == 0 || strcmp(path, "/..") == 0)
+   return (EINVAL);
AUDIT_ARG_UPATH1_CANON(path);
 
error = falloc(td, , , O_CLOEXEC);
@@ -2141,6 +2147,8 @@ sys_kmq_unlink(struct thread *td, struct kmq_unlink_ar
 
len = strlen(path);
if (len < 2 || path[0] != '/' || strchr(path + 1, '/') != NULL)
+   return (EINVAL);
+   if (strcmp(path, "/.") == 0 || strcmp(path, "/..") == 0)
return (EINVAL);
AUDIT_ARG_UPATH1_CANON(path);
 
___
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: r348070 - head/sys/sys

2019-05-21 Thread Conrad Meyer
Author: cem
Date: Tue May 21 21:35:37 2019
New Revision: 348070
URL: https://svnweb.freebsd.org/changeset/base/348070

Log:
  sys/lockmgr.h: Update #error to point at correct _lock.h
  
  After r347984, these macros live in sys/_lock.h.  No functional change.
  
  Sponsored by: Dell EMC Isilon

Modified:
  head/sys/sys/lockmgr.h

Modified: head/sys/sys/lockmgr.h
==
--- head/sys/sys/lockmgr.h  Tue May 21 21:27:14 2019(r348069)
+++ head/sys/sys/lockmgr.h  Tue May 21 21:35:37 2019(r348070)
@@ -58,7 +58,7 @@
 #ifdef _KERNEL
 
 #if !defined(LOCK_FILE) || !defined(LOCK_LINE)
-#error "LOCK_FILE and LOCK_LINE not defined, include  before"
+#error "LOCK_FILE and LOCK_LINE not defined, include  before"
 #endif
 
 struct thread;
___
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: r348064 - in head/sys: arm64/arm64 dev/acpica dev/ixgbe fs/unionfs kern mips/mips riscv/riscv ufs/ffs ufs/ufs vm

2019-05-21 Thread Conrad Meyer
Author: cem
Date: Tue May 21 20:38:48 2019
New Revision: 348064
URL: https://svnweb.freebsd.org/changeset/base/348064

Log:
  Include ktr.h in more compilation units
  
  Similar to r348026, exhaustive search for uses of CTRn() and cross reference
  ktr.h includes.  Where it was obvious that an OS compat header of some kind
  included ktr.h indirectly, .c files were left alone.  Some of these files
  clearly got ktr.h via header pollution in some scenarios, or tinderbox would
  not be passing prior to this revision, but go ahead and explicitly include it
  in files using it anyway.
  
  Like r348026, these CUs did not show up in tinderbox as missing the include.
  
  Reported by:  peterj (arm64/mp_machdep.c)
  X-MFC-With:   r347984
  Sponsored by: Dell EMC Isilon

Modified:
  head/sys/arm64/arm64/mp_machdep.c
  head/sys/arm64/arm64/trap.c
  head/sys/dev/acpica/acpi_ec.c
  head/sys/dev/ixgbe/if_sriov.c
  head/sys/fs/unionfs/union_subr.c
  head/sys/kern/kern_exit.c
  head/sys/kern/subr_eventhandler.c
  head/sys/kern/sys_process.c
  head/sys/kern/vfs_bio.c
  head/sys/kern/vfs_cache.c
  head/sys/kern/vfs_mount.c
  head/sys/kern/vfs_subr.c
  head/sys/kern/vfs_vnops.c
  head/sys/mips/mips/freebsd32_machdep.c
  head/sys/mips/mips/pm_machdep.c
  head/sys/mips/mips/trap.c
  head/sys/riscv/riscv/trap.c
  head/sys/ufs/ffs/ffs_vfsops.c
  head/sys/ufs/ufs/ufs_extattr.c
  head/sys/vm/vnode_pager.c

Modified: head/sys/arm64/arm64/mp_machdep.c
==
--- head/sys/arm64/arm64/mp_machdep.c   Tue May 21 19:42:04 2019
(r348063)
+++ head/sys/arm64/arm64/mp_machdep.c   Tue May 21 20:38:48 2019
(r348064)
@@ -40,6 +40,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/arm64/arm64/trap.c
==
--- head/sys/arm64/arm64/trap.c Tue May 21 19:42:04 2019(r348063)
+++ head/sys/arm64/arm64/trap.c Tue May 21 20:38:48 2019(r348064)
@@ -31,6 +31,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/dev/acpica/acpi_ec.c
==
--- head/sys/dev/acpica/acpi_ec.c   Tue May 21 19:42:04 2019
(r348063)
+++ head/sys/dev/acpica/acpi_ec.c   Tue May 21 20:38:48 2019
(r348064)
@@ -32,6 +32,7 @@ __FBSDID("$FreeBSD$");
 #include "opt_acpi.h"
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/dev/ixgbe/if_sriov.c
==
--- head/sys/dev/ixgbe/if_sriov.c   Tue May 21 19:42:04 2019
(r348063)
+++ head/sys/dev/ixgbe/if_sriov.c   Tue May 21 20:38:48 2019
(r348064)
@@ -37,6 +37,8 @@
 
 #ifdef PCI_IOV
 
+#include 
+
 MALLOC_DEFINE(M_IXGBE_SRIOV, "ix_sriov", "ix SR-IOV allocations");
 
 /

Modified: head/sys/fs/unionfs/union_subr.c
==
--- head/sys/fs/unionfs/union_subr.cTue May 21 19:42:04 2019
(r348063)
+++ head/sys/fs/unionfs/union_subr.cTue May 21 20:38:48 2019
(r348064)
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/kern/kern_exit.c
==
--- head/sys/kern/kern_exit.c   Tue May 21 19:42:04 2019(r348063)
+++ head/sys/kern/kern_exit.c   Tue May 21 20:38:48 2019(r348064)
@@ -47,6 +47,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/kern/subr_eventhandler.c
==
--- head/sys/kern/subr_eventhandler.c   Tue May 21 19:42:04 2019
(r348063)
+++ head/sys/kern/subr_eventhandler.c   Tue May 21 20:38:48 2019
(r348064)
@@ -31,6 +31,7 @@ __FBSDID("$FreeBSD$");
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/kern/sys_process.c
==
--- head/sys/kern/sys_process.c Tue May 21 19:42:04 2019(r348063)
+++ head/sys/kern/sys_process.c Tue May 21 20:38:48 2019(r348064)
@@ -36,6 +36,7 @@ __FBSDID("$FreeBSD$");
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/kern/vfs_bio.c
==
--- head/sys/kern/vfs_bio.c Tue May 21 19:42:04 2019(r348063)
+++ head/sys/kern/vfs_bio.c Tue May 21 20:38:48 2019(r348064)
@@ -57,6 +57,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 

Re: svn commit: r347638 - in head: . etc lib/libc/gen

2019-05-16 Thread Conrad Meyer
Hi Brad,

Can you revert this?  It seems to break every config-management tool
we have (mergemaster, etcupdate, beinstall ...).

Additionally, I don't believe this move has been justified — the cons
seem to outweigh the pros, if there are any.  I skimmed the
differential and it was not immediately obvious what the benefit was.
The commit message describes what was changed, but not *why* you
thought it was a good idea.

Thanks,
Conrad

On Wed, May 15, 2019 at 6:09 PM Brad Davis  wrote:
>
> Author: brd
> Date: Thu May 16 01:09:13 2019
> New Revision: 347638
> URL: https://svnweb.freebsd.org/changeset/base/347638
>
> Log:
>   Move master.passwd and group to lib/libc/gen/
>
>   libc was picked as the destination location for these because of the 
> syscalls
>   that use these files as the lowest level place they are referenced.
>
>   Approved by:  will (mentor), rgrimes, manu
>   Differential Revision:https://reviews.freebsd.org/D16728
>
> Added:
>   head/lib/libc/gen/group
>  - copied unchanged from r347637, head/etc/group
>   head/lib/libc/gen/master.passwd
>  - copied unchanged from r347637, head/etc/master.passwd
> Deleted:
>   head/etc/group
>   head/etc/master.passwd
> Modified:
>   head/Makefile.inc1
>   head/etc/Makefile
>   head/lib/libc/gen/Makefile.inc
>
> Modified: head/Makefile.inc1
> ==
> --- head/Makefile.inc1  Thu May 16 00:53:54 2019(r347637)
> +++ head/Makefile.inc1  Thu May 16 01:09:13 2019(r347638)
> @@ -871,8 +871,8 @@ DB_FROM_SRC=yes
>  .endif
>
>  .if defined(DB_FROM_SRC)
> -INSTALLFLAGS+= -N ${.CURDIR}/etc
> -MTREEFLAGS+=   -N ${.CURDIR}/etc
> +INSTALLFLAGS+= -N ${.CURDIR}/lib/libc/gen
> +MTREEFLAGS+=   -N ${.CURDIR}/lib/libc/gen
>  .endif
>  _INSTALL_DDIR= ${DESTDIR}/${DISTDIR}
>  INSTALL_DDIR=  ${_INSTALL_DDIR:S://:/:g:C:/$::}
>
> Modified: head/etc/Makefile
> ==
> --- head/etc/Makefile   Thu May 16 00:53:54 2019(r347637)
> +++ head/etc/Makefile   Thu May 16 01:09:13 2019(r347638)
> @@ -15,7 +15,6 @@ SUBDIR+=sendmail
>  .endif
>
>  BIN1=  \
> -   group \
> login.access \
> rc.bsdextended \
> rc.firewall \
> @@ -65,21 +64,7 @@ distribution:
>  .endif
> cd ${.CURDIR}; \
> ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 644 \
> -   ${BIN1} ${DESTDIR}/etc; \
> -   ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 600 \
> -   master.passwd ${DESTDIR}/etc;
> -
> -.if ${MK_TCSH} == "no"
> -   sed -i "" -e 's;/bin/csh;/bin/sh;' ${DESTDIR}/etc/master.passwd
> -.endif
> -   pwd_mkdb -i -p -d ${DESTDIR}/etc ${DESTDIR}/etc/master.passwd
> -.if defined(NO_ROOT)
> -   ( \
> -   echo "./etc/passwd type=file mode=0644 uname=root 
> gname=wheel"; \
> -   echo "./etc/pwd.db type=file mode=0644 uname=root 
> gname=wheel"; \
> -   echo "./etc/spwd.db type=file mode=0600 uname=root 
> gname=wheel"; \
> -   ) | ${METALOG.add}
> -.endif
> +   ${BIN1} ${DESTDIR}/etc
> ${_+_}cd ${.CURDIR}/gss; ${MAKE} install
> ${_+_}cd ${.CURDIR}/mtree; ${MAKE} install
> ${_+_}cd ${SRCTOP}/share/termcap; ${MAKE} etc-termcap
>
> Modified: head/lib/libc/gen/Makefile.inc
> ==
> --- head/lib/libc/gen/Makefile.inc  Thu May 16 00:53:54 2019
> (r347637)
> +++ head/lib/libc/gen/Makefile.inc  Thu May 16 01:09:13 2019
> (r347638)
> @@ -4,7 +4,8 @@
>  # machine-independent gen sources
>  .PATH: ${LIBC_SRCTOP}/${LIBC_ARCH}/gen ${LIBC_SRCTOP}/gen
>
> -CONFS= shells
> +CONFS+=group master.passwd shells
> +CONFSMODE_master.passwd=   600
>
>  SRCS+= __getosreldate.c \
> __pthread_mutex_init_calloc_cb_stub.c \
> @@ -543,3 +544,16 @@ MLINKS+=vis.3 nvis.3 \
> vis.3 svis.3
>
>  MLINKS+=wordexp.3 wordfree.3
> +
> +afterinstallconfig:
> +.if ${MK_TCSH} == "no"
> +   sed -i "" -e 's;/bin/csh;/bin/sh;' ${DESTDIR}/etc/master.passwd
> +.endif
> +   pwd_mkdb -i -p -d ${DESTDIR}/etc ${DESTDIR}/etc/master.passwd
> +.if defined(NO_ROOT) && defined(METALOG)
> +   ( \
> +   echo "./etc/pwd.db type=file mode=0644 uname=root 
> gname=wheel"; \
> +   echo "./etc/spwd.db type=file mode=0600 uname=root 
> gname=wheel"; \
> +   echo "./etc/passwd type=file mode=0644 uname=root 
> gname=wheel"; \
> +   ) | cat -l >> ${METALOG}
> +.endif
>
> Copied: head/lib/libc/gen/group (from r347637, head/etc/group)
> ==
> --- /dev/null   00:00:00 1970   (empty, because file is newly added)
> +++ head/lib/libc/gen/group Thu May 16 01:09:13 2019(r347638, 
> copy of r347637, head/etc/group)
> @@ -0,0 +1,36 @@
> +# $FreeBSD$
> +#
> +wheel:*:0:root
> +daemon:*:1:
> 

svn commit: r347828 - head/sys/dev/xdma

2019-05-16 Thread Conrad Meyer
Author: cem
Date: Thu May 16 17:34:36 2019
New Revision: 347828
URL: https://svnweb.freebsd.org/changeset/base/347828

Log:
  xdma(4): Fix invalid pointer use (breaks arm.SOCFPGA build)
  
  In xdma_handle_mem_node(), vmem_size_t and vmem_addr_t pointers were passed to
  an FDT API that emits u_long values to the output parameter pointer.  This
  broke on systems with both xdma and 32-bit vmem size/addr types (SOCFPGA).
  
  Reported by:  tinderbox
  Sponsored by: Dell EMC Isilon

Modified:
  head/sys/dev/xdma/xdma.c

Modified: head/sys/dev/xdma/xdma.c
==
--- head/sys/dev/xdma/xdma.cThu May 16 17:34:09 2019(r347827)
+++ head/sys/dev/xdma/xdma.cThu May 16 17:34:36 2019(r347828)
@@ -312,8 +312,7 @@ xdma_handle_mem_node(vmem_t *vmem, phandle_t memory)
pcell_t *regp;
int addr_cells, size_cells;
int i, reg_len, ret, tuple_size, tuples;
-   vmem_addr_t mem_start;
-   vmem_size_t mem_size;
+   u_long mem_start, mem_size;
 
if ((ret = fdt_addrsize_cells(OF_parent(memory), _cells,
_cells)) != 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: r347984 - in head/sys: amd64/vmm/io arm/allwinner arm/allwinner/a10 arm/allwinner/clkng arm/arm arm/broadcom/bcm2835 arm/freescale/imx arm/mv arm/mv/armada arm/nvidia arm/nvidia/tegra1

2019-05-20 Thread Conrad Meyer
Hi Peter,

Can you share what your kernel configuration is?

I believe the error is masked in existing tinderbox kernel
configurations ( https://ci.freebsd.org/tinderbox/ ) by some remaining
header pollution that must be conditional on an option.  The files
you've pointed out are missing the eventhandler header (and fixing
that is trivial), but I'd like to better understand where the leak is
so that other misses can be located.

Thanks,
Conrad

On Mon, May 20, 2019 at 12:31 PM Conrad Meyer  wrote:
>
> Hi Peter,
>
> Thanks for reporting this.  I ran a full tinderbox on this change
> (many many tinderboxes) and am not sure how I missed this.  I have to
> run to an appointment now, but will fix these in a couple hours if no
> one else beats me to it.  The fix is straightforward — include
> .
>
> Best,
> Conrad
>
> On Mon, May 20, 2019 at 12:21 PM Peter Jeremy  wrote:
> >
> > On 2019-May-20 00:38:23 +, Conrad Meyer  wrote:
> > >Author: cem
> > >Date: Mon May 20 00:38:23 2019
> > >New Revision: 347984
> > >URL: https://svnweb.freebsd.org/changeset/base/347984
> > >
> > >Log:
> > >  Extract eventfilter declarations to sys/_eventfilter.h
> > ...
> > >  No functional change (intended).  Of course, any out of tree modules that
> > >  relied on header pollution for sys/eventhandler.h, sys/lock.h, or
> > >  sys/mutex.h inclusion need to be fixed.  __FreeBSD_version has been 
> > > bumped.
> >
> > This seems to have broken at least netmap and netdump for me:
> > /usr/src/sys/dev/netmap/netmap_freebsd.c:191:3: error: implicit declaration 
> > of function 'EVENTHANDLER_REGISTER' is invalid in C99 
> > [-Werror,-Wimplicit-function-declaration]
> > EVENTHANDLER_REGISTER(ifnet_arrival_event,
> > ^
> > ...
> > /usr/src/sys/netinet/netdump/netdump_client.c:1458:22: error: implicit 
> > declaration of function 'EVENTHANDLER_REGISTER' is invalid in C99 
> > [-Werror,-Wimplicit-function-declaration]
> > nd_detach_cookie = 
> > EVENTHANDLER_REGISTER(ifnet_departure_event,
> >^
> >
> > --
> > Peter Jeremy
___
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: r348026 - in head/sys: arm/allwinner arm/amlogic/aml8726 arm/freescale/imx arm/rockchip arm/ti/am335x compat/linuxkpi/common/src dev/drm2/ttm dev/fb dev/hdmi dev/iscsi_initiator dev/mlx...

2019-05-20 Thread Conrad Meyer
Author: cem
Date: Tue May 21 01:18:43 2019
New Revision: 348026
URL: https://svnweb.freebsd.org/changeset/base/348026

Log:
  Include eventhandler.h in more compilation units
  
  This was enumerated with exhaustive search for sys/eventhandler.h includes,
  cross-referenced against EVENTHANDLER_* usage with the comm(1) utility.  
Manual
  checking was performed to avoid redundant includes in some drivers where a
  common os_bsd.h (for example) included sys/eventhandler.h indirectly, but it 
is
  possible some of these are redundant with driver-specific headers in ways I
  didn't notice.
  
  (These CUs did not show up as missing eventhandler.h in tinderbox.)
  
  X-MFC-With:   r347984

Modified:
  head/sys/arm/allwinner/a10_fb.c
  head/sys/arm/allwinner/a10_hdmi.c
  head/sys/arm/amlogic/aml8726/aml8726_wdt.c
  head/sys/arm/freescale/imx/imx6_ipu.c
  head/sys/arm/rockchip/rk30xx_wdog.c
  head/sys/arm/ti/am335x/am335x_lcd.c
  head/sys/arm/ti/am335x/tda19988.c
  head/sys/compat/linuxkpi/common/src/linux_compat.c
  head/sys/dev/drm2/ttm/ttm_page_alloc.c
  head/sys/dev/fb/creator.c
  head/sys/dev/fb/fbd.c
  head/sys/dev/hdmi/dwc_hdmi.c
  head/sys/dev/iscsi_initiator/iscsi.c
  head/sys/dev/mlx4/mlx4_en/mlx4_en_netdev.c
  head/sys/dev/mlx5/mlx5_en/mlx5_en_main.c
  head/sys/mips/atheros/ar531x/ar5315_wdog.c
  head/sys/mips/cavium/octeon_wdog.c
  head/sys/mips/ingenic/jz4780_lcd.c
  head/sys/ofed/drivers/infiniband/core/ib_roce_gid_mgmt.c
  head/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c
  head/sys/ofed/drivers/infiniband/ulp/sdp/sdp_main.c

Modified: head/sys/arm/allwinner/a10_fb.c
==
--- head/sys/arm/allwinner/a10_fb.c Tue May 21 00:46:47 2019
(r348025)
+++ head/sys/arm/allwinner/a10_fb.c Tue May 21 01:18:43 2019
(r348026)
@@ -38,6 +38,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/arm/allwinner/a10_hdmi.c
==
--- head/sys/arm/allwinner/a10_hdmi.c   Tue May 21 00:46:47 2019
(r348025)
+++ head/sys/arm/allwinner/a10_hdmi.c   Tue May 21 01:18:43 2019
(r348026)
@@ -38,6 +38,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 

Modified: head/sys/arm/amlogic/aml8726/aml8726_wdt.c
==
--- head/sys/arm/amlogic/aml8726/aml8726_wdt.c  Tue May 21 00:46:47 2019
(r348025)
+++ head/sys/arm/amlogic/aml8726/aml8726_wdt.c  Tue May 21 01:18:43 2019
(r348026)
@@ -35,6 +35,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/arm/freescale/imx/imx6_ipu.c
==
--- head/sys/arm/freescale/imx/imx6_ipu.c   Tue May 21 00:46:47 2019
(r348025)
+++ head/sys/arm/freescale/imx/imx6_ipu.c   Tue May 21 01:18:43 2019
(r348026)
@@ -32,6 +32,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/arm/rockchip/rk30xx_wdog.c
==
--- head/sys/arm/rockchip/rk30xx_wdog.c Tue May 21 00:46:47 2019
(r348025)
+++ head/sys/arm/rockchip/rk30xx_wdog.c Tue May 21 01:18:43 2019
(r348026)
@@ -32,6 +32,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/arm/ti/am335x/am335x_lcd.c
==
--- head/sys/arm/ti/am335x/am335x_lcd.c Tue May 21 00:46:47 2019
(r348025)
+++ head/sys/arm/ti/am335x/am335x_lcd.c Tue May 21 01:18:43 2019
(r348026)
@@ -35,6 +35,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/arm/ti/am335x/tda19988.c
==
--- head/sys/arm/ti/am335x/tda19988.c   Tue May 21 00:46:47 2019
(r348025)
+++ head/sys/arm/ti/am335x/tda19988.c   Tue May 21 01:18:43 2019
(r348026)
@@ -34,6 +34,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/compat/linuxkpi/common/src/linux_compat.c
==
--- head/sys/compat/linuxkpi/common/src/linux_compat.c  Tue May 21 00:46:47 
2019(r348025)
+++ head/sys/compat/linuxkpi/common/src/linux_compat.c  Tue May 21 01:18:43 
2019(r348026)
@@ -44,6 +44,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/dev/drm2/ttm/ttm_page_alloc.c

svn commit: r348022 - in head/sys: dev/netmap netinet/netdump

2019-05-20 Thread Conrad Meyer
Author: cem
Date: Tue May 21 00:04:19 2019
New Revision: 348022
URL: https://svnweb.freebsd.org/changeset/base/348022

Log:
  Add two missing eventhandler.h headers
  
  These are obviously missing from the .c files, but don't show up in any
  tinderbox configuration (due to latent header pollution of some kind).  It
  seems some configurations don't have this pollution, and the includes are
  obviously missing, so go ahead and add them.
  
  Reported by:  Peter Jeremy 
  X-MFC-With:   r347984

Modified:
  head/sys/dev/netmap/netmap_freebsd.c
  head/sys/netinet/netdump/netdump_client.c

Modified: head/sys/dev/netmap/netmap_freebsd.c
==
--- head/sys/dev/netmap/netmap_freebsd.cMon May 20 22:37:42 2019
(r348021)
+++ head/sys/dev/netmap/netmap_freebsd.cTue May 21 00:04:19 2019
(r348022)
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include   /* POLLIN, POLLOUT */
 #include  /* types used in module initialization */

Modified: head/sys/netinet/netdump/netdump_client.c
==
--- head/sys/netinet/netdump/netdump_client.c   Mon May 20 22:37:42 2019
(r348021)
+++ head/sys/netinet/netdump/netdump_client.c   Tue May 21 00:04:19 2019
(r348022)
@@ -38,6 +38,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #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"


Re: svn commit: r346959 - in head/release: . tools

2019-04-30 Thread Conrad Meyer
Thanks, Glen!

On Tue, Apr 30, 2019 at 7:29 AM Glen Barber  wrote:
>
> Author: gjb
> Date: Tue Apr 30 14:29:09 2019
> New Revision: 346959
> URL: https://svnweb.freebsd.org/changeset/base/346959
>
> Log:
>   Reduce the default image size for virtual machine disk images from
>   30GB to 3GB.  The raw images can be resized using truncate(1), and
>   other formats can be resized with tools included with other tools
>   included with other hypervisors.
>
>   Enable the growfs(8) rc(8) at firstboot if the disk was resized
>   prior to booting the virtual machine for the first time.
>
>   Discussed with:   several
>   PR:   232313 (requested in other context)
>   MFC after:3 days
>   Sponsored by: The FreeBSD Foundation
___
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: r347192 - in head: sbin/dumpon sys/dev/null sys/geom sys/geom/raid sys/kern sys/netinet/netdump sys/sys

2019-05-06 Thread Conrad Meyer
Author: cem
Date: Mon May  6 18:24:07 2019
New Revision: 347192
URL: https://svnweb.freebsd.org/changeset/base/347192

Log:
  List-ify kernel dump device configuration
  
  Allow users to specify multiple dump configurations in a prioritized list.
  This enables fallback to secondary device(s) if primary dump fails.  E.g.,
  one might configure a preference for netdump, but fallback to disk dump as a
  second choice if netdump is unavailable.
  
  This change does not list-ify netdump configuration, which is tracked
  separately from ordinary disk dumps internally; only one netdump
  configuration can be made at a time, for now.  It also does not implement
  IPv6 netdump.
  
  savecore(8) is already capable of scanning and iterating multiple devices
  from /etc/fstab or passed on the command line.
  
  This change doesn't update the rc or loader variables 'dumpdev' in any way;
  it can still be set to configure a single dump device, and rc.d/savecore
  still uses it as a single device.  Only dumpon(8) is updated to be able to
  configure the more complicated configurations for now.
  
  As part of revving the ABI, unify netdump and disk dump configuration ioctl
  / structure, and leave room for ipv6 netdump as a future possibility.
  Backwards-compatibility ioctls are added to smooth ABI transition,
  especially for developers who may not keep kernel and userspace perfectly
  synced.
  
  Reviewed by:  markj, scottl (earlier version)
  Relnotes: maybe
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D19996

Modified:
  head/sbin/dumpon/dumpon.8
  head/sbin/dumpon/dumpon.c
  head/sys/dev/null/null.c
  head/sys/geom/geom_dev.c
  head/sys/geom/raid/g_raid.h
  head/sys/kern/kern_shutdown.c
  head/sys/netinet/netdump/netdump.h
  head/sys/netinet/netdump/netdump_client.c
  head/sys/sys/conf.h
  head/sys/sys/disk.h
  head/sys/sys/param.h

Modified: head/sbin/dumpon/dumpon.8
==
--- head/sbin/dumpon/dumpon.8   Mon May  6 16:54:35 2019(r347191)
+++ head/sbin/dumpon/dumpon.8   Mon May  6 18:24:07 2019(r347192)
@@ -28,7 +28,7 @@
 .\" From: @(#)swapon.8 8.1 (Berkeley) 6/5/93
 .\" $FreeBSD$
 .\"
-.Dd November 17, 2018
+.Dd May 6, 2019
 .Dt DUMPON 8
 .Os
 .Sh NAME
@@ -36,12 +36,16 @@
 .Nd "specify a device for crash dumps"
 .Sh SYNOPSIS
 .Nm
+.Op Fl i Ar index
+.Op Fl r
 .Op Fl v
 .Op Fl k Ar pubkey
 .Op Fl Z
 .Op Fl z
 .Ar device
 .Nm
+.Op Fl i Ar index
+.Op Fl r
 .Op Fl v
 .Op Fl k Ar pubkey
 .Op Fl Z
@@ -72,8 +76,38 @@ and
 .Va dumpon_flags .
 For more information on this usage, see
 .Xr rc.conf 5 .
+.Pp
+Starting in
+.Fx 13.0 ,
+.Nm
+can configure a series of fallback dump devices.
+For example, an administrator may prefer
+.Xr netdump 4
+by default, but if the
+.Xr netdump 4
+service cannot be reached or some other failure occurs, they might choose a
+local disk dump as a second choice option.
 .Ss General options
 .Bl -tag -width _k_pubkey
+.It Fl i Ar index
+Insert the specified dump configuration into the prioritized fallback dump
+device list at the specified index, starting at zero.
+.Pp
+If
+.Fl i
+is not specified, the configured dump device is appended to the prioritized
+list.
+.It Fl r
+Remove the specified dump device configuration or configurations from the
+fallback dump device list rather than inserting or appending it.
+In contrast,
+.Do
+.Nm
+off
+.Dc
+removes all configured devices.
+Conflicts with
+.Fl i .
 .It Fl k Ar pubkey
 Configure encrypted kernel dumps.
 .Pp
@@ -96,7 +130,7 @@ The
 .Va pubkey
 file should be a PEM-formatted RSA key of at least 1024 bits.
 .It Fl l
-List the currently configured dump device, or /dev/null if no device is
+List the currently configured dump device(s), or /dev/null if no devices are
 configured.
 .It Fl v
 Enable verbose mode.

Modified: head/sbin/dumpon/dumpon.c
==
--- head/sbin/dumpon/dumpon.c   Mon May  6 16:54:35 2019(r347191)
+++ head/sbin/dumpon/dumpon.c   Mon May  6 18:24:07 2019(r347192)
@@ -86,8 +86,8 @@ static void _Noreturn
 usage(void)
 {
fprintf(stderr,
-"usage: dumpon [-v] [-k ] [-Zz] \n"
-"   dumpon [-v] [-k ] [-Zz]\n"
+"usage: dumpon [-i index] [-r] [-v] [-k ] [-Zz] \n"
+"   dumpon [-i index] [-r] [-v] [-k ] [-Zz]\n"
 "  [-g ] -s  -c  \n"
 "   dumpon [-v] off\n"
 "   dumpon [-v] -l\n");
@@ -290,8 +290,10 @@ genkey(const char *pubkeyfile, struct diocskerneldump_
 static void
 listdumpdev(void)
 {
+   static char ip[200];
+
char dumpdev[PATH_MAX];
-   struct netdump_conf ndconf;
+   struct diocskerneldump_arg ndconf;
size_t len;
const char *sysctlname = "kern.shutdown.dumpdevname";
int fd;
@@ -308,10 +310,18 @@ listdumpdev(void)
if (strlen(dumpdev) == 0)
(void)strlcpy(dumpdev, 

Re: svn commit: r347229 - in head: lib/libsbuf lib/libsbuf/tests share/man/man9 sys/kern sys/sys

2019-05-07 Thread Conrad Meyer
One correction

On Tue, May 7, 2019 at 10:47 AM Conrad Meyer  wrote:

> Author: cem
> Date: Tue May  7 17:47:20 2019
> New Revision: 347229
> URL: https://svnweb.freebsd.org/changeset/base/347229
>
> Log:
>   device_printf: Use sbuf for more coherent prints on SMP
>
>   device_printf does multiple calls to printf allowing other console
> messages to
>   be inserted between the device name, and the rest of the message.  This
> change
>   uses sbuf to compose to two into a single buffer, and prints it all at
> once.
>
>   It exposes an sbuf drain function (drain-to-printf) for common use.
>
>   Update documentation to match; some unit tests included.
>
>   Submitted by: jmg
>   Sponsored by: Dell EMC Isilon


^^^ Sorry, I added this on autopilot. It was fully jmg@‘s work.


>   Differential Revision:https://reviews.freebsd.org/D16690
>
___
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: r347229 - in head: lib/libsbuf lib/libsbuf/tests share/man/man9 sys/kern sys/sys

2019-05-07 Thread Conrad Meyer
Author: cem
Date: Tue May  7 17:47:20 2019
New Revision: 347229
URL: https://svnweb.freebsd.org/changeset/base/347229

Log:
  device_printf: Use sbuf for more coherent prints on SMP
  
  device_printf does multiple calls to printf allowing other console messages to
  be inserted between the device name, and the rest of the message.  This change
  uses sbuf to compose to two into a single buffer, and prints it all at once.
  
  It exposes an sbuf drain function (drain-to-printf) for common use.
  
  Update documentation to match; some unit tests included.
  
  Submitted by: jmg
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D16690

Modified:
  head/lib/libsbuf/Symbol.map
  head/lib/libsbuf/tests/sbuf_core_test.c
  head/lib/libsbuf/tests/sbuf_stdio_test.c
  head/share/man/man9/Makefile
  head/share/man/man9/sbuf.9
  head/sys/kern/kern_sysctl.c
  head/sys/kern/subr_bus.c
  head/sys/kern/subr_prf.c
  head/sys/sys/sbuf.h

Modified: head/lib/libsbuf/Symbol.map
==
--- head/lib/libsbuf/Symbol.map Tue May  7 16:17:33 2019(r347228)
+++ head/lib/libsbuf/Symbol.map Tue May  7 17:47:20 2019(r347229)
@@ -37,5 +37,6 @@ FBSD_1.4 {
 
 FBSD_1.5 {
sbuf_putbuf;
+   sbuf_printf_drain;
 };
 

Modified: head/lib/libsbuf/tests/sbuf_core_test.c
==
--- head/lib/libsbuf/tests/sbuf_core_test.c Tue May  7 16:17:33 2019
(r347228)
+++ head/lib/libsbuf/tests/sbuf_core_test.c Tue May  7 17:47:20 2019
(r347229)
@@ -63,6 +63,9 @@ ATF_TC_BODY(sbuf_clear_test, tc)
 */
child_proc = atf_utils_fork();
if (child_proc == 0) {
+   ATF_REQUIRE_EQ_MSG(0, sbuf_finish(sb), "sbuf_finish failed: %s",
+   strerror(errno));
+
sbuf_putbuf(sb);
exit(0);
}
@@ -100,6 +103,34 @@ ATF_TC_BODY(sbuf_done_and_sbuf_finish_test, tc)
sbuf_delete(sb);
 }
 
+static int
+drain_ret0(void *arg, const char *data, int len)
+{
+
+   (void)arg;
+   (void)data;
+   (void)len;
+
+   return (0);
+}
+
+ATF_TC_WITHOUT_HEAD(sbuf_drain_ret0_test);
+ATF_TC_BODY(sbuf_drain_ret0_test, tc)
+{
+   struct sbuf *sb;
+
+   sb = sbuf_new_auto();
+
+   sbuf_set_drain(sb, drain_ret0, NULL);
+
+   sbuf_cat(sb, test_string);
+
+   ATF_CHECK_EQ_MSG(-1, sbuf_finish(sb),
+   "required to return error when drain func returns 0");
+   ATF_CHECK_EQ_MSG(EDEADLK, errno,
+   "errno required to be EDEADLK when drain func returns 0");
+}
+
 ATF_TC_WITHOUT_HEAD(sbuf_len_test);
 ATF_TC_BODY(sbuf_len_test, tc)
 {
@@ -131,6 +162,34 @@ ATF_TC_BODY(sbuf_len_test, tc)
sbuf_delete(sb);
 }
 
+ATF_TC_WITHOUT_HEAD(sbuf_new_fixedlen);
+ATF_TC_BODY(sbuf_new_fixedlen, tc)
+{
+   char buf[strlen(test_string) + 1];
+   struct sbuf sb;
+   pid_t child_proc;
+
+   sbuf_new(, buf, sizeof(buf), SBUF_FIXEDLEN);
+
+   sbuf_cat(, test_string);
+
+   child_proc = atf_utils_fork();
+   if (child_proc == 0) {
+   ATF_REQUIRE_EQ_MSG(0, sbuf_finish(), "sbuf_finish failed: 
%s",
+   strerror(errno));
+
+   sbuf_putbuf();
+   exit(0);
+   }
+   atf_utils_wait(child_proc, 0, test_string, "");
+
+   sbuf_putc(, ' ');
+
+   ATF_CHECK_EQ_MSG(-1, sbuf_finish(), "failed to return error on 
overflow");
+
+   sbuf_delete();
+}
+
 ATF_TC_WITHOUT_HEAD(sbuf_setpos_test);
 ATF_TC_BODY(sbuf_setpos_test, tc)
 {
@@ -190,7 +249,9 @@ ATF_TP_ADD_TCS(tp)
 
ATF_TP_ADD_TC(tp, sbuf_clear_test);
ATF_TP_ADD_TC(tp, sbuf_done_and_sbuf_finish_test);
+   ATF_TP_ADD_TC(tp, sbuf_drain_ret0_test);
ATF_TP_ADD_TC(tp, sbuf_len_test);
+   ATF_TP_ADD_TC(tp, sbuf_new_fixedlen);
 #if 0
/* TODO */
 #ifdef HAVE_SBUF_CLEAR_FLAGS

Modified: head/lib/libsbuf/tests/sbuf_stdio_test.c
==
--- head/lib/libsbuf/tests/sbuf_stdio_test.cTue May  7 16:17:33 2019
(r347228)
+++ head/lib/libsbuf/tests/sbuf_stdio_test.cTue May  7 17:47:20 2019
(r347229)
@@ -59,6 +59,60 @@ sbuf_vprintf_helper(struct sbuf *sb, const char * rest
return (rc);
 }
 
+ATF_TC_WITHOUT_HEAD(sbuf_printf_drain_null_test);
+ATF_TC_BODY(sbuf_printf_drain_null_test, tc)
+{
+   struct sbuf *sb;
+   char buf[2];
+   pid_t child_proc;
+
+   sb = sbuf_new(NULL, buf, sizeof(buf), SBUF_FIXEDLEN);
+   ATF_REQUIRE_MSG(sb != NULL, "sbuf_new_auto failed: %s",
+   strerror(errno));
+
+   child_proc = atf_utils_fork();
+   if (child_proc == 0) {
+   sbuf_set_drain(sb, sbuf_printf_drain, NULL);
+
+   ATF_REQUIRE_EQ_MSG(0, sbuf_cat(sb, test_string),
+   "sbuf_cat failed");
+
+   ATF_CHECK_EQ(0, 

svn commit: r347235 - head/lib/libsbuf

2019-05-07 Thread Conrad Meyer
Author: cem
Date: Tue May  7 21:15:11 2019
New Revision: 347235
URL: https://svnweb.freebsd.org/changeset/base/347235

Log:
  Fix libsbuf sbuf_printf_drain symbol version
  
  (Introduced incorrectly in r347229 earlier today.)
  
  As pointed out by kevans, 1.6 should be used for FreeBSD 13, like r340383.
  
  Submitted by: kevans
  Reported by:  kib
  Reviewed by:  jilles
  X-MFC-with:r347229
  Differential Revision:https://reviews.freebsd.org/D20187

Modified:
  head/lib/libsbuf/Symbol.map
  head/lib/libsbuf/Version.def

Modified: head/lib/libsbuf/Symbol.map
==
--- head/lib/libsbuf/Symbol.map Tue May  7 20:39:39 2019(r347234)
+++ head/lib/libsbuf/Symbol.map Tue May  7 21:15:11 2019(r347235)
@@ -37,6 +37,9 @@ FBSD_1.4 {
 
 FBSD_1.5 {
sbuf_putbuf;
-   sbuf_printf_drain;
 };
 
+/* Added in FreeBSD 13.x */
+FBSD_1.6 {
+   sbuf_printf_drain;
+};

Modified: head/lib/libsbuf/Version.def
==
--- head/lib/libsbuf/Version.defTue May  7 20:39:39 2019
(r347234)
+++ head/lib/libsbuf/Version.defTue May  7 21:15:11 2019
(r347235)
@@ -11,3 +11,7 @@ FBSD_1.4 {
 
 FBSD_1.5 {
 } FBSD_1.4;
+
+# This version was first added to 13.0-current.
+FBSD_1.6 {
+} FBSD_1.5;
___
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: r347066 - in head: sbin/fsck_ffs sys/ufs/ufs

2019-05-07 Thread Conrad Meyer
Hi Kirk,

Coverity points out that namlen may be used uninitialized in the
following sequence (CID 1401317):

On Fri, May 3, 2019 at 2:54 PM Kirk McKusick  wrote:
>
> Author: mckusick
> Date: Fri May  3 21:54:14 2019
> New Revision: 347066
> URL: https://svnweb.freebsd.org/changeset/base/347066
>
> Log:
>   This update eliminates a kernel stack disclosure bug in UFS/FFS
>   directory entries that is caused by uninitialized directory entry
>   padding written to the disk.
> ...
> --- head/sbin/fsck_ffs/dir.cFri May  3 21:48:42 2019(r347065)
> +++ head/sbin/fsck_ffs/dir.cFri May  3 21:54:14 2019(r347066)
> ...
> @@ -209,15 +230,39 @@ dircheck(struct inodesc *idesc, struct direct *dp)
> char *cp;
> u_char type;
> u_int8_t namlen;
> -   int spaceleft;
> +   int spaceleft, modified, unused;
>
> +   modified = 0;
> spaceleft = DIRBLKSIZ - (idesc->id_loc % DIRBLKSIZ);
> if (dp->d_reclen == 0 ||
> dp->d_reclen > spaceleft ||
> -   (dp->d_reclen & 0x3) != 0)
> +   (dp->d_reclen & (DIR_ROUNDUP - 1)) != 0)
> goto bad;
> -   if (dp->d_ino == 0)
> -   return (1);
> +   if (dp->d_ino == 0) {

In this case, namlen may never be initialized.

> +   /*
> +* Special case of an unused directory entry. Normally
> +* the kernel would coalesce unused space with the previous
> +* entry by extending its d_reclen, but there are situations
> +* (e.g. fsck) where that doesn't occur.
> +* If we're clearing out directory cruft (-z flag), then make
> +* sure this entry gets fully cleared as well.
> +*/
> +   if (zflag && fswritefd >= 0) {
> +   if (dp->d_type != 0) {
> +   dp->d_type = 0;
> +   modified = 1;
> +   }
> +   if (dp->d_namlen != 0) {
> +   dp->d_namlen = 0;
> +   modified = 1;
> +   }
> +   if (dp->d_name[0] != '\0') {
> +   dp->d_name[0] = '\0';
> +   modified = 1;
> +   }
> +   }
> +   goto good;

Then we jump 'good'.

> +   }
> size = DIRSIZ(0, dp);
> namlen = dp->d_namlen;
> type = dp->d_type;
> @@ -231,7 +276,37 @@ dircheck(struct inodesc *idesc, struct direct *dp)
> goto bad;
> if (*cp != '\0')
> goto bad;
> +
> +good:
> +   if (zflag && fswritefd >= 0) {
> +   /*
> +* Clear unused directory entry space, including the d_name
> +* padding.
> +*/
> +   /* First figure the number of pad bytes. */
> +   unused = roundup2(namlen + 1, DIR_ROUNDUP) - (namlen + 1);

And here we access uninitialized 'namlen'.

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: r347239 - head/sys/dev/random

2019-05-07 Thread Conrad Meyer
Author: cem
Date: Wed May  8 00:45:16 2019
New Revision: 347239
URL: https://svnweb.freebsd.org/changeset/base/347239

Log:
  random: x86 driver: Prefer RDSEED over RDRAND when available
  
  Per
  
https://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed
  , RDRAND is a PRNG seeded from the same source as RDSEED.  The source is
  more suitable as PRNG seed material, so prefer it when the RDSEED intrinsic
  is available (indicated in CPU feature bits).
  
  Reviewed by:  delphij, jhb, imp (earlier version)
  Approved by:  secteam(delphij)
  Security: yes
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D20192

Modified:
  head/sys/dev/random/ivy.c

Modified: head/sys/dev/random/ivy.c
==
--- head/sys/dev/random/ivy.c   Wed May  8 00:40:08 2019(r347238)
+++ head/sys/dev/random/ivy.c   Wed May  8 00:45:16 2019(r347239)
@@ -44,11 +44,13 @@ __FBSDID("$FreeBSD$");
 
 #include 
 #include 
+#include 
 
 #include 
 
 #defineRETRY_COUNT 10
 
+static bool has_rdrand, has_rdseed;
 static u_int random_ivy_read(void *, u_int);
 
 static struct random_source random_ivy = {
@@ -57,10 +59,9 @@ static struct random_source random_ivy = {
.rs_read = random_ivy_read
 };
 
-static inline int
-ivy_rng_store(u_long *buf)
+static int
+x86_rdrand_store(u_long *buf)
 {
-#ifdef __GNUCLIKE_ASM
u_long rndval;
int retry;
 
@@ -75,11 +76,40 @@ ivy_rng_store(u_long *buf)
: "+r" (retry), "=r" (rndval) : : "cc");
*buf = rndval;
return (retry);
-#else /* __GNUCLIKE_ASM */
-   return (0);
-#endif
 }
 
+static int
+x86_rdseed_store(u_long *buf)
+{
+   u_long rndval;
+   int retry;
+
+   retry = RETRY_COUNT;
+   __asm __volatile(
+   "1:\n\t"
+   "rdseed %1\n\t" /* read randomness into rndval */
+   "jc 2f\n\t" /* CF is set on success, exit retry loop */
+   "dec%0\n\t" /* otherwise, retry-- */
+   "jne1b\n\t" /* and loop if retries are not exhausted */
+   "2:"
+   : "+r" (retry), "=r" (rndval) : : "cc");
+   *buf = rndval;
+   return (retry);
+}
+
+DEFINE_IFUNC(static, int, x86_rng_store, (u_long *buf), static)
+{
+   has_rdrand = (cpu_feature2 & CPUID2_RDRAND);
+   has_rdseed = (cpu_stdext_feature & CPUID_STDEXT_RDSEED);
+
+   if (has_rdseed)
+   return (x86_rdseed_store);
+   else if (has_rdrand)
+   return (x86_rdrand_store);
+   else
+   return (NULL);
+}
+
 /* It is required that buf length is a multiple of sizeof(u_long). */
 static u_int
 random_ivy_read(void *buf, u_int c)
@@ -90,7 +120,7 @@ random_ivy_read(void *buf, u_int c)
KASSERT(c % sizeof(*b) == 0, ("partial read %d", c));
b = buf;
for (count = c; count > 0; count -= sizeof(*b)) {
-   if (ivy_rng_store() == 0)
+   if (x86_rng_store() == 0)
break;
*b++ = rndval;
}
@@ -104,14 +134,14 @@ rdrand_modevent(module_t mod, int type, void *unused)
 
switch (type) {
case MOD_LOAD:
-   if (cpu_feature2 & CPUID2_RDRAND) {
+   if (has_rdrand || has_rdseed) {
random_source_register(_ivy);
printf("random: fast provider: \"%s\"\n", 
random_ivy.rs_ident);
}
break;
 
case MOD_UNLOAD:
-   if (cpu_feature2 & CPUID2_RDRAND)
+   if (has_rdrand || has_rdseed)
random_source_deregister(_ivy);
break;
 
___
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: r346645 - in head/sys: compat/linuxkpi/common/include/linux compat/linuxkpi/common/src sys

2019-05-07 Thread Conrad Meyer
Hi Tycho,

On Wed, Apr 24, 2019 at 1:31 PM Tycho Nightingale  wrote:
>
> Author: tychon
> Date: Wed Apr 24 20:30:45 2019
> New Revision: 346645
> URL: https://svnweb.freebsd.org/changeset/base/346645
>
> Log:
>   LinuxKPI should use bus_dma(9) to be compatible with an IOMMU
>
>   Reviewed by:  hselasky, kib
>   Tested by:greg@unrelenting.technology
>   Sponsored by: Dell EMC Isilon
>   Differential Revision:https://reviews.freebsd.org/D19845
>...
> Modified: head/sys/compat/linuxkpi/common/src/linux_pci.c
> ==
> --- head/sys/compat/linuxkpi/common/src/linux_pci.c Wed Apr 24 19:56:02 
> 2019(r346644)
> +++ head/sys/compat/linuxkpi/common/src/linux_pci.c Wed Apr 24 20:30:45 
> 2019(r346645)
> ...
> +linux_dma_map_phys(struct device *dev, vm_paddr_t phys, size_t len)
> +{
> ...
> +   nseg = -1;
> +   mtx_lock(>dma_lock);
> +   if (_bus_dmamap_load_phys(priv->dmat, obj->dmamap, phys, len,
> +   BUS_DMA_NOWAIT, , ) != 0) {
> +   bus_dmamap_destroy(priv->dmat, obj->dmamap);
> +   mtx_unlock(>dma_lock);
> +   uma_zfree(linux_dma_obj_zone, obj);
> +   return (0);
> +   }
> +   mtx_unlock(>dma_lock);
> +
> +   KASSERT(++nseg == 1, ("More than one segment (nseg=%d)", nseg));

This construct is a bit odd.  Coverity produces the (perhaps spurious)
warning (CID 1401319) that the KASSERT (which can be compiled out in
!INVARIANTS builds) has a side effect (++nseg).  While true, nseg is
never used afterwards, so perhaps we can use the equivalent expression
with no side effect instead?  I.e., something like:

KASSERT(nseg == 0, ("More than one segment (nseg=%d)", nseg + 1));

Does that make sense?  It is a false positive of sorts, but performing
side effects in compiled-out assert is a pretty strong antipattern so
I'd just as soon "fix" the warning.

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: r347221 - head/sys/net

2019-05-07 Thread Conrad Meyer
Hi Marius,

This change seems to break LINT-NOIP tinderbox builds; one reference
to tcp_lro_free() is covered by #if defined(INET) || defined(INET6),
but the one added in iflib_rx_structures_free() is not.

On Tue, May 7, 2019 at 1:28 AM Marius Strobl  wrote:
>
> Author: marius
> Date: Tue May  7 08:28:35 2019
> New Revision: 347221
> URL: https://svnweb.freebsd.org/changeset/base/347221
> ...
> Modified: head/sys/net/iflib.c
> ==
> --- head/sys/net/iflib.cTue May  7 08:14:30 2019(r347220)
> +++ head/sys/net/iflib.cTue May  7 08:28:35 2019(r347221)
> ...

The one below is protected by INET or INET6 define:

> @@ -5627,14 +5668,14 @@ iflib_rx_structures_setup(if_ctx_t ctx)
>  #if defined(INET6) || defined(INET) 
>  fail:
> /*
> -* Free RX software descriptors allocated so far, we will only handle
> +* Free LRO resources allocated so far, we will only handle
>  * the rings that completed, the failing case will have
> -* cleaned up for itself. 'q' failed, so its the terminus.
> +* cleaned up for itself.  'q' failed, so its the terminus.
>  */
> rxq = ctx->ifc_rxqs;
> for (i = 0; i < q; ++i, rxq++) {
> -   iflib_rx_sds_free(rxq);
> -   rxq->ifr_cq_cidx = 0;
> +   if (if_getcapabilities(ctx->ifc_ifp) & IFCAP_LRO)
> +   tcp_lro_free(>ifr_lc);   <<<
> }
> return (err);
>  #endif <<<

But the following one is not:

> @@ -5649,9 +5690,12 @@ static void
>  iflib_rx_structures_free(if_ctx_t ctx)
>  {
> iflib_rxq_t rxq = ctx->ifc_rxqs;
> +   int i;
>
> -   for (int i = 0; i < ctx->ifc_softc_ctx.isc_nrxqsets; i++, rxq++) {
> +   for (i = 0; i < ctx->ifc_softc_ctx.isc_nrxqsets; i++, rxq++) {
> iflib_rx_sds_free(rxq);
> +   if (if_getcapabilities(ctx->ifc_ifp) & IFCAP_LRO)
> +   tcp_lro_free(>ifr_lc);

^^^

> }
> free(ctx->ifc_rxqs, M_IFLIB);
> ctx->ifc_rxqs = NULL;

This fails to compile on kernels without INET and INET6 (which is
something we still support, for reasons I cannot fathom) because
netinet/tcp_lro.c is conditional on option inet | inet6 in
sys/conf/files.

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: r347238 - head/sys/amd64/vmm

2019-05-07 Thread Conrad Meyer
Author: cem
Date: Wed May  8 00:40:08 2019
New Revision: 347238
URL: https://svnweb.freebsd.org/changeset/base/347238

Log:
  vmm(4): Pass through RDSEED feature bit to guests
  
  Reviewed by:  jhb
  Approved by:  #bhyve (jhb)
  MFC after:2 leapseconds
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D20194

Modified:
  head/sys/amd64/vmm/x86.c

Modified: head/sys/amd64/vmm/x86.c
==
--- head/sys/amd64/vmm/x86.cWed May  8 00:09:10 2019(r347237)
+++ head/sys/amd64/vmm/x86.cWed May  8 00:40:08 2019(r347238)
@@ -432,6 +432,7 @@ x86_emulate_cpuid(struct vm *vm, int vcpu_id,
CPUID_STDEXT_AVX2 | CPUID_STDEXT_BMI2 |
CPUID_STDEXT_ERMS | CPUID_STDEXT_RTM |
CPUID_STDEXT_AVX512F |
+   CPUID_STDEXT_RDSEED |
CPUID_STDEXT_AVX512PF |
CPUID_STDEXT_AVX512ER |
CPUID_STDEXT_AVX512CD | CPUID_STDEXT_SHA);
___
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"


<    5   6   7   8   9   10   11   12   13   14   >