CVS commit: src/share/misc
Module Name:src Committed By: alnsn Date: Fri Nov 24 21:17:49 UTC 2023 Modified Files: src/share/misc: acronyms.comp Log Message: Add two BTB entries. To generate a diff of this commit: cvs rdiff -u -r1.380 -r1.381 src/share/misc/acronyms.comp Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/share/misc/acronyms.comp diff -u src/share/misc/acronyms.comp:1.380 src/share/misc/acronyms.comp:1.381 --- src/share/misc/acronyms.comp:1.380 Mon Nov 20 21:16:41 2023 +++ src/share/misc/acronyms.comp Fri Nov 24 21:17:49 2023 @@ -1,4 +1,4 @@ -$NetBSD: acronyms.comp,v 1.380 2023/11/20 21:16:41 jschauma Exp $ +$NetBSD: acronyms.comp,v 1.381 2023/11/24 21:17:49 alnsn Exp $ 3WHS three-way handshake 8VSB 8-state vestigial side band modulation AA anti-aliasing @@ -197,6 +197,8 @@ BSSID basic service set identifier BT BitTorrent BT Bluetooth BT bit test +BTB branch target buffer +BTB board-to-board BTC bit test [and] complement BTM bus transport mechanism BTR bit test [and] reset
CVS commit: src/share/misc
Module Name:src Committed By: alnsn Date: Fri Nov 24 21:17:49 UTC 2023 Modified Files: src/share/misc: acronyms.comp Log Message: Add two BTB entries. To generate a diff of this commit: cvs rdiff -u -r1.380 -r1.381 src/share/misc/acronyms.comp Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/share/misc
Module Name:src Committed By: alnsn Date: Mon Jun 12 21:00:38 UTC 2023 Modified Files: src/share/misc: acronyms.comp Log Message: Add DPDK. To generate a diff of this commit: cvs rdiff -u -r1.354 -r1.355 src/share/misc/acronyms.comp Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/share/misc
Module Name:src Committed By: alnsn Date: Mon Jun 12 21:00:38 UTC 2023 Modified Files: src/share/misc: acronyms.comp Log Message: Add DPDK. To generate a diff of this commit: cvs rdiff -u -r1.354 -r1.355 src/share/misc/acronyms.comp Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/share/misc/acronyms.comp diff -u src/share/misc/acronyms.comp:1.354 src/share/misc/acronyms.comp:1.355 --- src/share/misc/acronyms.comp:1.354 Sun Jun 11 17:54:18 2023 +++ src/share/misc/acronyms.comp Mon Jun 12 21:00:38 2023 @@ -1,4 +1,4 @@ -$NetBSD: acronyms.comp,v 1.354 2023/06/11 17:54:18 dholland Exp $ +$NetBSD: acronyms.comp,v 1.355 2023/06/12 21:00:38 alnsn Exp $ 3WHS three-way handshake 8VSB 8-state vestigial side band modulation AA anti-aliasing @@ -446,6 +446,7 @@ DPAA data path acceleration architecture DPC deferred procedure call DPCM differential pulse code modulation DPD dead peer detection +DPDK data plane development kit DPI deep packet inspection DPI dots per inch DPL descriptor privilege level
Re: CVS commit: src/external/mit/lua/dist/src
Nikita wrote: > Module Name: src > Committed By: nikita > Date: Mon Apr 17 21:17:58 UTC 2023 > > Modified Files: > src/external/mit/lua/dist/src: ldump.c lundump.c > > Log Message: > lua: apply upstream bugfix for "Loading a corrupted binary file can segfault." Unless it's a security bugfix for a release branch, I don't feel that all those bugfixes should be applied to -current individually, it's ok to wait for Lua 5.4.5 release and import it. Alex
Re: CVS commit: src/usr.sbin/tprof
Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Fri Dec 23 19:37:06 UTC 2022 > > Modified Files: > src/usr.sbin/tprof: tprof_top.c > > Log Message: > use malloc instead of alloca so that SSP works. pullup to 10?
Re: CVS commit: src/etc
Simon Burge wrote: > Why don't we just mount all the ZFS filesystems in mountcritlocal? Future versions may require loading of encryption keys over kerberos or a special pam module to decrypt /home/$USER. Alex
CVS commit: src/share/man/man5
Module Name:src Committed By: alnsn Date: Sun Feb 20 14:43:39 UTC 2022 Modified Files: src/share/man/man5: rc.conf.5 Log Message: Document critical_filesystems_zfs. To generate a diff of this commit: cvs rdiff -u -r1.191 -r1.192 src/share/man/man5/rc.conf.5 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/share/man/man5/rc.conf.5 diff -u src/share/man/man5/rc.conf.5:1.191 src/share/man/man5/rc.conf.5:1.192 --- src/share/man/man5/rc.conf.5:1.191 Sun Feb 20 10:49:17 2022 +++ src/share/man/man5/rc.conf.5 Sun Feb 20 14:43:39 2022 @@ -1,4 +1,4 @@ -.\" $NetBSD: rc.conf.5,v 1.191 2022/02/20 10:49:17 alnsn Exp $ +.\" $NetBSD: rc.conf.5,v 1.192 2022/02/20 14:43:39 alnsn Exp $ .\" .\" Copyright (c) 1996 Matthew R. Green .\" All rights reserved. @@ -321,6 +321,17 @@ where the prefix means that it is not an error if the file system is not present in .Xr fstab 5 . +.It Sy critical_filesystems_zfs +A string. +Mount non-legacy ZFS file systems right after mounting local +file systems listed in +.Sy critical_filesystems_local +variable. +An entry can be prefixed with +.Ql "OPTIONAL:" +which means that it is not an error if the file system is not present +among available ZFS datasets. +The default is ''. .It Sy fsck_flags A string. A file system is checked with
CVS commit: src/share/man/man5
Module Name:src Committed By: alnsn Date: Sun Feb 20 14:43:39 UTC 2022 Modified Files: src/share/man/man5: rc.conf.5 Log Message: Document critical_filesystems_zfs. To generate a diff of this commit: cvs rdiff -u -r1.191 -r1.192 src/share/man/man5/rc.conf.5 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/etc
Module Name:src Committed By: alnsn Date: Sun Feb 20 14:42:08 UTC 2022 Modified Files: src/etc/defaults: rc.conf src/etc/rc.d: mountcritlocal Log Message: Enable critical_filesystems_zfs. To generate a diff of this commit: cvs rdiff -u -r1.161 -r1.162 src/etc/defaults/rc.conf cvs rdiff -u -r1.16 -r1.17 src/etc/rc.d/mountcritlocal Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/etc/defaults/rc.conf diff -u src/etc/defaults/rc.conf:1.161 src/etc/defaults/rc.conf:1.162 --- src/etc/defaults/rc.conf:1.161 Sun Jan 10 23:24:25 2021 +++ src/etc/defaults/rc.conf Sun Feb 20 14:42:07 2022 @@ -1,4 +1,4 @@ -# $NetBSD: rc.conf,v 1.161 2021/01/10 23:24:25 riastradh Exp $ +# $NetBSD: rc.conf,v 1.162 2022/02/20 14:42:07 alnsn Exp $ # # /etc/defaults/rc.conf -- # default configuration of /etc/rc.conf @@ -92,6 +92,7 @@ domainname="" # critical_filesystems_local="OPTIONAL:/var" critical_filesystems_remote="OPTIONAL:/usr" +critical_filesystems_zfs="" # Swap device controls. # Index: src/etc/rc.d/mountcritlocal diff -u src/etc/rc.d/mountcritlocal:1.16 src/etc/rc.d/mountcritlocal:1.17 --- src/etc/rc.d/mountcritlocal:1.16 Wed Jul 22 16:50:41 2020 +++ src/etc/rc.d/mountcritlocal Sun Feb 20 14:42:07 2022 @@ -1,6 +1,6 @@ #!/bin/sh # -# $NetBSD: mountcritlocal,v 1.16 2020/07/22 16:50:41 martin Exp $ +# $NetBSD: mountcritlocal,v 1.17 2022/02/20 14:42:07 alnsn Exp $ # # PROVIDE: mountcritlocal @@ -19,8 +19,12 @@ mountcritlocal_start() # This usually includes /var. # mount_critical_filesystems local || return $? + if checkyesno zfs; then + mount_critical_filesystems_zfs || return $? + fi return 0 } load_rc_config $name +load_rc_config_var zfs zfs run_rc_command "$1"
CVS commit: src/etc
Module Name:src Committed By: alnsn Date: Sun Feb 20 14:42:08 UTC 2022 Modified Files: src/etc/defaults: rc.conf src/etc/rc.d: mountcritlocal Log Message: Enable critical_filesystems_zfs. To generate a diff of this commit: cvs rdiff -u -r1.161 -r1.162 src/etc/defaults/rc.conf cvs rdiff -u -r1.16 -r1.17 src/etc/rc.d/mountcritlocal Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/share/man/man5
Module Name:src Committed By: alnsn Date: Sun Feb 20 10:49:17 UTC 2022 Modified Files: src/share/man/man5: rc.conf.5 Log Message: Document zfs variable. To generate a diff of this commit: cvs rdiff -u -r1.190 -r1.191 src/share/man/man5/rc.conf.5 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/share/man/man5
Module Name:src Committed By: alnsn Date: Sun Feb 20 10:49:17 UTC 2022 Modified Files: src/share/man/man5: rc.conf.5 Log Message: Document zfs variable. To generate a diff of this commit: cvs rdiff -u -r1.190 -r1.191 src/share/man/man5/rc.conf.5 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/share/man/man5/rc.conf.5 diff -u src/share/man/man5/rc.conf.5:1.190 src/share/man/man5/rc.conf.5:1.191 --- src/share/man/man5/rc.conf.5:1.190 Fri Jan 15 15:18:32 2021 +++ src/share/man/man5/rc.conf.5 Sun Feb 20 10:49:17 2022 @@ -1,4 +1,4 @@ -.\" $NetBSD: rc.conf.5,v 1.190 2021/01/15 15:18:32 riastradh Exp $ +.\" $NetBSD: rc.conf.5,v 1.191 2022/02/20 10:49:17 alnsn Exp $ .\" .\" Copyright (c) 1996 Matthew R. Green .\" All rights reserved. @@ -55,7 +55,7 @@ .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" -.Dd September 11, 2020 +.Dd February 20, 2022 .Dt RC.CONF 5 .Os .Sh NAME @@ -416,6 +416,9 @@ RAIDframe disk devices. See .Xr raidctl 8 for additional details. +.It Sy zfs +Boolean value. +Configures ZFS storage pools and ZFS file systems. .El .Ss One-time actions to perform or programs to run on boot-up .Bl -tag -width net_interfaces
CVS commit: src/etc
Module Name:src
Committed By: alnsn
Date: Sun Feb 6 16:23:12 UTC 2022
Modified Files:
src/etc: rc.subr
Log Message:
Small changes in mount_critical_filesystems_zfs
avoid unnecessary eval, switch to $() and -ne.
from kre@, thanks!
To generate a diff of this commit:
cvs rdiff -u -r1.109 -r1.110 src/etc/rc.subr
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/etc/rc.subr
diff -u src/etc/rc.subr:1.109 src/etc/rc.subr:1.110
--- src/etc/rc.subr:1.109 Thu Feb 3 21:02:47 2022
+++ src/etc/rc.subr Sun Feb 6 16:23:12 2022
@@ -1,4 +1,4 @@
-# $NetBSD: rc.subr,v 1.109 2022/02/03 21:02:47 alnsn Exp $
+# $NetBSD: rc.subr,v 1.110 2022/02/06 16:23:12 alnsn Exp $
#
# Copyright (c) 1997-2011 The NetBSD Foundation, Inc.
# All rights reserved.
@@ -207,10 +207,10 @@ mount_critical_filesystems()
# the rc.conf(5) variable $critical_filesystems_zfs, checking
# each one to see if it is mounted, and if it is not, mounting it.
# It's not an error if file systems prefixed with "OPTIONAL:"
-# aren't zfs mountpoints.
+# aren't ZFS mountpoints.
mount_critical_filesystems_zfs()
{
- eval _fslist=\$critical_filesystems_zfs
+ _fslist=$critical_filesystems_zfs
_tab=" "
_mountcrit_es=0
for _fs in $_fslist; do
@@ -222,7 +222,7 @@ mount_critical_filesystems_zfs()
;;
esac
- _dataset=`
+ _dataset=$(
zfs list -H -o mountpoint,name |
while read _line ; do
_dataset=''
@@ -240,7 +240,7 @@ mount_critical_filesystems_zfs()
;;
esac
fi
- done`
+ done)
if [ -z "$_dataset" ]; then
if $_optional; then
@@ -259,14 +259,13 @@ mount_critical_filesystems_zfs()
print_rc_metadata \
"note:File system $_fs was already mounted"
;;
- esac
-
- if [ -z "$_mount_es" ]; then
+ *) # no
zfs mount "$_dataset" >/dev/null
_mount_es=$?
- fi
+;;
+ esac
- if [ "$_mount_es" != 0 ]; then
+ if [ $_mount_es -ne 0 ]; then
_mountcrit_es="$_mount_es"
fi
fi
CVS commit: src/etc
Module Name:src Committed By: alnsn Date: Sun Feb 6 16:23:12 UTC 2022 Modified Files: src/etc: rc.subr Log Message: Small changes in mount_critical_filesystems_zfs avoid unnecessary eval, switch to $() and -ne. from kre@, thanks! To generate a diff of this commit: cvs rdiff -u -r1.109 -r1.110 src/etc/rc.subr Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/etc
Taylor R Campbell wrote: > > Date: Sat, 5 Feb 2022 21:21:53 + > > From: Alexander Nasonov > > > > Since I plan to migrate my ZFS setup to a smaller cgd disk, I gave > > legacy mountpoints a try to see how much complexity they add. > > I use legacy mountpoints for / and /var, but it's a little kludgey, > and from what I recall a legacy mountpoint requires setting the > mountpoint property explicitly on anything mounted under it. > > I assumed you had made the change to obviate the need for most of this > extra bookkeeping with fstab and explicit mountpoint properties that > don't match the zpool dataset path. That's right. > So I'm guessing with your change and critical_filesystems_zfs=/var, I > could: > > - skip the fstab entry for /var, > - have only rpool/ROOT with mountpoint=legacy, and > - have /var and all the file systems under /var use default > mountpoints. yes yes yes :) It even supports OPTIONAL: critical_filesystems_zfs=OPTIONAL:/var and it's clever enough to skip "fake" mountpoints (datasets with canmount=off). Alex
Re: CVS commit: src/etc
Brad Spencer wrote: > Alexander Nasonov writes: > > Are there any downside of mixing legacy and non-legacy mountpoints? > > E.g. if my /var is legacy but /var/crash is a normal ZFS mountpoint? > > That should work fine as long as /var was arranged to be mounted first. > The other way around may and probably is trouble right now, where a > zpool Not-legacy needs to be mounted so that a ZFS legacy filesystem or, > in fact, any other filesystem type gets mounted under it. I believe > that Solaris did and probably still does have this problem too. Legacy > ZFS mounts should be perfectly workable even from single user when /usr > isn't available yet for most simple use cases. Since I plan to migrate my ZFS setup to a smaller cgd disk, I gave legacy mountpoints a try to see how much complexity they add. I have the following ZFS mountpoints in my setup /usr - legacy /var - legacy /var/log - legacy /var/tmp - normal /var/mail - normal ... Ideally, I'd like to keep all datasets under one root: tank/base/usr - legacy tank/base/var - legacy tank/base/var/log - legacy tank/base/var/mail - normal but it has a small inconvenience: every time I add a new dataset under a legacy mountpoint (e.g. create a dataset for /var/spool), it can't inherit a mountpoint from a legacy mountpoint and I have to set it manually (zfs set mountpoint=/var/spool tank/base/var/spool). One way to avoid this issue is to have separate hierarchies: tank/legacy tank/legacy/usr tank/legacy/var tank/legacy/var/log tank/base tank/base/var tank/base/var/mail but I'm pretty sure it has some downsides too. Alex
Re: CVS commit: src/etc
J. Hannken-Illjes wrote: > What is wrong with ZFS legacy mounts? > > $ zpool create -m legacy tank > $ zfs create tank/a > $ mount -t zfs tank/a /mnt Hmm, I heard about ZFS legacy (quite a while ago!) but I didn't look into it because, well, "legacy"... Are there any downside of mixing legacy and non-legacy mountpoints? E.g. if my /var is legacy but /var/crash is a normal ZFS mountpoint? Alex
Re: CVS commit: src/etc
Martin Husemann wrote: > On Thu, Feb 03, 2022 at 11:10:43PM +0000, Alexander Nasonov wrote: > > variable, it will mix two very different styles of mounting and > > compilate the code. s/compilate/complicate/ > "different styles of mounting" sounds like a non-starter to me, maybe > that should be fixed first? These two "styles of mounting" are /sbin/mount /filesystem - looks up fs parameters in /etc/fstab /sbin/zfs mount dataset - looks up fs parameters in zpools I don't think these two approaches can be unified. We surely can modify mount_critical_systems to try entries from /etc/fstab first, and if /sbin/mount fails, then try to find a zfs dataset for the failed entry and /sbin/zfs mount it. But if things go wrong, a complicated mounting process will make troubleshooting harder. For that reason, I'd like to keep mountcrit_zfs separate from mountcrit_local. Alex
Re: CVS commit: src/etc
Hi Robert,
Robert Elz wrote:
> A couple of comments about your mount_critical_filesystems_zfs()
> function in rc.subr
Thank you for reviewing my code!
> It starts:
>
> eval _fslist=\$critical_filesystems_zfs
>
> I'm not sure what you're attempting to accomplish there.
I copied this line from mount_critical_filesystems:
eval _fslist=\$critical_filesystems_${1}
and changed ${1} to zfs without realising that I don't need eval
anymore.
>...
>_dataset=`
>
> (followed by a lengthy command substitution). Please don't use ``
> command substitutions, they are fragile, and essentially obsolete.
Noted.
I don't like the approach I took but I'm not very comfortable in
a bare shell when tools in /usr aren't (yet) available and this
giant $() was all I could think of.
> The only excuse for ever using them in anything modern is if the
> script might need to be run by a truly ancient shell. Just use $( )
> instead, the semantics are much cleaner.
>
> And perhaps more important, near the bottom of the big loop:
>
> if [ "$_mount_es" != 0 ]; then
> _mountcrit_es="$_mount_es"
> fi
>
> which causes the exit status of the function (_mountcrit_es) to be the
> status of the last mount that failed for some reason, rather than the
> first (which tends to be more common).
These lines is a copy/paste from mount_critical_filesystems and
your comment apply to that function too.
>...
> One additional minor point, it might be better to use -ne there instead
> of != since the values are intended to be integers, rather than strings.
> But that doesn't really matter (unless $_mount_es might be "" in which
> case using != is better - that would be 0 for -ne, but not 0 for !=).
Yes, it's intended to be integers.
--
Alex
Re: CVS commit: src/etc
Alexander Nasonov wrote: > Module Name: src > Committed By: alnsn > Date: Thu Feb 3 20:52:44 UTC 2022 > > Modified Files: > src/etc: rc.subr > > Log Message: > Add mount_critical_filesystems_zfs > > The new function is similar to mount_critical_filesystems > but it walks through ZFS datasets and mounts matching entries. I plan to intoduce a new rc.conf variable critical_filesystems_zfs which is essentially the same as critical_filesystems_local but for ZFS. Although the new variable can be avoided if my code is merged into existing mount_critical_filesystems(), and all critical filesystems (ZFS or not) are mounted in one pass through critical_filesystems_local variable, it will mix two very different styles of mounting and compilate the code. One extra variable shouldn't be a problem for most users but it will help to keep rc.subr neater. -- Alex
CVS commit: src/etc
Module Name:src Committed By: alnsn Date: Thu Feb 3 21:02:47 UTC 2022 Modified Files: src/etc: rc.subr Log Message: Compare $_mount_es with 0 To generate a diff of this commit: cvs rdiff -u -r1.108 -r1.109 src/etc/rc.subr Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/etc/rc.subr diff -u src/etc/rc.subr:1.108 src/etc/rc.subr:1.109 --- src/etc/rc.subr:1.108 Thu Feb 3 20:52:44 2022 +++ src/etc/rc.subr Thu Feb 3 21:02:47 2022 @@ -1,4 +1,4 @@ -# $NetBSD: rc.subr,v 1.108 2022/02/03 20:52:44 alnsn Exp $ +# $NetBSD: rc.subr,v 1.109 2022/02/03 21:02:47 alnsn Exp $ # # Copyright (c) 1997-2011 The NetBSD Foundation, Inc. # All rights reserved. @@ -266,7 +266,7 @@ mount_critical_filesystems_zfs() _mount_es=$? fi - if [ -n "$_mount_es" ]; then + if [ "$_mount_es" != 0 ]; then _mountcrit_es="$_mount_es" fi fi
CVS commit: src/etc
Module Name:src Committed By: alnsn Date: Thu Feb 3 21:02:47 UTC 2022 Modified Files: src/etc: rc.subr Log Message: Compare $_mount_es with 0 To generate a diff of this commit: cvs rdiff -u -r1.108 -r1.109 src/etc/rc.subr Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/etc
Module Name:src
Committed By: alnsn
Date: Thu Feb 3 20:52:44 UTC 2022
Modified Files:
src/etc: rc.subr
Log Message:
Add mount_critical_filesystems_zfs
The new function is similar to mount_critical_filesystems
but it walks through ZFS datasets and mounts matching entries.
To generate a diff of this commit:
cvs rdiff -u -r1.107 -r1.108 src/etc/rc.subr
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/etc/rc.subr
diff -u src/etc/rc.subr:1.107 src/etc/rc.subr:1.108
--- src/etc/rc.subr:1.107 Sat Nov 6 23:11:43 2021
+++ src/etc/rc.subr Thu Feb 3 20:52:44 2022
@@ -1,4 +1,4 @@
-# $NetBSD: rc.subr,v 1.107 2021/11/06 23:11:43 christos Exp $
+# $NetBSD: rc.subr,v 1.108 2022/02/03 20:52:44 alnsn Exp $
#
# Copyright (c) 1997-2011 The NetBSD Foundation, Inc.
# All rights reserved.
@@ -202,6 +202,79 @@ mount_critical_filesystems()
}
#
+# mount_critical_filesystems_zfs
+# Go through the list of critical ZFS mountpoints as provided in
+# the rc.conf(5) variable $critical_filesystems_zfs, checking
+# each one to see if it is mounted, and if it is not, mounting it.
+# It's not an error if file systems prefixed with "OPTIONAL:"
+# aren't zfs mountpoints.
+mount_critical_filesystems_zfs()
+{
+ eval _fslist=\$critical_filesystems_zfs
+ _tab=" "
+ _mountcrit_es=0
+ for _fs in $_fslist; do
+ _optional=false
+ case "$_fs" in
+ OPTIONAL:*)
+ _optional=true
+ _fs="${_fs#*:}"
+ ;;
+ esac
+
+ _dataset=`
+ zfs list -H -o mountpoint,name |
+ while read _line ; do
+_dataset=''
+case "$_line" in
+"${_fs}${_tab}"*)
+ _dataset="${_line#*${_tab}}"
+ ;;
+esac
+if [ -n "$_dataset" ]; then
+ case "$( zfs get -H -o value canmount $_dataset )" in
+ on)
+ echo -n "$_dataset"
+ break ;;
+ *) # noauto|off - dataset isn't supposed to be mounted
+ ;;
+ esac
+fi
+ done`
+
+ if [ -z "$_dataset" ]; then
+ if $_optional; then
+# ignore this error
+print_rc_metadata \
+"note:Optional file system $_fs is not present"
+ else
+printf >&2 "%s\n" "No suitable ZFS dataset found for mountpoint $_fs"
+_mountcrit_es=1
+ fi
+ else
+ _mount_es=
+ case "$( zfs get -H -o value mounted $_dataset )" in
+ yes)
+_mount_es=1
+print_rc_metadata \
+"note:File system $_fs was already mounted"
+;;
+ esac
+
+ if [ -z "$_mount_es" ]; then
+zfs mount "$_dataset" >/dev/null
+_mount_es=$?
+ fi
+
+ if [ -n "$_mount_es" ]; then
+_mountcrit_es="$_mount_es"
+ fi
+ fi
+ done
+ return $_mountcrit_es
+}
+
+#
# check_pidfile pidfile procname [interpreter]
# Parses the first line of pidfile for a PID, and ensures
# that the process is running and matches procname.
CVS commit: src/etc
Module Name:src Committed By: alnsn Date: Thu Feb 3 20:52:44 UTC 2022 Modified Files: src/etc: rc.subr Log Message: Add mount_critical_filesystems_zfs The new function is similar to mount_critical_filesystems but it walks through ZFS datasets and mounts matching entries. To generate a diff of this commit: cvs rdiff -u -r1.107 -r1.108 src/etc/rc.subr Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/share/misc
Module Name:src
Committed By: alnsn
Date: Sun Sep 5 17:29:27 UTC 2021
Modified Files:
src/share/misc: acronyms acronyms-o.real
Log Message:
Move SOB to offensive acronyms.
To generate a diff of this commit:
cvs rdiff -u -r1.310 -r1.311 src/share/misc/acronyms
cvs rdiff -u -r1.9 -r1.10 src/share/misc/acronyms-o.real
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/share/misc/acronyms
diff -u src/share/misc/acronyms:1.310 src/share/misc/acronyms:1.311
--- src/share/misc/acronyms:1.310 Fri Jun 18 21:58:20 2021
+++ src/share/misc/acronyms Sun Sep 5 17:29:27 2021
@@ -1,4 +1,4 @@
-$NetBSD: acronyms,v 1.310 2021/06/18 21:58:20 riastradh Exp $
+$NetBSD: acronyms,v 1.311 2021/09/05 17:29:27 alnsn Exp $
10Q thank you
10X thanks
1337 elite ("leet")
@@ -529,7 +529,6 @@ SNERT snot-nosed egotistical rude teenag
SNES Super Nintendo Entertainment System
SNMP sorry, not my problem
SO significant other
-SOB son of [a] bitch
SOP standard operating procedure
SRS serious
SRSLY seriously
Index: src/share/misc/acronyms-o.real
diff -u src/share/misc/acronyms-o.real:1.9 src/share/misc/acronyms-o.real:1.10
--- src/share/misc/acronyms-o.real:1.9 Sun Aug 9 17:18:47 2020
+++ src/share/misc/acronyms-o.real Sun Sep 5 17:29:27 2021
@@ -1,4 +1,4 @@
-# $NetBSD: acronyms-o.real,v 1.9 2020/08/09 17:18:47 nia Exp $
+# $NetBSD: acronyms-o.real,v 1.10 2021/09/05 17:29:27 alnsn Exp $
ACAB all cops are bastards
AFU all fucked up
AYFKM are you fucking kidding me
@@ -57,6 +57,7 @@ RTFS read the {fine,fucking} source
SFA sweet fuck all
SNAFU situation normal, all fucked up
SNCA shit no one cares about
+SOB son of [a] bitch
SOL shit out [of] luck
SOS same old shit
STFA search the fucking archives
CVS commit: src/share/misc
Module Name:src Committed By: alnsn Date: Sun Sep 5 17:29:27 UTC 2021 Modified Files: src/share/misc: acronyms acronyms-o.real Log Message: Move SOB to offensive acronyms. To generate a diff of this commit: cvs rdiff -u -r1.310 -r1.311 src/share/misc/acronyms cvs rdiff -u -r1.9 -r1.10 src/share/misc/acronyms-o.real Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/dev
Jaromir Dolecek wrote:
> Index: src/sys/dev/ic/bwfmvar.h
> diff -u src/sys/dev/ic/bwfmvar.h:1.9 src/sys/dev/ic/bwfmvar.h:1.10
> --- src/sys/dev/ic/bwfmvar.h:1.9 Sat May 30 13:41:58 2020
> +++ src/sys/dev/ic/bwfmvar.h Sat May 30 15:55:47 2020
> @@ -1,4 +1,4 @@
> -/* $NetBSD: bwfmvar.h,v 1.9 2020/05/30 13:41:58 jdolecek Exp $ */
> +/* $NetBSD: bwfmvar.h,v 1.10 2020/05/30 15:55:47 jdolecek Exp $ */
> /* $OpenBSD: bwfmvar.h,v 1.1 2017/10/11 17:19:50 patrick Exp $ */
> /*
> * Copyright (c) 2010-2016 Broadcom Corporation
> @@ -214,6 +214,11 @@ struct bwfm_softc {
> enum ieee80211_state, int);
>
> int sc_bcdc_reqid;
> +
> + union {
> + struct bwfm_bss_info bss_info;
> + uint8_t padding[BWFM_BSS_INFO_BUFLEN];
> + } sc_bss_buf;
> };
I think you miss
#include
where BWFM_BSS_INFO_BUFLEN is defined.
--
Alex
Re: CVS commit: src/sys/uvm
Taylor R Campbell wrote: > This sounds entirely reasonable. Would you like to draft an > implementation of that? Sure, I can look into this on the weekend. > Presumably it would require writing a sysctl callback function for > vm.swap_encrypt, and would somehow involve kauth, but I'm not sure > offhand what needs to happen beyond that. Perhaps vm.user_va0_disable > can be a source of inspiration. I implemented a similar behaviour for SVS sysctl but I later removed it because SVS sysctl was removed. -- Alex
Re: CVS commit: src/sys/uvm
Taylor R Campbell wrote: > Log Message: > Implement swap encryption. > > Enabled by sysctl -w vm.swap_encrypt=1. If secmodel_securelevel(9) is still a thing, locking down this sysctl at high securelevel may improve our security. Prior to this change, swap devices were readable (even if enrypted with cgd). With this sysctl set to 1, all new swap devices will be encrypted, the only thing to worry about is if it's set back to 0 on a compromised host. Not sure if this makes sense because all files on a compromised host can be read and processes' memory can be probably dumped. Alex
Re: CVS commit: src/sys/dev/ata
David Brownlee wrote: > Just another data point - seeing this same panic on a T480 with the > latest kernel from nyftp Same problem on T470. -- Alex
Re: CVS commit: src/sys/sys
Roy Marples wrote: > On 22/12/2019 22:24, Andrew Doran wrote: > > NetBSD 9.99.29 - struct mount changed. > > Just curious - does our build software cope with 3 digit for the last number? https://twitter.com/needydev/status/1205585787095519234?s=20 -- Alex
Re: CVS commit: src/sys/sys
Andrew Doran wrote: > Log Message: > NetBSD 9.99.28 - cpu_data & UVM changes. Wow, you bump versions faster than I compile new releases. At this pace, we'll get to 9.99.99 in a month or two ;-) -- Alex
Re: CVS commit: src/sys/arch/x86
Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Wed Nov 27 06:24:33 UTC 2019 > > Modified Files: > src/sys/arch/x86/include: cpu.h fpu.h > src/sys/arch/x86/x86: cpu.c fpu.c > > Log Message: > Add a small API for in-kernel FPU operations. > > fpu_kern_enter(); > /* do FPU stuff */ > fpu_kern_leave(); Is it now possible to use AES-NI instructions for cgd disk encryption? -- Alex
CVS commit: src/distrib/common
Module Name:src
Committed By: alnsn
Date: Fri Nov 22 00:27:30 UTC 2019
Modified Files:
src/distrib/common: cgdroot.rc
Log Message:
If gpt label "cgd.conf" contains a valid /etc/cgd file system,
try mounting gpt label "cgdroot" as a root filesystem first and
only mount /dev/cgd0a if that gpt label doesn't exist or fails
to mount.
XXX pullup to 8 and 9.
To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 src/distrib/common/cgdroot.rc
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/distrib/common/cgdroot.rc
diff -u src/distrib/common/cgdroot.rc:1.4 src/distrib/common/cgdroot.rc:1.5
--- src/distrib/common/cgdroot.rc:1.4 Sat Dec 29 13:09:35 2018
+++ src/distrib/common/cgdroot.rc Fri Nov 22 00:27:30 2019
@@ -1,4 +1,4 @@
-# $NetBSD: cgdroot.rc,v 1.4 2018/12/29 13:09:35 alnsn Exp $
+# $NetBSD: cgdroot.rc,v 1.5 2019/11/22 00:27:30 alnsn Exp $
#
# Copyright (c) 2013 Pierre Pronchery
# All rights reserved.
@@ -36,17 +36,20 @@ export EDITOR
umask 022
-mounted=
+# Mount /etc/cgd.
+etc_cgd_mount=
for dev in NAME=cgd.conf /dev/wd0a /dev/ld0a ; do
if mount -o ro $dev /etc/cgd 2>/dev/null ; then
- mounted=$dev
+ etc_cgd_mount=$dev
break
fi
done
-if [ -z "$mounted" ]; then
+if [ -z "${etc_cgd_mount}" ]; then
echo "Could not mount the boot partition" 1>&2
exit 2
fi
+
+# Configure cgd device(s).
/sbin/wsconsctl -d -w splash.enable=0 > /dev/null 2>&1
cgdconfig -C
if [ $? -ne 0 ]; then
@@ -54,13 +57,32 @@ if [ $? -ne 0 ]; then
umount /etc/cgd
exit 2
fi
-mount -o ro /dev/cgd0a /altroot
-if [ $? -ne 0 ]; then
+
+# Select candidates for a root mount.
+root_mounts=
+if [ -z "${etc_cgd_mount##NAME=*}" ]; then
+ root_mounts="NAME=cgdroot /dev/cgd0a"
+else
+ root_mounts=/dev/cgd0a
+fi
+
+# Mount the root filesystem.
+mounted=
+for dev in ${root_mounts} ; do
+ if mount -o ro $dev /altroot 2>/dev/null ; then
+ mounted=$dev
+ break
+ fi
+done
+
+if [ -z "$mounted" ]; then
echo "Could not mount the root partition" 1>&2
cgdconfig -U
umount /etc/cgd
exit 2
fi
+
+# Boot into /altroot.
umount /etc/cgd
/sbin/wsconsctl -d -w splash.enable=1 > /dev/null 2>&1
sysctl -w init.root=/altroot
CVS commit: src/distrib/common
Module Name:src Committed By: alnsn Date: Fri Nov 22 00:27:30 UTC 2019 Modified Files: src/distrib/common: cgdroot.rc Log Message: If gpt label "cgd.conf" contains a valid /etc/cgd file system, try mounting gpt label "cgdroot" as a root filesystem first and only mount /dev/cgd0a if that gpt label doesn't exist or fails to mount. XXX pullup to 8 and 9. To generate a diff of this commit: cvs rdiff -u -r1.4 -r1.5 src/distrib/common/cgdroot.rc Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: Leak Sanitizer - how to suppress leaks
Martin Husemann wrote: > On Sat, Sep 14, 2019 at 01:45:08PM +0200, Kamil Rytarowski wrote: > > Thanks! I will go for __NO_LEAKS ifdef. > > But it is not a good idea to clutter perfectly fine sources with such > #ifdefs and unused/untested/likely broken code (even if it does not affect > the default binaries). I support __NO_LEAKS idea because it documents the fact that there are indended leaks. -- Alex
CVS commit: src/usr.sbin/veriexecgen
Module Name:src Committed By: alnsn Date: Thu Aug 1 08:51:52 UTC 2019 Modified Files: src/usr.sbin/veriexecgen: veriexecgen.c Log Message: Move case 'f' to go right after case 'F'. To generate a diff of this commit: cvs rdiff -u -r1.20 -r1.21 src/usr.sbin/veriexecgen/veriexecgen.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/usr.sbin/veriexecgen
Module Name:src
Committed By: alnsn
Date: Thu Aug 1 08:51:52 UTC 2019
Modified Files:
src/usr.sbin/veriexecgen: veriexecgen.c
Log Message:
Move case 'f' to go right after case 'F'.
To generate a diff of this commit:
cvs rdiff -u -r1.20 -r1.21 src/usr.sbin/veriexecgen/veriexecgen.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/usr.sbin/veriexecgen/veriexecgen.c
diff -u src/usr.sbin/veriexecgen/veriexecgen.c:1.20 src/usr.sbin/veriexecgen/veriexecgen.c:1.21
--- src/usr.sbin/veriexecgen/veriexecgen.c:1.20 Wed Jul 31 15:02:39 2019
+++ src/usr.sbin/veriexecgen/veriexecgen.c Thu Aug 1 08:51:52 2019
@@ -1,4 +1,4 @@
-/* $NetBSD: veriexecgen.c,v 1.20 2019/07/31 15:02:39 alnsn Exp $ */
+/* $NetBSD: veriexecgen.c,v 1.21 2019/08/01 08:51:52 alnsn Exp $ */
/*-
* Copyright (c) 2006 The NetBSD Foundation, Inc.
@@ -36,7 +36,7 @@
#ifndef lint
#ifdef __RCSID
-__RCSID("$NetBSD: veriexecgen.c,v 1.20 2019/07/31 15:02:39 alnsn Exp $");
+__RCSID("$NetBSD: veriexecgen.c,v 1.21 2019/08/01 08:51:52 alnsn Exp $");
#endif
#endif /* not lint */
@@ -468,9 +468,6 @@ main(int argc, char **argv)
Fflag = 1;
break;
#endif /* notyet */
- case 'h':
- usage();
- return EXIT_SUCCESS;
case 'f':
if (strcmp(optarg, "-") == 0) {
v.from_file = stdin;
@@ -485,6 +482,9 @@ main(int argc, char **argv)
v.from_filename = strdup(optarg);
}
break;
+ case 'h':
+ usage();
+ return EXIT_SUCCESS;
case 'o':
v.dbfile = optarg;
break;
CVS commit: src/usr.sbin/veriexecgen
Module Name:src Committed By: alnsn Date: Wed Jul 31 15:02:39 UTC 2019 Modified Files: src/usr.sbin/veriexecgen: veriexecgen.8 veriexecgen.c Log Message: Add an option to read entries from a file. To generate a diff of this commit: cvs rdiff -u -r1.20 -r1.21 src/usr.sbin/veriexecgen/veriexecgen.8 cvs rdiff -u -r1.19 -r1.20 src/usr.sbin/veriexecgen/veriexecgen.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/usr.sbin/veriexecgen
Module Name:src
Committed By: alnsn
Date: Wed Jul 31 15:02:39 UTC 2019
Modified Files:
src/usr.sbin/veriexecgen: veriexecgen.8 veriexecgen.c
Log Message:
Add an option to read entries from a file.
To generate a diff of this commit:
cvs rdiff -u -r1.20 -r1.21 src/usr.sbin/veriexecgen/veriexecgen.8
cvs rdiff -u -r1.19 -r1.20 src/usr.sbin/veriexecgen/veriexecgen.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/usr.sbin/veriexecgen/veriexecgen.8
diff -u src/usr.sbin/veriexecgen/veriexecgen.8:1.20 src/usr.sbin/veriexecgen/veriexecgen.8:1.21
--- src/usr.sbin/veriexecgen/veriexecgen.8:1.20 Tue Jan 8 01:31:49 2019
+++ src/usr.sbin/veriexecgen/veriexecgen.8 Wed Jul 31 15:02:39 2019
@@ -1,4 +1,4 @@
-.\" $NetBSD: veriexecgen.8,v 1.20 2019/01/08 01:31:49 gutteridge Exp $
+.\" $NetBSD: veriexecgen.8,v 1.21 2019/07/31 15:02:39 alnsn Exp $
.\"
.\" Copyright (c) 2006 The NetBSD Foundation, Inc.
.\" All rights reserved.
@@ -27,7 +27,7 @@
.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
.\" POSSIBILITY OF SUCH DAMAGE.
.\"
-.Dd January 8, 2019
+.Dd July 31, 2019
.Dt VERIEXECGEN 8
.Os
.Sh NAME
@@ -37,6 +37,7 @@
.Nm
.Op Fl AaDrSTvW
.Op Fl d Pa dir
+.Op Fl f Pa file
.Op Fl o Pa fingerprintdb
.Op Fl p Pa prefix
.Op Fl t Ar algorithm
@@ -81,6 +82,13 @@ Scan for files in
Multiple uses of this flag can specify more than one directory.
.\" .It Fl F
.\" Try to guess the correct flags for every file.
+.It Fl f Ar file
+Read files from
+.Ar file,
+or if
+.Ar file
+is "-" read from
+.Ar stdin.
.It Fl h
Display the help screen.
.It Fl o Ar fingerprintdb
Index: src/usr.sbin/veriexecgen/veriexecgen.c
diff -u src/usr.sbin/veriexecgen/veriexecgen.c:1.19 src/usr.sbin/veriexecgen/veriexecgen.c:1.20
--- src/usr.sbin/veriexecgen/veriexecgen.c:1.19 Tue Apr 23 22:35:42 2019
+++ src/usr.sbin/veriexecgen/veriexecgen.c Wed Jul 31 15:02:39 2019
@@ -1,4 +1,4 @@
-/* $NetBSD: veriexecgen.c,v 1.19 2019/04/23 22:35:42 sevan Exp $ */
+/* $NetBSD: veriexecgen.c,v 1.20 2019/07/31 15:02:39 alnsn Exp $ */
/*-
* Copyright (c) 2006 The NetBSD Foundation, Inc.
@@ -36,7 +36,7 @@
#ifndef lint
#ifdef __RCSID
-__RCSID("$NetBSD: veriexecgen.c,v 1.19 2019/04/23 22:35:42 sevan Exp $");
+__RCSID("$NetBSD: veriexecgen.c,v 1.20 2019/07/31 15:02:39 alnsn Exp $");
#endif
#endif /* not lint */
@@ -84,6 +84,8 @@ typedef struct veriexecgen_t {
int scan_system_dirs; /* just scan system directories */
int verbose; /* verbosity level */
int stamp; /* put a timestamp */
+ FILE *from_file; /* read from a file or stdin */
+ char *from_filename;
} veriexecgen_t;
/* this struct describes a directory entry to generate a hash for */
@@ -123,7 +125,7 @@ static void
usage(void)
{
(void)fprintf(stderr,
- "usage: %s [-AaDrSTvW] [-d dir] [-o fingerprintdb] [-p prefix]\n"
+ "usage: %s [-AaDrSTvW] [-d dir] [-f file] [-o fingerprintdb] [-p prefix]\n"
"\t\t[-t algorithm]\n"
"\t%s [-h]\n", getprogname(), getprogname());
}
@@ -136,8 +138,15 @@ banner(veriexecgen_t *vp, hash_t *hash_t
(void)printf("Fingerprinting ");
- for (j = 0; search_path[j] != NULL; j++)
- (void)printf("%s ", search_path[j]);
+ if (search_path) {
+ for (j = 0; search_path[j] != NULL; j++)
+ (void)printf("%s ", search_path[j]);
+ } else if (vp->from_file == stdin) {
+ (void)printf("files from stdin ");
+ } else {
+ (void)printf("files from %s ",
+ vp->from_filename ? vp->from_filename : "???");
+ }
(void)printf("(%s) (%s) using %s\n",
vp->all_files ? "all files" : "executables only",
@@ -194,7 +203,41 @@ check_dup(char *filename)
/* add a new entry to the list for `file' */
static void
-add_new_entry(veriexecgen_t *vp, FTSENT *file, hash_t *hash)
+add_new_path_entry(veriexecgen_t *vp, const char *file, hash_t *hash)
+{
+ struct stat sb;
+ struct fentry *e;
+
+ if (stat(file, ) == -1) {
+ gripe(vp, "Cannot stat file `%s'", file);
+ return;
+ }
+
+ if (!vp->all_files && !IS_EXEC(sb.st_mode))
+ return;
+
+ e = ecalloc(1UL, sizeof(*e));
+
+ if (realpath(file, e->filename) == NULL) {
+ gripe(vp, "Cannot find absolute path `%s'", file);
+ return;
+ }
+ if (check_dup(e->filename)) {
+ free(e);
+ return;
+ }
+ if ((e->hash_val = do_hash(e->filename, hash)) == NULL) {
+ gripe(vp, "Cannot calculate hash `%s'", e->filename);
+ return;
+ }
+ e->flags = figure_flags(e->filename, sb.st_mode);
+
+ TAILQ_INSERT_TAIL(, e, f);
+}
+
+/* add a new entry to the list for `file' */
+static void
+add_new_ftsent_entry(veriexecgen_t *vp, FTSENT *file, hash_t *hash)
{
struct fentry *e;
struct stat sb;
@@ -263,13 +306,33 @@ walk_dir(veriexecgen_t *vp, char **searc
strerror(file->fts_errno));
}
} else {
- add_new_entry(vp, file, hash);
+ add_new_ftsent_entry(vp, file, hash);
}
}
fts_close(fh);
}
+/* read files from `file' */
+static void
CVS commit: src/share/misc
Module Name:src
Committed By: alnsn
Date: Sun Jun 23 17:17:18 UTC 2019
Modified Files:
src/share/misc: acronyms.comp
Log Message:
Fix a typo.
To generate a diff of this commit:
cvs rdiff -u -r1.269 -r1.270 src/share/misc/acronyms.comp
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/share/misc/acronyms.comp
diff -u src/share/misc/acronyms.comp:1.269 src/share/misc/acronyms.comp:1.270
--- src/share/misc/acronyms.comp:1.269 Sun Jun 23 16:04:34 2019
+++ src/share/misc/acronyms.comp Sun Jun 23 17:17:18 2019
@@ -1,4 +1,4 @@
-$NetBSD: acronyms.comp,v 1.269 2019/06/23 16:04:34 sevan Exp $
+$NetBSD: acronyms.comp,v 1.270 2019/06/23 17:17:18 alnsn Exp $
3WHS three-way handshake
8VSB 8-state vestigial side band modulation
AA anti-aliasing
@@ -130,7 +130,7 @@ BEDO burst extended data output
BER basic encoding rules
BER bit error {rate,ratio}
BERT boot error record table
-BFB bidirectional forwarding detection
+BFD bidirectional forwarding detection
BFD binary {file,format} descriptor
BFKL big fscking kernel lock
BFS breadth-first search
CVS commit: src/share/misc
Module Name:src Committed By: alnsn Date: Sun Jun 23 17:17:18 UTC 2019 Modified Files: src/share/misc: acronyms.comp Log Message: Fix a typo. To generate a diff of this commit: cvs rdiff -u -r1.269 -r1.270 src/share/misc/acronyms.comp Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/share/misc
Module Name:src Committed By: alnsn Date: Sun Jun 2 20:18:23 UTC 2019 Modified Files: src/share/misc: acronyms.comp Log Message: One more CPS. To generate a diff of this commit: cvs rdiff -u -r1.254 -r1.255 src/share/misc/acronyms.comp Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/sys/dev/cadence/if_cemac.c
Module Name:src Committed By: alnsn Date: Sun May 19 13:32:00 UTC 2019 Modified Files: src/sys/dev/cadence: if_cemac.c Log Message: Kill unused sc variable and fix the build. To generate a diff of this commit: cvs rdiff -u -r1.17 -r1.18 src/sys/dev/cadence/if_cemac.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/share/man/man9
Module Name:src Committed By: alnsn Date: Sat May 18 10:21:03 UTC 2019 Modified Files: src/share/man/man9: secmodel_securelevel.9 Log Message: Don't mention SVS because it can't be changed anymore. To generate a diff of this commit: cvs rdiff -u -r1.18 -r1.19 src/share/man/man9/secmodel_securelevel.9 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/share/man/man9
Module Name:src Committed By: alnsn Date: Sat May 18 10:21:03 UTC 2019 Modified Files: src/share/man/man9: secmodel_securelevel.9 Log Message: Don't mention SVS because it can't be changed anymore. To generate a diff of this commit: cvs rdiff -u -r1.18 -r1.19 src/share/man/man9/secmodel_securelevel.9 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/share/man/man9/secmodel_securelevel.9 diff -u src/share/man/man9/secmodel_securelevel.9:1.18 src/share/man/man9/secmodel_securelevel.9:1.19 --- src/share/man/man9/secmodel_securelevel.9:1.18 Sun Jul 15 05:16:41 2018 +++ src/share/man/man9/secmodel_securelevel.9 Sat May 18 10:21:03 2019 @@ -1,4 +1,4 @@ -.\" $NetBSD: secmodel_securelevel.9,v 1.18 2018/07/15 05:16:41 maxv Exp $ +.\" $NetBSD: secmodel_securelevel.9,v 1.19 2019/05/18 10:21:03 alnsn Exp $ .\" .\" Copyright (c) 2006 Elad Efrat .\" Copyright (c) 2000 Hugh Graham @@ -26,7 +26,7 @@ .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. .\" -.Dd July 14, 2018 +.Dd May 18, 2019 .Dt SECMODEL_SECURELEVEL 9 .Os .Sh NAME @@ -132,8 +132,6 @@ Access to unmanaged memory is denied. Only GPIO pins that have been set at .Em securelevel 0 can be accessed. -.It -SVS (Separate Virtual Space) may not be disabled on platforms that support it. .El .It \ 2 Em Highly secure mode .Bl -bullet
Re: CVS commit: src/distrib/common
m...@netbsd.org wrote: > On Wed, Jan 02, 2019 at 08:42:33PM +0000, Alexander Nasonov wrote: > > https://wiki.netbsd.org/projects/project/transparent-cgd/ > > > > This page describes limitations of cgdroot.kmod. > > > > In my opinion, aes-xts should be added to efi bootloader and paramsfile > > should be merged into boot.cfg. > > If you aren't doing this, it's a *really* good beginner project. > Perhaps adjust the wiki page to be less exploratory and more with do > X,Y,Z and add it to the GSoC-able list? Adding a cgd layer on top of ffs code in libsa isn't straightforward but it should be doable. It's also not clear to me how to pass a raw encryption key from the bootloader to the kernel but I'm not very familiar with that code. Overall it would be a good GCoC project. -- Alex
Re: CVS commit: src/distrib/common
Alexander Nasonov wrote: > m...@netbsd.org wrote: > > Why are we using a memory disk for full disk encryption? I am under the > > impression that it shouldn't be required. > > We use a memory disk because cgdconfig functionality isn't available in > the bootloader. https://wiki.netbsd.org/projects/project/transparent-cgd/ This page describes limitations of cgdroot.kmod. In my opinion, aes-xts should be added to efi bootloader and paramsfile should be merged into boot.cfg. -- Alex
Re: CVS commit: src/distrib/common
m...@netbsd.org wrote: > Why are we using a memory disk for full disk encryption? I am under the > impression that it shouldn't be required. We use a memory disk because cgdconfig functionality isn't available in the bootloader. -- Alex
Re: CVS commit: src/distrib/common
Alexander Nasonov wrote: > Module Name: src > Committed By: alnsn > Date: Sat Dec 29 00:52:11 UTC 2018 > > Modified Files: > src/distrib/common: cgdroot.rc > > Log Message: > Don't hardcode wd0a in cgdroot.kmod, try NAME=cgd.conf and ROOT.a. > > +mounted= > +for dev in NAME=cgd.conf ROOT.a ; do > + if mount -o ro $dev /etc/cgd 2>/dev/null ; then > + mounted=$dev > + fi > +done I was a bit too fast to add the second probe. ROOT.a is always /dev/md0a when booted with 'load cgdroot.kmod'. I can't think of anything other than putting back /dev/wd0a and perhaps adding few more common disks like /dev/ld0a. -- Alex
Re: CVS commit: src/sbin/cgdconfig
Christoph Badura wrote: > Using /etc/cgd/ROOT. has the advantage that the cgd will configure > if the root device changes name, thus upholding POLA. > > E.g. moving disks from a controller that attaches sd(4)s to one that > attaches ld(4)s. I believe you can see that when dd'ing an image from > SDcard to MMC on Pinebook. > > It seems to me that similar behaviour for NAME=label would be more useful > too. dk(4) attachments move around in practice. Yeah, I discovered it the hard way ;-) Perhaps the simplest change would be to pass an unresolved (original) name when composing a paramsfile. E.g. /etc/cgd/NAME=mylabel /etc/cgd/ROOT.e -- Alex
Re: CVS import: src/external/mit/lua/dist
Alexander Nasonov wrote: > Alexander Nasonov wrote: > > Module Name:src > > Committed By: alnsn > > Date: Sun Jul 29 19:46:08 UTC 2018 > > > > Update of /cvsroot/src/external/mit/lua/dist > > In directory ivanova.netbsd.org:/tmp/cvs-serv15569 > > > > Log Message: > > Import Lua 5.3.5. > > Hmm, it didn't go as planned. I ran cvs import from the wrong directory. > How can I revert it? If I import a new vendor branch (call it LUA_5_3_5_proper_import) and then run cvs up -j LUA_5_3_4 -j LUA_5_3_5_proper_import, would it work? -- Alex
Re: CVS import: src/external/mit/lua/dist
Alexander Nasonov wrote: > Module Name: src > Committed By: alnsn > Date: Sun Jul 29 19:46:08 UTC 2018 > > Update of /cvsroot/src/external/mit/lua/dist > In directory ivanova.netbsd.org:/tmp/cvs-serv15569 > > Log Message: > Import Lua 5.3.5. Hmm, it didn't go as planned. I ran cvs import from the wrong directory. How can I revert it? -- Alex
Re: CVS commit: src/sbin/cgdconfig
Robert Elz wrote: > Module Name: src > Committed By: kre > Date: Sat May 5 11:28:44 UTC 2018 > > Modified Files: > src/sbin/cgdconfig: cgdconfig.c > > Log Message: > Check whether the cgd device selected is available to be > configured,that is, not already in use, before requesting > passwords from the user (or elsewhere). Is now a good time to request pullup-8 for this change (with a follow-up fix) and a couple of other small changes? -- Alex
Re: CVS commit: src/usr.sbin/tprof
Thomas Klausner wrote: > Module Name: src > Committed By: wiz > Date: Wed Jul 18 16:50:05 UTC 2018 > > Modified Files: > src/usr.sbin/tprof: tprof.8 tprof.c > > Log Message: > Various improvements to man page. Sync usage. > Does tprof work on amd64? When I tried it a couple of days ago, tprof complained about missing /dev/tprof. I recompiled the kernel with options GPROF pseudo-device tprof then tried creating the device with MAKEDEV. It didn't know about tprof and I had to dig a major number in the code to create it manually. With /dev/tproj available, the tool complained about unsupported cpu. I'm on haswell notebook. It'd be nice to mention /dev/tprof in the man page and list common errors. Alex
Re: CVS commit: src/sbin/cgdconfig
matthew green wrote: > "Alexander Nasonov" writes: > > XXX Using memset for wiping isn't a good idea because memset is likely > > optimised away by gcc. This should be revisited. > > use explicit_memset(3)? Yes, we should change memsets of sensitive buffers to explicit_memset but we also should inspect code for any missing memsets. -- Alex
Re: CVS commit: src/sbin/cgdconfig
Alexander Nasonov wrote: > (gdb) b opendisk1 > (gdb) run -p > Starting program: > /home/alnsn/netbsd-current/clean/src/sbin/cgdconfig/obj/cgdconfig -p > > Breakpoint 1, 0x7f7ff78111f6 in opendisk1 () from /lib/libutil.so.7 > (gdb) x/s $rdi > 0x0: # path=NULL Adding (argc > 0) check before calling opendisk1 fixes the crash. -- Alex
Re: CVS commit: src/sbin/cgdconfig
Robert Elz wrote: > Date:Tue, 8 May 2018 19:15:28 +0100 > From: Alexander Nasonov <al...@yandex.ru> > Message-ID: <20180508180815.GA5990@neva> > > | I think it broke the tool. If you run > | > | cgdconfig -p > | > | it will crash. > > Sorry, I cannot reproduce this, it looks to work OK to me. > > Can you tell me exactly what command you gave and what > "it will crash" means (core dump? other failure? ??) (gdb) b opendisk1 (gdb) run -p Starting program: /home/alnsn/netbsd-current/clean/src/sbin/cgdconfig/obj/cgdconfig -p Breakpoint 1, 0x7f7ff78111f6 in opendisk1 () from /lib/libutil.so.7 (gdb) x/s $rdi 0x0: # path=NULL (gdb) c Program received signal SIGSEGV, Segmentation fault. 0x7f7ff7116880 in strchr () from /lib/libc.so.12 (gdb) bt #0 0x7f7ff7116880 in strchr () from /lib/libc.so.12 #1 0x7f7ff78110a8 in ?? () from /lib/libutil.so.7 #2 0x00202bc3 in configure () #3 0x002074d8 in main () (gdb) disassemble Dump of assembler code for function strchr: 0x7f7ff7116860 <+0>: movabs $0x101010101010101,%r8 0x7f7ff711686a <+10>:movzbq %sil,%rdx 0x7f7ff711686e <+14>:imul $0x80,%r8,%r9 0x7f7ff7116875 <+21>:imul %r8,%rdx 0x7f7ff7116879 <+25>:test $0x7,%dil 0x7f7ff711687d <+29>:jne0x7f7ff71168d5 <strchr+117> 0x7f7ff711687f <+31>:nop => 0x7f7ff7116880 <+32>:mov(%rdi),%rax (gdb) x $rdi 0x0:Cannot access memory at address 0x0 # presumably the path argument If I comment out the if block with opendisk1 inside: (gdb) run -p Starting program: /home/alnsn/netbsd-current/clean/src/sbin/cgdconfig/obj/cgdconfig -p cgdconfig: wrong number of args usage: cgdconfig [-nv] [-V vmeth] cgd dev [paramsfile] cgdconfig -C [-nv] [-f configfile] cgdconfig -G [-nv] [-i ivmeth] [-k kgmeth] [-o outfile] paramsfile cgdconfig -g [-nv] [-i ivmeth] [-k kgmeth] [-o outfile] alg [keylen] cgdconfig -l cgdconfig -s [-nv] [-i ivmeth] cgd dev alg [keylen] cgdconfig -U [-nv] [-f configfile] cgdconfig -u [-nv] cgd [Inferior 1 (process 26827) exited with code 01] -- Alex
Re: CVS commit: src/sbin/cgdconfig
Robert Elz wrote: > Module Name: src > Committed By: kre > Date: Sat May 5 11:28:44 UTC 2018 > > Modified Files: > src/sbin/cgdconfig: cgdconfig.c > > Log Message: > Check whether the cgd device selected is available to be > configured,that is, not already in use, before requesting > passwords from the user (or elsewhere). I think it broke the tool. If you run cgdconfig -p it will crash. Alex
Re: Register new acronym in wtf(6) (Re: CVS commit: src/share/misc)
Kamil Rytarowski wrote: > On 05.05.2018 11:47, Geoff Wing wrote: > > VLC = Variable Length Code (or the video player I use) > > VLA = Variable Length Array > > It has been fixed... Should I move this term to acronyms.comp? Variable Length Code sounds like a good candidate for our acronyms db if it's what you meant. BTW, C99 has a concept similar to VLA. It's called Flexible Array Member (FAM). Perhaps worth adding it too. -- Alex signature.asc Description: PGP signature
Re: CVS commit: src/sys/kern
Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sun Apr 1 19:29:43 UTC 2018 > > Modified Files: > src/sys/kern: subr_prf.c > > Log Message: > Add the ability to prepend a timestamp [ sec.nsec] relative to boottime > in kernel messages if KLOG_TIMESTAMP is enabled. > > + n = snprintf(buf, sizeof(buf), "[% 9jd.%.9ld] ", > + (intptr_t)ts.tv_sec, ts.tv_nsec); Taking more than a quarter of 80-char wide terminal for a timestamp is a bit too much, IMO. Do we really need 9 characters to print seconds? It starts from a single digit on boot and it can increase to 2-3 digits while it's still booting but rarely more than that. Three digits should be enough for nice looking dmesg.boot. As a compromise, can we settle with "% 4jd" for the seconds part? -- Alex
Re: CVS commit: src/sys/netinet
Robert Elz wrote: > I totally agree with this - and it is worse when included in commit logs > wherte it will remain, visible, and actually viewed, forever (unlike even > in a mailing list, which while archived forever, somewhere, usually > falls quickly out of view.) Searching for archived email messages is actually easier for me than grepping a huge cvs log output. After looking at email archives I see that many active developers are "guilty" of committing 'hi dev@' messages. If there are enough people who oppose this, they're welcome to start a new thread on appropriate mailing list. > If you feel the need to (in a friendly, or not-so way) to make sure the > developer who got things wrong knows about it, send e-mail. That's > probably a good idea in any case, their view on how to fix it might be > different than yours. If you need a fix quickly, make it in your local > tree - it is not required that all changes be committed the instant you > finish typing them! If you think it likely that others might be seeing > the same problem, send your fix to the appropriate mailing list. > If whoever broke things then doesn't fix it, or ask you to go ahead and > commit your fix, within a reasonable time, then the fix can just be > committed (but by this time, the use for a "hi xxx" will have long since > passed). Even a very friendly email means that you 1. waiting for a fix and dev@ may feel an urgency to commit the fix 2. you fixed it in a local tree and you will later have to deal with a conflict if dev@ needs to tweak your patch for whatever reason. On the other hand, 'hi dev@' notifies dev@ after the fact. They don't have to do anything to fix things. -- Alex
Re: CVS commit: src/sys/netinet
Taylor R Campbell wrote: > They mean different things. > > `hi dev@' means `FYI, dev@, you broke this, so I'm fixing it'. > > `ok dev@' means `dev@ reviewed and approved this change'. I'm well aware they mean different things. > One connotation of `hi dev@' may be `dev@ is an idiot'; it can be > offputting -- and it's not really necessary to call them out publicly. > Sometimes dev@ has a rapport with the committer and will take it as > good-natured, but a passive observer can't tell the difference between > one colleague joshing another and someone saying `you're an idiot and > I cleaned up your mess'. Module Name:src Committed By: riastradh Date: Thu Aug 14 16:26:21 UTC 2014 Modified Files: src/distrib/sets/lists/modules: md.amd64 Log Message: Add dtrace modules to amd64-xen module set list. Hi [redacted]! There is at least one more commit with 'hi dev@' from you. Alex
Re: CVS commit: src/sys/netinet
m...@netbsd.org wrote: > I seem to recall a discussion about wanting to avoid this type > of commit message (hi dev-name), as it can be seen as excessively > hostile. 'ok rmind@' would definitely be better than 'hi maxv@'. Hostile? I don't think so. I personally quite like it. -- Alex
Re: CVS commit: src/sys/dist/pf/net
Christos Zoulas wrote:
> + if (so == NULL)
> + return -1;
> + if (so->so_cred == NULL) {
> + DPFPRINTF(PF_DEBUG_URGENT,
> + ("%s: so->so_cred == NULL so=%p\n", __func__, so));
> + return -1;
> + }
> pd->lookup.uid = kauth_cred_geteuid(so->so_cred);
> pd->lookup.gid = kauth_cred_getegid(so->so_cred);
> #else
I think it's perfectly normal for an incoming packet to have no
cred. For instance, if that packet is about to be accepted.
pd->lookup.uid and pd->lookup.gid are set to UID_MAX and GID_MAX
at the beginning of the function. They can be probably changed only
if so_cred is set:
if (so == NULL)
return
-1;
if (so->so_cred != NULL) {
pd->lookup.uid = kauth_cred_geteuid(so->so_cred);
pd->lookup.gid = kauth_cred_getegid(so->so_cred);
}
--
Alex
Re: CVS commit: src/sys/dist/pf/net
Christos Zoulas wrote:
> On Feb 19, 10:55pm, al...@yandex.ru (Alexander Nasonov) wrote:
> -- Subject: Re: CVS commit: src/sys/dist/pf/net
>
> | I think it's perfectly normal for an incoming packet to have no
> | cred. For instance, if that packet is about to be accepted.
>
> Yes, that is what I was thinking.
>
> | pd->lookup.uid and pd->lookup.gid are set to UID_MAX and GID_MAX
> | at the beginning of the function. They can be probably changed only
> | if so_cred is set:
> |
> | if (so == NULL)
>
> return -1;
>if (so->so_cred != NULL) {
>
> pd->lookup.uid =
> kauth_cred_geteuid(so->so_cred);
> pd->lookup.gid =
> kauth_cred_getegid(so->so_cred);
> }
>
> Or should return -1 there too without printing anything...
> I have not looked if -1 is handled differently.
>
What does return -1 do? Skip a packet? Reject?
I think it reasonable to set uid to something that can't belong to
a real user and pass control to pf matching engine. I don't know
about pf internals to confirm whether this can work as expected.
So, I'm running the new kernel with my change to pf_socket_lookup
and without your change in ipc_socket2.c. I see randomly rejected
packets in pflog but otherwise it runs fine.
I'll try your change tomorrow.
--
Alex
Re: CVS commit: src/sys/arch/x86/x86
Maxime Villard wrote: > In the first mail, you said that it was better to have a all-or-nothing > sysctl, which is *exactly* what I just committed. Yes, sysctl is better than giving rdtsc to root only. But "better" alone isn't strong enough to count me as a supporter. > In the second one, as a reply to me, you were indeed talking about > more granular control -- but with vdso, which we don't have, so > it's basically not doable. IMO, it's more important to have vdso than to control rdtsc. > (PS: there is no point in having it done in a note section either, since > unpriv user can still create a binary with rdtsc enabled and side channel > the kernel.) Mount all user-writable partitions with noexec. -- Alex
Re: CVS commit: src/sys/arch/x86/x86
Maxime Villard wrote: > In case you didn't notice, this sysctl results directly from the answers I > got, and is not my original plan (about which I changed my mind as a > consequence of the conversation). So now tell me exactly which point I didn't > consider and which reply I ignored. The thread is here?[1], go ahead, I'm > watching you. > > [1] https://marc.info/?l=netbsd-tech-kern=149071535930695=2 Some people (including me) wanted more granular control. Your sysctl doesn't give such control. -- Alex
Re: CVS commit: src
Joerg Sonnenberger wrote: > At least for my evbppc64 build this fails to link because it uses > mktemp and -Wl,--fatal-errors. Does it really need a random file name > and can't just use an easier to predict for debugging name in the > current directory? New change is committed. Alex
Re: CVS commit: src/tests
Juergen Hannken-Illjes wrote: > Module Name: src > Committed By: hannken > Date: Tue May 24 10:16:34 UTC 2016 > > Modified Files: > src/tests/lib/libbpfjit: Makefile > src/tests/net/bpfjit: Makefile > > Log Message: > Disable PAX mprotect to make just-in-time-compile tests work again. > > Ok: Christos Zoulas We're lucky that we run bpfjit in kernel-space only and not e.g. in tcpdump/libpcap. Though, if we implement W^X in the kernel (like OpenBSD recently did), we will have to tackle this problem. Alex
Re: CVS commit: src/sys/net
Christos Zoulas wrote: In article 20141119210214.GA8310@neva, Alexander Nasonov al...@yandex.ru wrote: I don't think SLJIT_UMOD exists. You need to emit SLJIT_SUB after SLJIT_UDIV. This should be pretty straigthforward. But I don't mind if you make a function call for these quite rare instructions. Can you please do it? You are the expert :-) Done. It was easier than emitting SLJIT_SUB because SLJIT_UDIV places the remainder to SLJIT_SCRATCH_REG2. I just SLJIT_MOV'ed it to BJ_AREG. Alex
Re: CVS commit: src/sys/net
Christos Zoulas wrote: Module Name: src Committed By: christos Date: Wed Nov 19 19:34:43 UTC 2014 Modified Files: src/sys/net: bpfjit.c Log Message: Add BPF_MOD/BPF_XOR (untested, needs work) Changes look good. /* + * XXX: Until we support SLJIT_UMOD properly + */ +#undef BPFJIT_USE_UDIV I don't think SLJIT_UMOD exists. You need to emit SLJIT_SUB after SLJIT_UDIV. This should be pretty straigthforward. But I don't mind if you make a function call for these quite rare instructions. Alex
Re: CVS commit: src/sys/net
Alexander Nasonov wrote: Module Name: src Committed By: alnsn Date: Mon Jul 28 07:32:46 UTC 2014 Modified Files: src/sys/net: bpf.c Log Message: Enable net.bpf.jit only if MODULAR and BPFJIT. Tweak a warning about postponed jit activation. MODULAR _or_ BPFJIT. Alex
Re: CVS commit: src/lib/librumpuser
Justin Cormack wrote:
Module Name: src
Committed By: justin
Date: Tue Jul 22 22:41:58 UTC 2014
Modified Files:
src/lib/librumpuser: Makefile rumpfiber.c rumpuser.c rumpuser_int.h
rumpuser_port.h
Added Files:
src/lib/librumpuser: rumpuser_random.c
Log Message:
Clean up random implementation for librumpuser
Use /dev/urandom for platforms without arc4random, not srandom(),
deduplicate code, do not read excessive random bytes
Reviewed by pooka@
...
+int
+rumpuser__random_init(void)
+{
+
+ random_fd = open(random_device, O_RDONLY);
+ if (random_fd 0) {
+ fprintf(stderr, random init open failed\n);
+ return 1;
+ }
return -1 ?
...
#else
#define ET(_v_) return (_v_) ? rumpuser__errtrans(_v_) : 0;
#endif
+ rv = read(random_fd, buf, buflen random_maxread ? random_maxread :
buflen);
+ if (rv 0) {
+ ET(errno);
+ }
I know it's not your code and it's not touched by your change but
ET(errno) looks a bit cryptic. If it appeared as 'return ERRTRANS(errno)',
that would significantly increase readability.
ET(0) can be changed to 'return 0'.
Alex
Re: CVS commit: src/sys/arch/mips/include
Matt Thomas wrote: On Jul 22, 2014, at 12:54 PM, Alexander Nasonov al...@netbsd.org wrote: Module Name:src Committed By: alnsn Date: Tue Jul 22 19:54:55 UTC 2014 Modified Files: src/sys/arch/mips/include: sljitarch.h Log Message: Define SLJIT_CACHE_FLUSH() for mips. Actually, this isn't enough. You need to allocate a page of mapped memory as RWX and then when you are done use pmap_protect to change it to RX followed by pmap_update() and the pmap will automagically sync the page for you. I allocate with the X flag and it seems to work: /* in sljitExecAllocator.c */ return (void *)uvm_km_alloc(module_map, size, PAGE_SIZE, UVM_KMF_WIRED | UVM_KMF_ZERO | UVM_KMF_EXEC); Alex
Re: CVS commit: src/sys/arch/mips/include
Matt Thomas wrote: On Jul 22, 2014, at 2:27 PM, Alexander Nasonov al...@yandex.ru wrote: I allocate with the X flag and it seems to work: /* in sljitExecAllocator.c */ return (void *)uvm_km_alloc(module_map, size, PAGE_SIZE, UVM_KMF_WIRED | UVM_KMF_ZERO | UVM_KMF_EXEC); ok. Then you need don't a hook for cache flushing pmap_protect(vm_map_pamp(module_map), va, size) will do that for you. At least for arm/mips/ppc/vax. (e.g. changing a writeable exec page to read-only automatically causes it exec cleaned). sljit allocates 64K exec chucks which are managed by a special allocator. You need to run pmap_protect for each chunk. I think it's cheaper to flush icache. Alex
Re: CVS commit: src/sys/arch/mips/include
Matt Thomas wrote: On Jul 22, 2014, at 2:40 PM, Alexander Nasonov al...@yandex.ru wrote: Matt Thomas wrote: On Jul 22, 2014, at 2:27 PM, Alexander Nasonov al...@yandex.ru wrote: I allocate with the X flag and it seems to work: /* in sljitExecAllocator.c */ return (void *)uvm_km_alloc(module_map, size, PAGE_SIZE, UVM_KMF_WIRED | UVM_KMF_ZERO | UVM_KMF_EXEC); ok. Then you need don't a hook for cache flushing pmap_protect(vm_map_pamp(module_map), va, size) will do that for you. At least for arm/mips/ppc/vax. (e.g. changing a writeable exec page to read-only automatically causes it exec cleaned). sljit allocates 64K exec chucks which are managed by a special allocator. You need to run pmap_protect for each chunk. I think it's cheaper to flush icache. Maybe. But I'd prefer executable code to be in read-only pages so that malicious code can't be placed in them and executed. I think trading space for security is a valid tradeoff. That would be my preference too but it's not how sljit is designed. The author of sljit doing some refactoring at the moment. I'll ask if he can look into this issue too. Alex
Re: CVS commit: src/sys/arch/arm/include
Matt Thomas wrote: On Jul 22, 2014, at 1:16 PM, Alexander Nasonov al...@netbsd.org wrote: Module Name:src Committed By: alnsn Date: Tue Jul 22 20:16:39 UTC 2014 Modified Files: src/sys/arch/arm/include: sljitarch.h Log Message: Add parentheses around macro arguments. Please use sljit_machdep.h to follow the standard netbsd convention. How strict are we about following this rule? These files were around for a while and there are 29 of them. It's quite a bit of mechanical work to rename them and obsolete old files. Alex
Re: CVS commit: src/external/mit/lua/dist/src
Lourival Pereira Vieira Neto wrote: Module Name: src Committed By: lneto Date: Sat Jul 19 17:11:53 UTC 2014 Modified Files: src/external/mit/lua/dist/src: luaconf.h Log Message: lua(4): preventing division by zero * note: we should raise an error instead of return INTMAX_MAX Userspace lua returns +inf or -inf. So, something like this would be even better than your change: #define luai_numdiv(a,b) \ ((b) != 0 ? (a)/(b) : (a) 0 ? INTMAX_MAX : INTMAX_MIN) Alex
Re: CVS commit: src/sys/modules/lua
Lourival Pereira Vieira Neto wrote: ... Index: src/sys/modules/lua/stdlib.h diff -u src/sys/modules/lua/stdlib.h:1.1 src/sys/modules/lua/stdlib.h:1.2 --- src/sys/modules/lua/stdlib.h:1.1 Wed Oct 16 19:44:57 2013 +++ src/sys/modules/lua/stdlib.h Sat Jul 19 17:10:02 2014 @@ -1,7 +1,7 @@ /* $NetBSD */ /* - * Copyright (c) 2011, Lourival Neto ln...@netbsd.org. + * Copyright (c) 2011-2014, Lourival Neto ln...@netbsd.org. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -36,11 +36,8 @@ #include sys/param.h #include sys/kmem.h -#ifndef _LUA_INCLUDE_STDLIB -#define _LUA_INCLUDE_STDLIB - -#define realloc(ptr, nsize) kmem_alloc(nsize, KM_SLEEP) -#define free(ptr)kmem_free(ptr, osize) +#ifndef _LUA_INCLUDE_STDLIB_ +#define _LUA_INCLUDE_STDLIB_ #define exit(EXIT_FAILURE) return Infamous hack is still in the tree. Alex
Re: CVS commit: src/sys
Lourival Pereira Vieira Neto wrote: Module Name: src Committed By: lneto Date: Sat Jul 19 17:13:22 UTC 2014 Modified Files: src/sys/modules/lua: lua.c src/sys/sys: lua.h Log Message: lua(4): added support for running Lua scripts in intr context Please revert this. You can't make a mechanical change (s/kmem_/kmem_intr_/g and so on) to enable lua in softintr context. You need to design it. What if GC kicks-in in softintr? What if the code tries to load a chunk of new code in softintr? And there are other questions. softint(9): Since software interrupts are a limited resource and run with higher priority than most other LWPs in the system, all block-and-resume activity by a software interrupt must be kept short to allow further processing at that level to continue. By extension, code running with process context must take care to ensure that any lock that may be taken from a software interrupt can not be held for more than a short period of time. The kernel does not allow software interrupts to use facilities or perform actions that are likely to block for a significant amount of time. This means that it's not valid for a software interrupt to sleep on condition variables or to wait for resources to become available (for example, memory). Alex
Re: CVS commit: src
Lourival Pereira Vieira Neto wrote: Module Name: src Committed By: lneto Date: Sat Jul 19 18:38:35 UTC 2014 Modified Files: src/distrib/sets/lists/base: ad.arm ad.mips ad.powerpc md.amd64 md.sparc64 mi shl.mi src/distrib/sets/lists/debug: ad.arm ad.mips ad.powerpc md.amd64 md.sparc64 shl.mi src/doc: CHANGES RESPONSIBLE src/etc/mtree: NetBSD.dist.base NetBSD.dist.earm NetBSD.dist.mips64eb NetBSD.dist.mips64el NetBSD.dist.powerpc64 NetBSD.dist.sparc64 NetBSD.dist.x86_64 src/external/mit/lua/dist: Makefile README src/external/mit/lua/dist/doc: contents.html lua.1 lua.css luac.1 manual.css manual.html readme.html src/external/mit/lua/dist/src: Makefile lapi.c lapi.h lauxlib.c lauxlib.h lbaselib.c lcode.c lcode.h ldblib.c ldebug.c ldebug.h ldo.c ldo.h ldump.c lfunc.c lfunc.h lgc.c lgc.h linit.c liolib.c llex.c llex.h llimits.h lmathlib.c lmem.c lmem.h loadlib.c lobject.c lobject.h lopcodes.c lopcodes.h loslib.c lparser.c lparser.h lstate.c lstate.h lstring.c lstring.h lstrlib.c ltable.c ltable.h ltablib.c ltm.c ltm.h lua.c lua.h luac.c luaconf.h lualib.h lundump.c lundump.h lvm.c lvm.h lzio.c lzio.h src/external/mit/lua/lib/liblua: Makefile shlib_version src/external/mit/lua/usr.bin/luac: Makefile src/lib/lua/gpio: gpio.c src/lib/lua/sqlite: sqlite.c src/libexec/httpd: lua-bozo.c src/share/examples/lua: gpio.lua sqlite.lua src/share/mk: bsd.lua.mk src/sys/external/bsd/acpica/dist/include/platform: acnetbsd.h src/sys/lib/libkern: Makefile.libkern libkern.h src/sys/modules/lua: Makefile lua.c test.lua src/sys/modules/luapmf: Makefile luapmf.c src/sys/modules/luasystm: Makefile luasystm.c test.lua Added Files: src/common/lib/libc/string: strcspn.c strpbrk.c strspn.c src/external/mit/lua/dist/doc: alert.png osi-certified-72x60.png src/external/mit/lua/dist/src: lbitlib.c lcorolib.c lctype.c lctype.h lua.hpp lutf8lib.c Removed Files: src/external/mit/lua/dist: COPYRIGHT HISTORY INSTALL src/external/mit/lua/dist/doc: cover.png lua.html luac.html src/external/mit/lua/dist/etc: Makefile README all.c lua.hpp lua.ico lua.pc luavs.bat min.c noparser.c strict.lua src/external/mit/lua/dist/src: print.c src/external/mit/lua/dist/test: README bisect.lua cf.lua echo.lua env.lua factorial.lua fib.lua fibfor.lua globals.lua hello.lua life.lua luac.lua printf.lua readonly.lua sieve.lua sort.lua table.lua trace-calls.lua trace-globals.lua xd.lua src/lib/libc/string: strcspn.c strpbrk.c strspn.c src/sys/modules/lua: assert.h ctype.h errno.h inttypes.h limits.h locale.h math.h setjmp.h signal.h stdarg.h stddef.h stdio.h stdlib.h string.h Log Message: lua: updated from 5.1 to 5.3 work3 That's not how we update 3rd-party code in the tree. We use cvs import and resolve conflicts afterwards. Alex
Re: CVS commit: src/sys
Lourival Vieira Neto wrote: Hi Alexander, On Sat, Jul 19, 2014 at 4:39 PM, Alexander Nasonov al...@yandex.ru wrote: ... What if GC kicks-in in softintr? It will call kmem_intr_free(9). How many times? What if the code tries to load a chunk of new code in softintr? What if? Have you tried that already? Do I have to? See also my point below about documentation. You can formulate these questions and help to improve this work. Please document softintr interface in Lua (and other bits) so that I can write my first module and formulate my questions and report any problems. Alex
Re: CVS commit: src/sys
Lourival Vieira Neto wrote: On Sat, Jul 19, 2014 at 5:45 PM, Alexander Nasonov al...@yandex.ru wrote: What if GC kicks-in in softintr? It will call kmem_intr_free(9). How many times? It depends on your script. Ok, let me ask a more general question. Do you mix softintr Lua code and regular Lua kernel code in one Lua state? If you do, are you aware that GC running in softintr context can collect objects you created outside of softintr context? Have you thought of that? Alex
Re: CVS commit: src/sys
Lourival Vieira Neto wrote: ... Yes, I do. ... Yes, I am. ... Yes, I have. Good to know. Please document it. Thanks, Alex
Re: CVS commit: src/distrib/sets/lists/debug
Hisashi T Fujinaka wrote: Please put it back the way I had it unless you can prove it's broken with debug turned on. Your commit was wrong, it broke sparc, powerpc, mips and arm with MKSLJIT=yes. Alex
Re: CVS commit: src/lib/librumpuser
Alan Barrett wrote: Some historical uses of __RCSID have an unnecessary #if/#endif wrapper around them, but for new uses, please just write __RCSID(...); without any #if/#endif wrapper. I copy/pasted this block from another file from the same directory. Alex
Re: CVS commit: src/lib/librumpuser
Antti Kantee wrote: To be clear: the objection was to modifying a stable interface without coordination. The hypercall interface is implemented in multiple places outside of the NetBSD tree, including by 3rd parties. Stable interface in -current? How are you supposed to make any significant changes then? As I stated in the private email to Antti, we need to support two versions: stable for users and current for developers. Otherwise, it will block a development of NetBSD if every time you need to make a change in NetBSD-current, you have to wait for a rumpuser bump for stable users even though many of them are outside of NetBSD. In other words, don't rely on NetBSD-current being 100% stable, especially for users outside of NetBSD. I don't know enough details about rump to be certain but would splitting only rumpuser into two versions work? If there were two versions of rumpuser I could tweak the makefile to build cpufunc.c only if MKSLJIT=yes and it would solve the problem because MKSLJIT is no by default on arm. Another reason for splitting rumpuser is because some hypercalls can't be implemented with POSIX API. I don't think we need to support Linux or Solaris in NetBSD tree, especailly if it depends on OS-specific code. Think of it like changing the libc ABI: no matter the merits of the change itself (which they too remain to be discussed), it will be objected to. I got an impression from your private email yesterday that the approach is correct (you didn't say that librumpuser code must be POSIX while the code I sent to you wasn't as it used NetBSD specific sysarch syscall). And because it was a pure addition of a new function and it didn't break NetBSD build, I assumed that it's safe to add it. The only thing I didn't do was rumpuser ABI version bump. Alex
Re: CVS commit: src/lib/librumpuser
Antti Kantee wrote: I think that will be overengineering it, but if you want to come up with a concrete proposal patch, please. I'd simply use discussion and not rushing commits to avoid issues here. The code is in the tree already. I don't need anything else for sljit. The sljit library doesn't support W^X protection. Rumpuser has a way to create an executable page via rumpuser_anonmap(... exec=true). I understand it's not perfect but it's not my area to change memory management in rumpuser. If you don't have time to wait for discussion or coordination, do everything in the privacy of the sljit component. Please teach me how to create a private component. In either case, there's no need for the blocking development drama card. It's not a drama, it's a technical issue. ... For reference, here's what I wrote: === snip === If the problem is syncing icache, the approach is correct. However, I'd argue that the problem is dynamically loading code into a rump kernel, and with that the interface falls somewhat short. What if someone wants W^X? === snip === If you understood that as go ahead, sorry for not being clear, falls short was the comment that I was trying to ease in. My problem is syncing icache, therefore, the approach is correct. I'm not saying that librumpuser must be POSIX. I'm not sure where you're getting that from. rumpuser(3): DESCRIPTION The rumpuser hypercall interfaces allow a rump kernel to access host resources. A hypervisor implementation must implement the routines described in this document to allow a rump kernel to run on the host. The implementation included in NetBSD is for POSIX hosts. ^ ^ and it indeed broke buildrump.sh builds on Linux because sysarch stuff isn't available. There is no way I can make this interface POSIX-compatible because POSIX doesn't specify icache sync as far as I know. What I _am_ saying is that there must be some critical thought going in to the interfaces and their implications. We're several years past the oh I'll just add this because I need it today stage of discovery. Ok, I'll leave it to you to think about it. All I need now is a private component for my change. ... It's a pure addition in the same sense as if you made a pure addition to NetBSD's Xen hypercall interface and made guests unconditionally use it. It would not break the NetBSD build. Would you assume that's a safe change to make? In my case, I could easily build icache in rumpkern conditionally with MKSLJIT if librumpuser didn't break on non NetBSD hosts. Alex
Re: CVS commit: src/lib/librumpuser
Antti Kantee wrote: Use RUMPCOMP_USER_SRCS, several examples under src/sys/rump Thanks for the pointer, will do. That's one more indication that sync icache is the wrong level of problem to represent at the interface level. Existence of __clear_cache is an indication of the opposite. I'm not saying that POSIX should have icache sync routine, they could specify that mprotect syscall that turns on PROT_EXEC should sync icache. But that's no guaranteed by POSIX. If it were a high-level, holistic interface, both the caller and callee would what needs to be done, and the caller could perhaps implement the same with a alternative method. A low-level interface like sync icache for this memory range leaves no room for interpretation, even if it will ever be used for only one purpose. Not quite sure what you're saying because no room for interpretation is a good thing in general and using something for one purpose is even better ;-) -- Alex
Re: CVS commit: src/lib/librumpuser
Antti Kantee wrote: Ok, one more try, this time with an example: * fact: interface will be used to say I have loaded code here, please arrange things so that it can be executed * fact: you want to call the interface sync icache and possess those semantics the example: Let's assume some fictional platform where you need to sign newly loaded code before it can execute. Should the implementation of sync icache on that platform sign code? If not, you can't execute the code, which was the original purpose. If yes, you've failed to implement the interface correctly, because that might not be what the caller wants at all. Will such a platform be supported? Who knows. Is it cause to leave known problems into the interface? Definitely not! You're over generalizing. You can't generate and sign your own code without posing a security risk. This case deserves a special interface, you can't just bring it under umbrella of a single hypercall that does everything to turn memory into code. I'm following a common practice of calling __clear_cache for JIT code except that I wrap it as a hypercall. If you don't want to solve anything except your immediate problem, that's more than fair enough (we've all been there), We've seen many examples of over generalizing too. My need is driven by existing sljit code which follows a common practice of calling __clear_cache() gcc extension. If you want to generalize it, we will need to work with sljit upstream to design a new interface. Alternatively, we can disable jit code on arm and mips and give intel a favor. but it needs to be done without breaking things for everyone else or knowingly introducing suboptimal interfaces that everyone else will suffer from. Everyone else is a multi-dimentional term. Are you referring to users of other operating systems or users of arches where sync_icache is noop or a hypotetical arch where you need to sign code before running it? (well, it's probably not hypotetical anymore, I vaguely remember reading about a similar feature few months ago). As I stated in the earlier email, I can build my rumpkern stuff conditionally if you split librumpuser into NetBSD and non-NetBSD versions. I'm going to check how it will work with a private component. Alex
Re: CVS commit: src/lib/librumpuser
Valery Ushakov wrote: In that case a local rump header plays that role (either including cdefs.h or providing the necessary definition). Yes, I believe that rumpuser_port.h includes sys/cdefs.h. The conditional is a separate issue and yes it shoud be gc'ed. I agree but I wanted to be consistent with other files in the same directory. Alex
Re: CVS commit: src/sys/arch/amd64/conf
matthew green wrote: this comment probably would be nice if it was with all instances of INET6, not just amd64 GENERIC. it certainly will help me a couple of times a year when i end up forgetting... I looked at this. There are 138 files in conf directories with both INET6 and stf in them. It's easier to revert my comment now after Christos changed the code to print #error. Alex
Re: CVS commit: src
Lourival Vieira Neto wrote: Are you aware that we have already changed the language number type? Thus, we have already changed the language itself? If you insist, we can call that Lua', kernel Lua, or whatever you like. It's documented: http://www.lua.org/manual/5.2/manual.html#lua_Number typedef double lua_Number; The type of numbers in Lua. By default, it is double, but that can be changed in luaconf.h. Through this configuration file you can change Lua to operate with another type for numbers (e.g., float or long). But seriously, you can easily implement it. It doesn't even have to be in a Lua core file. You can create a new file in you lua module directory. Yes, we can (how Obama says =). However, I don't see this as a priority. When I see something like this at work, I may set a reminder to follow-up after 6 months. I don't think mutt has this feature. Should I submit a PR instead? Alex
Re: CVS commit: src
Lourival Vieira Neto wrote: I wasn't in that thread at that time. However, I'll carefully read it. If you haven't done so yet, it's a good idea to subscribe to source-changes-d@. Anyway, I think that the missing implementation of luai_numpow() doesn't break anything. Do you have a test to prove that 'return 2^3' doesn't break in the kernel? Is there an issue with lua_error? I don't think that lua_error would work because lua_State isn't passed to luai_numpow(a,b). I wanted to say that you need a stub that breaks in a very noticeable way. I don't think I've created a problem to myself. We discussed it on the list and _we_ come to a conclusion. Note, I don't think that this overflow is a huge problem. The worst that could happen is to have a truncation of a greater number instead of 0. Anyway, I think it must be fixed and that any of the two presented solutions is fine. However, I also have no problem to step back and use 'long long', if _we_ choose to reconsider that. IMHO, the fact that Lua 5.3 is using 'long long' is a good argument for that. I do prefer explicit width type, but my main argument is that 'long long' width could be lesser than 64 bit. Lua is external software and we should keep our copy close to the original. If this sense long long is the best choice. However, Lua 5.3 isn't released yet and Lua team may change their minds. They will have to go through similar problem with strtoll replacement, though. Alex
Re: CVS commit: src
Lourival Pereira Vieira Neto wrote: Module Name: src Committed By: lneto Date: Mon Dec 2 06:07:22 UTC 2013 Modified Files: src/external/mit/lua/dist/src: luaconf.h src/sys/modules/lua: Makefile Removed Files: src/sys/modules/lua: luaconf.h Log Message: merged luaconf.h of kernel and userspace Lua 1. This doesn't look right: #define luai_numpow(a,b)luai_nummul(a,b) 2. If intmax_t is a greater type than int64_t, the below doesn't handle overflow: #define lua_str2number(s,p)((int64_t) strtoimax((s), (p), 10)) I checked Lua code and there is no overflow check. However, I noticed that they detect 0x strings and convert them using strtoul. It should be changed to stroumax. This is in function luaO_str2d in src/lobject.c. 3. Item 1 was in my earlier review of luaconf.h in sys/modules and I see at least one minor item not covered by your new change. Can you please go over my review and make sure all covered? Thanks, Alex
Re: CVS commit: src
Lourival Vieira Neto wrote: Yes, it isn't. But, please note, I didn't change that now. I just merged it in one single file. Though I think we need implement integer exponentiation, I think that is not a priority. IMO, it is a TODO. Well, I assume that any raised issues should be resolved before moving broken stuff around. See the link to my review below. If you wanted to keep this item in TODO list, you'd better picked lua_error rather than lua_mul ;-) 2. If intmax_t is a greater type than int64_t, the below doesn't handle overflow: #define lua_str2number(s,p)((int64_t) strtoimax((s), (p), 10)) I'm considering two approaches: 1) creating an auxiliary function based on strtoimax(): ... 2) creating an auxiliary function based on strtol template I think you created some problems for yourself by using int64_t. I was going to tell you that Lua 5.3 uses long long for 64bit integers but I saw your question on lua-l about it. I didn't mind using long long in the kernel when we discussed that topic but some other people convinced you to use explicit width type ;-) 3. Item 1 was in my earlier review of luaconf.h in sys/modules and I see at least one minor item not covered by your new change. Can you please go over my review and make sure all covered? Sorry, I've missed that. Which review? Are you talking about the changing lua_Number to int64_t thread? http://mail-index.netbsd.org/source-changes-d/2013/10/22/msg006172.html Alex
Re: CVS commit: src
+./usr/lib/librumpkern_sljit.so base-rump-shlib rump +./usr/lib/librumpkern_sljit.so.0 base-rump-shlib rump +./usr/lib/librumpkern_sljit.so.0.0 base-rump-shlib rump A similar change was sitting in my local tree for quite a while but sljit API isn't yet stable enough to wrap it into a DSO. I kept bpbfjit and libsljit private (LIBISPRIVATE=yes) and used them only for libsljit and libbpfjit tests. Is it possible to do something similar in rump framework? Alex
Re: CVS commit: src/sys/rump/kern
Martin Husemann wrote:
Log Message:
sljit is only available on very few architectures, so do not try to build
it on all.
We have a special MKSLJIT variable. It's enabled by default on the three
arches you listed below but it can also be turned on on arm and mips.
Alex
To generate a diff of this commit:
cvs rdiff -u -r1.6 -r1.7 src/sys/rump/kern/Makefile.rumpkerncomp
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/sys/rump/kern/Makefile.rumpkerncomp
diff -u src/sys/rump/kern/Makefile.rumpkerncomp:1.6
src/sys/rump/kern/Makefile.rumpkerncomp:1.7
--- src/sys/rump/kern/Makefile.rumpkerncomp:1.6 Sat Nov 16 01:39:18 2013
+++ src/sys/rump/kern/Makefile.rumpkerncomp Sat Nov 16 10:34:47 2013
@@ -1,9 +1,15 @@
-#$NetBSD: Makefile.rumpkerncomp,v 1.6 2013/11/16 01:39:18 rmind Exp $
+#$NetBSD: Makefile.rumpkerncomp,v 1.7 2013/11/16 10:34:47 martin Exp $
#
.include bsd.own.mk
-RUMPKERNCOMPS= crypto sljit tty z
+RUMPKERNCOMPS= crypto tty z
+
+.if ${MACHINE_ARCH} == i386 || \
+${MACHINE_ARCH} == x86_64 || \
+${MACHINE_ARCH} == sparc
+RUMPKERNCOMPS+= sljit
+.endif
.if ${MKZFS} != no
RUMPKERNCOMPS+=solaris
--
