Re: unattended install

[Taylor R Campbell]

> Date: Wed, 17 Apr 2024 15:12:21 +0200
> From: "Enrico Weigelt, metux IT consult" 
> 
> is there any way of unattended installation (eg. from the ISO) ?
> 
> Rationale: I need to create VM images by a build pipeline (on kvm).

If there isn't an image that already serves your needs, the
distrib/utils/embedded/mkimage script is how we would approach this on
systems where the goal isn't partly to test interactive installation
with sysinst:

https://nxr.netbsd.org/xref/src/distrib/utils/embedded/mkimage?r=1.82

Currently we make Arm, RISC-V, and some other images this way, with
config files under distrib/utils/embedded/conf/, like this one:

https://nxr.netbsd.org/xref/src/distrib/utils/embedded/conf/arm64.conf?r=1.16
https://nxr.netbsd.org/xref/src/distrib/utils/embedded/conf/evbarm.conf?r=1.42

Here's how we invoke it in the build (${.TARGET} in this rule will be
something like `smp_arm64' for arm64.img):

https://nxr.netbsd.org/xref/src/etc/etc.evbarm/Makefile.inc?r=1.131#80

There are also amd64 and i386 config files, not currently used in the
NetBSD release build -- the x86 live images are built another way, but
you can use mkimage for x86 VM images using amd64.conf or i386.conf.

The mkimage script doesn't have to run under NetBSD -- you can run it
on another system using NetBSD's cross-build toolchain built with
`build.sh tools'.

Re: Please forgive a blatant plug: I reviewed v10 for the Reg

[Taylor R Campbell]

Hi adr,

Liam provided valuable feedback in both reviews, and if anything we
haven't put enough effort into smoothing out the rough edges Liam
pointed out, like figuring out why command-line editing and PATH
weren't set up right out of the box.  There's always room for
improvement, and our documentation is sometimes hard to follow,
missing parts, or too wordy in places.

This feedback helps us to improve the out-of-the-box experience for
users, fix unnecessarily confusing parts of the experience, and
identify where the documentation is lacking or hard to find.

Gatekeeping NetBSD on the basis of prior expertise is not good for the
community, and not good for the project.  sysinst is supposed to be a
tool to help you, not a test of your patience or knowledge.

We would appreciate it if you toned down your criticism of a new user
and their honest feedback about the experience so we as a community
don't discourage other users and further feedback as we continue to
improve NetBSD.

Thanks,
-Riastradh, NetBSD core team

Re: Call for testing: Diagnostics for broken downloads from NetBSD.org CDN

[Taylor R Campbell]

> Date: Sat, 17 Jun 2023 10:24:26 +
> From: Taylor R Campbell 
> 
> So if you catch a partially failed download with, e.g.,
> 
> curl -H 'Fastly-Debug: true' -D header.txt -O https://archive.NetBSD.org/...
> 
> then it would be helpful to us if you could pass on the header.txt
> file that curl produces, along with the exact length of the data that
> curl was able to retrieve -- either by email, or by a PR filed with
> gnats at https://gnats.NetBSD.org or send-pr(1).

Addendum: please do this only if you were going to download something
anyway -- one problem may be that the backend is overloaded, in which
case a horde of people testing downloads that they wouldn't have
otherwise downloaded might make the problem worse!

Call for testing: Diagnostics for broken downloads from NetBSD.org CDN

[Taylor R Campbell]

Hi folks,

We've been hearing reports of intermittent issues with broken partial
downloads via our content delivery network, Fastly, from
cdn.NetBSD.org, nycdn.NetBSD.org, and/or archive.NetBSD.org,
particularly of large files like the installer images.

These issues are hard to track down because Fastly might choose a
different cache each time, and maybe one cache has a problem while
other nearby ones don't.

