Re: CVS commit: src/etc

2022-03-11 Thread Alexander Nasonov
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

2022-02-20 Thread Alexander Nasonov
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

2022-02-20 Thread Alexander Nasonov
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

2022-02-20 Thread Alexander Nasonov
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

2022-02-20 Thread Alexander Nasonov
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

2022-02-20 Thread Alexander Nasonov
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

2022-02-20 Thread Alexander Nasonov
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

2022-02-06 Thread Alexander Nasonov
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

2022-02-06 Thread Alexander Nasonov
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

2022-02-06 Thread Alexander Nasonov
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

2022-02-05 Thread Alexander Nasonov
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

2022-02-05 Thread Alexander Nasonov
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

2022-02-04 Thread Alexander Nasonov
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

2022-02-03 Thread Alexander Nasonov
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

2022-02-03 Thread Alexander Nasonov
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

2022-02-03 Thread Alexander Nasonov
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

2022-02-03 Thread Alexander Nasonov
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

2022-02-03 Thread Alexander Nasonov
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

2022-02-03 Thread Alexander Nasonov
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

2021-09-05 Thread Alexander Nasonov
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

2021-09-05 Thread Alexander Nasonov
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

2020-05-30 Thread Alexander Nasonov
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

2020-05-11 Thread Alexander Nasonov
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

2020-05-10 Thread Alexander Nasonov
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

2020-04-29 Thread Alexander Nasonov
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

2019-12-22 Thread Alexander Nasonov
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

2019-12-21 Thread Alexander Nasonov
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

2019-11-27 Thread Alexander Nasonov
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

2019-11-21 Thread Alexander Nasonov
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

2019-11-21 Thread Alexander Nasonov
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

2019-09-14 Thread Alexander Nasonov
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

2019-08-01 Thread Alexander Nasonov
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

2019-08-01 Thread Alexander Nasonov
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

2019-07-31 Thread Alexander Nasonov
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

2019-07-31 Thread Alexander Nasonov
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

2019-06-23 Thread Alexander Nasonov
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

2019-06-23 Thread Alexander Nasonov
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

2019-06-02 Thread Alexander Nasonov
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

2019-05-19 Thread Alexander Nasonov
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

2019-05-18 Thread Alexander Nasonov
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

2019-05-18 Thread Alexander Nasonov
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

2019-01-02 Thread Alexander Nasonov
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

2019-01-02 Thread Alexander Nasonov
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

2018-12-29 Thread Alexander Nasonov
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

2018-12-29 Thread Alexander Nasonov
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

2018-12-27 Thread Alexander Nasonov
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

2018-07-29 Thread Alexander Nasonov
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

2018-07-29 Thread Alexander Nasonov
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

2018-07-27 Thread Alexander Nasonov
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

2018-07-18 Thread Alexander Nasonov
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

2018-05-09 Thread Alexander Nasonov
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

2018-05-09 Thread Alexander Nasonov
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

2018-05-09 Thread Alexander Nasonov
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

2018-05-08 Thread Alexander Nasonov
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)

2018-05-05 Thread Alexander Nasonov
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

2018-04-12 Thread Alexander Nasonov
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

2018-03-31 Thread Alexander Nasonov
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

2018-03-31 Thread Alexander Nasonov
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

2018-03-29 Thread Alexander Nasonov
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

2018-02-19 Thread Alexander Nasonov
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

2018-02-19 Thread Alexander Nasonov
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

2017-10-04 Thread Alexander Nasonov
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

2017-10-03 Thread Alexander Nasonov
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

2016-11-07 Thread Alexander Nasonov
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

2016-05-24 Thread Alexander Nasonov
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

2014-11-20 Thread Alexander Nasonov
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 :-)

Sure, will do.

-- 
Alex


Re: CVS commit: src/sys/net

2014-11-20 Thread Alexander Nasonov
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

2014-11-19 Thread Alexander Nasonov
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

2014-07-28 Thread Alexander Nasonov
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

2014-07-23 Thread Alexander Nasonov
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

2014-07-22 Thread Alexander Nasonov
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

2014-07-22 Thread Alexander Nasonov
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

2014-07-22 Thread Alexander Nasonov
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

2014-07-22 Thread Alexander Nasonov
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

2014-07-19 Thread Alexander Nasonov
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

2014-07-19 Thread Alexander Nasonov
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

2014-07-19 Thread Alexander Nasonov
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

2014-07-19 Thread Alexander Nasonov
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

2014-07-19 Thread Alexander Nasonov
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

2014-07-19 Thread Alexander Nasonov
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

2014-07-19 Thread Alexander Nasonov
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

2014-07-02 Thread Alexander Nasonov
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

2014-06-17 Thread Alexander Nasonov
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

2014-06-17 Thread Alexander Nasonov
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

2014-06-17 Thread Alexander Nasonov
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

2014-06-17 Thread Alexander Nasonov
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

2014-06-17 Thread Alexander Nasonov
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

2014-06-17 Thread Alexander Nasonov
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

2014-06-12 Thread Alexander Nasonov
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

2013-12-04 Thread Alexander Nasonov
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

2013-12-03 Thread Alexander Nasonov
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

2013-12-02 Thread Alexander Nasonov
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

2013-12-02 Thread Alexander Nasonov
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

2013-11-16 Thread Alexander Nasonov
 +./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

2013-11-16 Thread Alexander Nasonov
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
 


-- 


Re: CVS commit: src/usr.sbin/npf/npftest

2013-11-16 Thread Alexander Nasonov
Mindaugas Rasiukevicius wrote:
 Module Name:  src
 Committed By: rmind
 Date: Sat Nov 16 01:41:43 UTC 2013
 
 Modified Files:
   src/usr.sbin/npf/npftest: Makefile
   src/usr.sbin/npf/npftest/libnpftest: Makefile npf_bpf_test.c
 
 Log Message:
 Enable bpfjit for npftest.

It breaks when MKSLJIT=no. I fixed the build already but I don't know
if something else should be changed in npf_bpf_test.c file.

Alex


Re: CVS commit: src/sys/rump/kern

2013-11-16 Thread Alexander Nasonov
Martin Husemann wrote:
 I copied the .if from src/sys/modules/Makefile - please feel free to
 fix both instances. But arm is missing machine/sljitarch.h, so it would
 not compile.

I don't think that sljit supports all arms. If you want bpfjit on arm (or
mips) you should build with MKSLJIT=yes. Default is no on these arches.

Alex



Re: CVS commit: src/sys/rump/kern

2013-11-16 Thread Alexander Nasonov
Martin Husemann wrote:
 I copied the .if from src/sys/modules/Makefile - please feel free to
 fix both instances. But arm is missing machine/sljitarch.h, so it would
 not compile.

I now see where the problem is. I listed those three arches because they
support modules but other sljit arches don't always have modules.

Is there a make variable to check whether modules are supported?

Alex


Re: CVS commit: src/sys/modules/lua

2013-10-22 Thread Alexander Nasonov
Alexander Nasonov wrote:
  +#define exit(EXIT_FAILURE) return
 
 You only need to make a change in one place in ldo.c:
 
 @@ -105,7 +110,11 @@ void luaD_throw (lua_State *L, int errco
lua_unlock(L);
G(L)-panic(L);
  }
 +#if defined(_KERNEL)
 +panic(luaD_throw(), errcode=%d, errcode);
 +#else
  exit(EXIT_FAILURE);
 +#endif
}
  }

I'm having a private discussion with Chris Badura about the above panic
call.

He made me realise that I assume that Lua kernel framework always
executes scripts in a protected environment (pcall or xpcall) but I
don't actually know whether it's the case. If it's not, than Lua script
can indeed panic the kernel.

On the other hand, ignoring it and continuing as if nothing happened is
even crazier idea.

We just need to make sure that all entry points to Lua are protected and
hope that the above panic will never trigger.

Alex


Re: CVS commit: src/sys/modules/lua

2013-10-22 Thread Alexander Nasonov
Christoph Badura wrote:
 On Tue, Oct 22, 2013 at 09:25:19AM +0100, Alexander Nasonov wrote:
  We just need to make sure that all entry points to Lua are protected and
  hope that the above panic will never trigger.
 
 Actually, I would prefer if that call to panic wasn't there at all.
 Instead the script/state should be aborted noisily.

I have a simple code you can play with in userspace.

#include lua.h
#include lauxlib.h

const char prog[] =
print'hi'\n
error'throw'\n
print'dead code'\n;

int main()
{
lua_State *L;

L = luaL_newstate();
luaL_openlibs(L);

if (luaL_loadstring(L, prog) == 0) {
// Dangerous:
lua_call(L, 0, 0); // no args and no return values
// Protected call should be safe:
//lua_pcall(L, 0, 0, 0);
}

lua_close(L);
return 0;
}

If you link it with vanilla Lua, you'll get 

$ gcc -I/usr/pkg/include/lua-5.1/ -O -g lua-throw.c  -L/usr/pkg/lib 
-Wl,-rpath,/usr/pkg/lib  -llua5.1
$ ./a.out
hi
PANIC: unprotected error in call to Lua API ([string print'hi'...]:2: throw)

If you comment out exit(EXIT_FAILURE) in luaD_throw(), you'll get a
crash because Lua will try to execute the third line while its state
is inconsistent:

$ gcc -I/usr/pkg/include/lua-5.1/ -O -g lua-throw.c  -L `pwd`/lua-5.1.5/src/  
-llua -lm
$ gdb ./a.out
(gdb) run
Starting program: /home/alnsn/src/test/a.out
hi
PANIC: unprotected error in call to Lua API ([string print'hi'...]:2: throw)

Program received signal SIGSEGV, Segmentation fault.
0xb7d8 in luaD_precall ()
(gdb) bt
#0  0xb7d8 in luaD_precall ()
#1  0x00011084 in luaV_execute ()
#2  0x in ?? ()

You really need this panic or KASSERT even if you make sure all your
scripts are properly isolated. You can achieve these in two ways:

1. Set a panic handler with lua_atpanic() which jumps to your safety
   point (if your handler returns, the control is passed to the line
   in question).
2. Make sure that all scripts are executed using lua_pcall. For
   instance, code that loads kmods written in Lua can do this
   seamlessly.


While I agree that it's good to have a protection from fool scripts, but
being able to control loading of scripts manually have advantages too.

The link below is a skeleton for bpfjit generator. It doesn't yet
generate a real code but it creates a Lua array of instructions, passes
it from C to Lua, creates sljit compiler object and gerenates a simple
function inside Lua script, then returns that object to C where it's
casted to C object. If you look at interface, you won't see Lua at all,
it's hidden from public.

https://github.com/alnsn/luaSljit/blob/master/examples/bpfjit/bpfjit.c

Alex


  1   2   >