With the HTTP header field `Fastly-Debug: true', Fastly will return
some extra data in the response header that might help diagnose the
problem.

So if you catch a partially failed download with, e.g.,

curl -H 'Fastly-Debug: true' -D header.txt -O https://archive.NetBSD.org/...

then it would be helpful to us if you could pass on the header.txt
file that curl produces, along with the exact length of the data that
curl was able to retrieve -- either by email, or by a PR filed with
gnats at https://gnats.NetBSD.org or send-pr(1).

Thanks,
-Riastradh

Re: touch screen support

[Taylor R Campbell]

> Date: Sun, 28 May 2023 23:57:38 +0100
> From: Dave Tyson 
> 
> [60.731037] uhidev0 at uhub0 port 1 configuration 1 interface 0
> [60.731037] uhidev0: wch.cn (0x1a86) USB2IIC_CTP_CONTROL (0xe5e3),
> rev 0.01/0.00, addr 2, iclass 3/0
> [60.751042] uhidev0: 3 report ids
> [60.751042] uts0 at uhidev0 reportid 1
> [60.751042] uts0: autoconfiguration error: touchscreen has no range
> report
> [60.761045] uhid0 at uhidev0 reportid 2: input=0, output=0,
> feature=1
> [60.771044] uhid1 at uhidev0 reportid 3: input=0, output=0,
> feature=256

Can you:

1. drop into the bootloader prompt,
2. do `userconf disable uts' at the bootloader prompt,
3. boot,
4. confirm the device shows up as uhid(4) instead of uts(4) now, and
5. share `usbhidctl -f /dev/uhidN -v -r' output?

Also maybe:

6. file a PR to track this?

Re: TOTP apps, and WebAuthn recommended devices?

[Taylor R Campbell]

> Date: Sat, 25 Mar 2023 08:36:36 -0400
> From: Greg Troxel 
> 
> Thanks very much for the detailed response.
> 
> One thing that's not 100% clear to me:
> 
>   One device (plus a second one as a backup!)
> 
> 
> A device can fail or be lost, so the backup concept is obvious, and
> perhaps should extend to a third.
> 
> Are the backup devices independent in that you
> 
>   enroll device A on a site
> 
>   enroll device B on the same site
> 
> and then either one will be accpeted by the site to login, and they
> otherwise don't have anything to do with each other?  I mean no transfer
> of keymat, or other linkage.
> 
> So therefore one could have a secondary backup in a place far away
> that's somewhat hard to get to, and when visiting it every few months,
> enroll that backup as an additional key in the sites that were added to
> the working device (carried with you) and the primary backup.

That is all correct.  Security key enrollments are independent.


P.S. There is also a proposal for a scheme that does allow devices to
 be linked in a way that preserves the privacy properties but
 doesn't require you to have the backup key itself to enroll it --
 only to log in with it -- but it's not there yet:
 
https://www.yubico.com/blog/yubico-proposes-webauthn-protocol-extension-to-simplify-backup-security-keys/)
 

Re: TOTP apps, and WebAuthn recommended devices?

[Taylor R Campbell]

> Date: Thu, 23 Mar 2023 09:51:17 -0400
> From: Greg Troxel 
> 
> One thing is TOTP.  There are Android apps from f-droid (which suits me
> but not everyone), and there is vaultwarden which should allow bitwarden
> to do TOTP.  I wonder if there are good TOTP programs in pkgsrc and what
> people recommend.

TOTP -- also called `authenticator app', and usually presented with a
QR code and an optional base32 string as the key -- is a very simple
standard protocol defined in RFC 6238, with reference to RFC 4226.

security/oath-toolkit is a command-line tool to manage a collection of
TOTP keys.  security/py-otp is a very simple Python library.  I use a
fragment of Python code with security/py-cryptography[1], from before
py-otp was added to pkgsrc.

For Android and iOS, there's also a free software app called FreeOTP
from Red Hat (in Google Play and F-Droid): https://freeotp.github.io/

In Firefox, the Bitwarden browser extension can automagically handle
TOTP keys.


However, you should be aware that _TOTP is vulnerable to phishing_.


If you inadvertently open gmai1.com instead of gmail.com and are shown
what looks exactly like a Google login page, entering a TOTP (or SMS)
code alongside your password gives the adversary everything they need
to break into your account.

In contrast, using only password + U2F/FIDO/webauthn security key
defeats phishing.

It defeats phishing because the browser cryptographically binds the
web site origin (gmai1.com vs gmail.com) into the protocol between the
security key and the server.

The user experience of U2F/FIDO/webauthn is also better because you
just tap a button -- no need to keep state on a phone, configure keys
into it, or copy & paste magic codes from one device to another.

One device (plus a second one as a backup!) works for as many sites as
you want, and for as many different accounts at each site as you want
(work, personal, whatever).  Directory of sites with support:
https://www.dongleauth.com/

For most uses, the words U2F, FIDO, FIDO2, and webauthn all mean
essentially the same thing, so I'll just say FIDO here.


> The other thing is WebAuthn which is apparently the new U2F.  I'd like
> to get some security keys for this, probably 3 (carry, non-carried
> backup, offsite cold storage) for long-term availability.  What devices
> are recommended, meeting:

All FIDO USB security keys will work out of the box on all modern
desktop/laptop platforms (including NetBSD 9), and all FIDO NFC/USB
security keys will work out of the box on all modern smartphones from
the last four years or so, in all major browsers.

You should pick according to the interface and form factor you need
(and what you can easily find nearby or get shipped to you).

A good choice to start with is NFC and USB-A or USB-C, so you can use
the same key with a phone and a laptop, like these:

https://www.yubico.com/product/security-key-nfc-by-yubico-black/
https://www.yubico.com/product/security-key-c-nfc-by-yubico-black/

Typical interfaces:

- USB-A
- USB-C
- Lightning (Apple proprietary)
- NFC
- smartcard contact
- Bluetooth LE

Typical form factors:

- keychain-oriented -- like a house or car key but with USB

  https://www.yubico.com/product/security-key-nfc-by-yubico-black/
  https://solokeys.com/products/solo-tap-usb-a-preorder?variant=27688204271680
  https://shop.nitrokey.com/shop/product/nkfi2-nitrokey-fido2-55
  https://www.ftsafe.com/Products/FIDO/NFC
  https://store.google.com/us/product/titan_security_key?hl=en-US

- nano -- barely sticks out of the USB port, so you can just keep it
  plugged into your laptop all the time

  https://www.yubico.com/product/yubikey-5-nano/
  
https://solokeys.com/products/somu-tiny-security-key-two-factor-authentication-u2f-and-fido2-usb-a

- credit card -- NFC/smartcard only, not well supported outside
  Windows yet, not a lot of retail market, seems to be mostly for
  corporate id badge deployments

  https://neowave.fr/en/products/fido-range/badgeo-nfc-fido-2/
  https://shop.cryptnox.com/products/cryptnox-fido-2-card
  https://gotrustid.com/products-idem-card/ (has battery for BLE)
  https://www.hidglobal.com/products/crescendo

- other

  https://shop.ledger.com/products/ledger-nano-s-plus
  https://authentrend.com/atkey-card/

You can vet a product with the FIDO certification database:
https://fidoalliance.org/certification/fido-certified-products/

You can try a key out without risking locking yourself out of any
accounts here: https://demo.yubico.com/

If you want to add support to a web site: https://webauthn.io/


Answering some specific concerns you had:

>   allow enrolling in a bunch of different sites (dozenish, not 1000s)

FIDO keys have no limit on the number of sites.  There is no state
stored on the device[2], except for a count of the number of
signatures it has made, which is revealed to the server so the server
can detect cloned devices.

>   work on NetBSD with firefox (netbsd 9 amd64 at the moment)

All certified FIDO USB keys 

Re: -10.0_BETA panics when system is rebooting

[Taylor R Campbell]

> Date: Fri, 6 Jan 2023 22:04:26 +0100
> From: BERTRAND Joël 
> 
> [ 856605,576197] uvm_fault(0x8190e240, 0xe80ea992e000, 4) -> e

This indicates that the kernel tried to execute code in the page at
0xe80ea992e000in kernel virtual address space (VM_PROT_EXECUTE=4),
but that led to a page fault.

> [ 856605,576197] fatal page fault in supervisor mode
> [ 856605,576197] trap type 6 code 0x11 rip 0xe80ea992e498 cs 0x8
> rflags 0x10246 cr2 0xe80ea992e498 ilevel 0x6 rsp 0xb504492c29f8

trap type 6 = T_PAGEFLT (same as `page fault' in line above)
code 0x11 = PGEX_P (0x01, page was present)
  | PGEX_I (0x10, exception during instruction fetch)
rip = 0xe80ea992e498, the instruction address which led to fault
cr2 = 0xe80ea992e498, the faulting address (same as rip, because
  attempting to fetch the instruction faulted)

> [ 856605,576197] ?() at e80ea992e498
> [ 856605,576197] priqclose() at netbsd:priqclose+0x4a

If you disassemble priqclose that might help identify what instruction
led to a call to e80ea992e498.  However, I don't see a lot of
indirect calls in priqclose, so there is likely something else wrong
here.

> [ 856605,000596] acpiout5 at acpivga0 (DD.5961966] dump device bad
> 
>   I don't understand last line as dmesg indicates :
> [ 3,718620] boot device: raid0
> [ 3,718620] root on raid0a dumps on raid0b
> 
>   Unfortunately, I have replaced netbsd and netbsd.dbg by two new kernels
> and I cannot debug. I don't know if this kind of panic is already known.
> Next time I can reboot this server, I will try to obtain more information.

You might want to verify whether crash dumps work on your system by
using the crashme sysctl knobs to force a crash:

# sysctl -w debug.crashme_enable=1
# sysctl -w debug.crashme.panic=1

(Again: strongly recommend trying this in a VM that simulates your
setup -- e.g., raid on virtual disks in qemu -- so you can test it
without affecting production use!)

Re: entropy-file

[Taylor R Campbell]

> Date: Thu, 18 Jun 2020 09:15:55 +0300
> From: Dima Veselov 
> 
> I have a small question why we have /etc/entropy-file in boot.cfg after
> every install but it always tries to update to /var/db/entropy-file on
> every build of -STABLE?

The idea of this logic in sysinst was to ensure that the entropy file
is on the root file system so that the bootloader can get to it.

The default location is /var/db/entropy-file, but if /var is on a
separate file system, the bootloader won't be able to get at it.  So
in that case, sysinst tries to add

random_file=/etc/entropy-file

to /etc/rc.conf, and

rndseed /etc/entropy_file

to boot.cfg.

(It's not a huge problem if the bootloader can't get at the seed --
/etc/rc.d/random_seed runs after mountcritlocal, so as long as /var is
in critical_filesystems_local as it is by default, the random seed
will be used, just a bit later at boot than it would have been if the
bootloader could get it.)

However, you say

> but it always tries to update to /var/db/entropy-file

Can you expand on this?  Can you confirm that /etc/rc.conf and
boot.cfg both agree on /etc/entropy-file, and can you say what
symptoms suggest that the system is nevertheless trying to use
/var/db/entropy-file?

Re: Random lockups on an email server - possibly kern/50168

[Taylor R Campbell]

   Date: Mon, 11 Apr 2016 10:01:13 -0400
   From: "D'Arcy J.M. Cain" 

   Crash didn't help.  When I pressed enter it dumped a ps output to the
   screen, probably the last command I ran when the system was up.  Here
   is a partial output of that as far back as screen would go.

   [...]

   I tried doing ps/n|more and crash just hung.

Trying to exec more may not work here.  Next time this happens, can
you just write down some of the pids from top output that are in
tstile, and ask crash to, e.g., `bt 0t18999'?  (`0t' means decimal
input, as opposed to the default hexadecimal.)

Another useful indication is the `flt_no' wchan (which likely means
one of the flt_noram[123456] waits), which suggests that the uvm pager
is stuck waiting for something -- probably waiting for the pager
daemon to do disk I/O, and all the other processes are probably stuck
waiting for a lock held by someone stuck in disk I/O.

Re: Random lockups on an email server - possibly kern/50168

[Taylor R Campbell]

   Date: Sun, 3 Apr 2016 09:51:08 -0400
   From: "D'Arcy J.M. Cain" 

   This led me to the following PR.

   http://gnats.netbsd.org/39016

   There is a bit of discussion and then it was closed with "This
   particular problem has been fixed. Other problems that lead to "tstile
   syndrome" still exist, because "tstile syndrome" is any generic
   deadlock."  It doesn't say what the fix was.  Could this be some sort
   of code regression?

Every mutex in the kernel is supposed to be held for at most some
constant duration.  When someone tries to an acquire a mutex that is
already held, it will wait with wchan `tstile'.  There are hundreds or
thousands of different mutexes in any given system -- a bug with any
one of them could manifest that way.  

Was your system completely locked up and unresponsive, or just the
services that mattered?  Can you get a stack trace from crash(8) for
the processes that are wedged?  If not, can you enter ddb, e.g. by
typing C-A-ESC, and do it there?

>From either crash(8) or ddb, you can list the processes with `show
proc' and get a stack trace for any individual one with `bt 0t'.
(`0t' is the notation for decimal; ddb reads input as hexadecimal by
default, for whatever reason.)

   I am copying tech-kern as we seem to be getting deeper into the
   kernel.  Replies set there as well.

   Meanwhile I am running the following script, a modification of one
   suggested by Robert Elz.

   ...
   case "${wchan}" in
 tstile*)  x="`ps -p "${pid}" | grep tstile`"
   if [ "X$x" = "X" ]; then continue; fi
   dt=`date`
   echo "TSTILE: ${dt} $x"
   ;;

If you can get a stack trace out of crash(8), that would be more
helpful.  Maybe something like:

printf 'bt 0t%d\n' "${pid}" | crash

Usually the culprit is *not* the process or thread that is stuck in
tstile, but that stack trace will help to find what mutex is at issue.

Re: Security implications of large CGD?

[Taylor R Campbell]

Date: Sun, 28 Apr 2013 14:48:05 +0200
From: Jimmy Johansson ji...@update.uu.se

   I'm about to create a CGD volume larger than 1 TB.

   I seem to remember reading something about OpenBSD and their full disk
   encryption several years ago and that you should not create a
   volume larger than 1 TB with their scheme. If I remember correctly it
   was due to implementation limitations, but then again I don't trust my
   memory any more.

   Or are there any problems overall with a volume larger than 1 TB
   encrypted with aes-cbc and 256 b key that a layperson like me can't
   see? I mean I'm neither a cryptographer nor a mathematician...

Cryptographers recommend[*] avoiding using a 128-bit block cipher with
a single key to encrypt more than 2^32 blocks = 2^40 bytes = 1 TB.
This is to render negligible an attacker's probability of success at
using the birthday paradox to distinguish your ciphertext, which will
have no collisions, from random data, which is expected to have a
collision after 2^64 blocks.

To avoid this, you could break up your disk into parts encrypted with
different keys and combine the parts using ccd or raid.

(OpenBSD has it much worse off, because their disk encryption supports
only the 64-bit block cipher Blowfish.  I wonder whether cgd(4) ought
to reject attempts to configure 1 TB (and much smaller for Blowfish
and 3DES), until perhaps we add support for a wider-block cipher.)

[*] E.g., http://www.ietf.org/rfc/rfc4434.txt.