Re: overflow in libsa dosfs, feature for efiboot (patches provided)

2020-01-21 Thread Martin Husemann
On Tue, Jan 21, 2020 at 01:12:58PM -0800, Rob Newberry wrote:
> And the code in efi_block_probe will only identify partitions if:
> 
>   - it's GPT (mine isn't)
> 
>   - it's MBR (mine is) and it's a NETBSD partition type (mine isn't)

OK, have to admit the code confuses me. I'm not opposing your patch but
thought there might be a simpler way already.

> With your change AND the following change to blkbyt, I was able to get thing 
> to work with this disk:
> 
>   -#define blkbyt(fs, b)  ((b) << (fs)->bshift)
>   +#define blkbyt(fs, b)  ((uint64_t)(b) << (fs)->bshift)
> 
> Does that make sense?  It's certainly a simpler set of patches to dosfs.c 
> (though I have to swallow my angst over all the casting :-).

Yes - every time we shift a value left and calculate a byte offset, we need
to make sure the calculation is done using 64 bit values. For sector offsets
we do not do that.

Unfortunately the 64 bit arithmetic makes this code create larger binaries
and some boot blocks using this overflow (example I ran into:
sys/arch/i386/stand/bootxx/bootxx_msdos).

So it needs to be conditionalized - very ugly. I have commited that part,
let's see what other build fallout it causes, then get back to the efiboot
change.

Martin


daily CVS update output

2020-01-21 Thread NetBSD source update


Updating src tree:
P src/distrib/evbarm/instkernel/sshramdisk/Makefile
P src/distrib/sets/lists/man/mi
P src/external/bsd/libarchive/dist/cat/test/test_0.c
P src/external/bsd/libarchive/dist/cpio/test/test_basic.c
P src/external/bsd/libarchive/dist/cpio/test/test_format_newc.c
P src/external/bsd/libarchive/dist/libarchive/test/test_compat_zip.c
P src/external/bsd/libarchive/dist/libarchive/test/test_fuzz.c
P src/external/bsd/libarchive/dist/libarchive/test/test_read_extract.c
P 
src/external/bsd/libarchive/dist/libarchive/test/test_read_format_gtar_sparse.c
P src/external/bsd/libarchive/dist/libarchive/test/test_read_format_zip.c
P 
src/external/bsd/libarchive/dist/libarchive/test/test_read_format_zip_7075_utf8_paths.c
P 
src/external/bsd/libarchive/dist/libarchive/test/test_read_format_zip_comment_stored.c
P 
src/external/bsd/libarchive/dist/libarchive/test/test_read_format_zip_extra_padding.c
P 
src/external/bsd/libarchive/dist/libarchive/test/test_read_format_zip_high_compression.c
P src/external/bsd/libarchive/dist/libarchive/test/test_read_format_zip_jar.c
P 
src/external/bsd/libarchive/dist/libarchive/test/test_read_format_zip_mac_metadata.c
P 
src/external/bsd/libarchive/dist/libarchive/test/test_read_format_zip_malformed.c
P src/external/bsd/libarchive/dist/libarchive/test/test_read_format_zip_msdos.c
P src/external/bsd/libarchive/dist/libarchive/test/test_read_format_zip_nested.c
P 
src/external/bsd/libarchive/dist/libarchive/test/test_read_format_zip_nofiletype.c
P src/external/bsd/libarchive/dist/libarchive/test/test_read_format_zip_padded.c
P src/external/bsd/libarchive/dist/libarchive/test/test_read_format_zip_sfx.c
P 
src/external/bsd/libarchive/dist/libarchive/test/test_read_format_zip_with_invalid_traditional_eocd.c
P src/external/bsd/libarchive/dist/libarchive/test/test_read_format_zip_zip64.c
P src/external/bsd/libarchive/dist/libarchive/test/test_read_pax_truncated.c
P src/external/bsd/libarchive/dist/libarchive/test/test_read_truncated_filter.c
P src/external/bsd/libarchive/dist/libarchive/test/test_sparse_basic.c
P src/external/bsd/libarchive/dist/libarchive/test/test_write_disk.c
P 
src/external/bsd/libarchive/dist/libarchive/test/test_write_format_cpio_empty.c
P 
src/external/bsd/libarchive/dist/libarchive/test/test_write_format_shar_empty.c
P src/external/bsd/libarchive/dist/libarchive/test/test_write_format_tar.c
P 
src/external/bsd/libarchive/dist/libarchive/test/test_write_format_tar_sparse.c
P src/external/bsd/libarchive/dist/tar/test/test_basic.c
P src/external/bsd/libarchive/dist/tar/test/test_copy.c
P src/external/bsd/libarchive/dist/tar/test/test_option_C_upper.c
P src/external/bsd/libarchive/dist/tar/test/test_option_s.c
P src/external/bsd/libarchive/dist/test_utils/test_common.h
P src/external/bsd/libarchive/dist/test_utils/test_main.c
P src/share/man/man9/in_getifa.9
P src/sys/arch/aarch64/conf/files.aarch64
P src/sys/arch/aarch64/include/vmparam.h
P src/sys/arch/arm/acpi/acpi_machdep.c
P src/sys/arch/arm/acpi/acpipchb.c
P src/sys/arch/arm/arm/arm_machdep.c
P src/sys/arch/arm/conf/files.arm
P src/sys/arch/evbarm/fdt/fdt_machdep.c
P src/sys/arch/powerpc/powerpc/lock_stubs.S
P src/sys/dev/acpi/xhci_acpi.c
P src/sys/dev/dm/dm.h
P src/sys/dev/dm/dm_target.c
P src/sys/dev/dm/dm_target_delay.c
P src/sys/dev/dm/dm_target_error.c
P src/sys/dev/dm/dm_target_flakey.c
P src/sys/dev/dm/dm_target_linear.c
P src/sys/dev/dm/dm_target_mirror.c
P src/sys/dev/dm/dm_target_snapshot.c
P src/sys/dev/dm/dm_target_stripe.c
P src/sys/dev/dm/dm_target_zero.c
P src/sys/dev/pci/if_wm.c
P src/sys/dev/pci/pcidevs
P src/sys/dev/pci/pcidevs.h
P src/sys/dev/pci/pcidevs_data.h
P src/sys/dev/pci/pcireg.h
P src/sys/dev/pci/ixgbe/ix_txrx.c
P src/sys/dev/pci/ixgbe/ixgbe.c
P src/sys/dev/pci/ixgbe/ixgbe.h
P src/sys/dev/pci/ixgbe/ixgbe_netbsd.c
P src/sys/dev/pci/ixgbe/ixv.c
P src/sys/kern/kern_module.c
P src/sys/kern/kern_rwlock.c
P src/sys/kern/kern_turnstile.c
P src/sys/kern/subr_lockdebug.c
P src/sys/kern/tty.c
P src/sys/sys/lwp.h
P src/sys/sys/param.h
P src/sys/sys/rwlock.h
P src/sys/uvm/uvm_page.c
P src/sys/uvm/uvm_page.h
P src/sys/uvm/uvm_pdpolicy_clock.c
P src/tests/lib/libc/sys/t_ptrace_wait.c
P src/usr.bin/make/meta.c
P src/usr.bin/quota/quota.1
P src/usr.sbin/sysinst/disklabel.c

Updating xsrc tree:


Killing core files:



Updating release-7 src tree (netbsd-7):
U doc/CHANGES-7.3
P sys/compat/common/kern_sig_43.c
P sys/compat/linux/arch/amd64/linux_machdep.c
P sys/compat/linux/common/linux_fcntl.h
P sys/compat/linux/common/linux_file64.c
P sys/compat/linux/common/linux_ipc.c
P sys/compat/linux/common/linux_misc.c
P sys/compat/linux/common/linux_signal.c
P sys/compat/linux/common/linux_socket.c
P sys/compat/linux/common/linux_socket.h
P sys/compat/linux/common/linux_statfs.h
P sys/compat/linux/common/linux_termios.c
P sys/compat/linux/common/linux_termios.h
P sys/compat/linux32/common/linux32_dirent.c
P sys/compat/linux32/common/linux32_ioctl.c
P sys/compat/linux32/common/linux32_misc.c
P 

Re: overflow in libsa dosfs, feature for efiboot (patches provided)

2020-01-21 Thread Rob Newberry
Thanks for your feedback!

>> Below are patches -- one to "dosfs.c" to fix the overflow problem,
>> one to "efiblock.c" to add the "deal with no disklabel" feature.  I
>> don't know the proper way to propose or advocate for these, but I'm
>> sharing them here in the hopes that they'll eventually make it in --
>> though surely after some feedback from others.  Thanks for any advice!
> 
> I think I dimly recall there was a magic way to just use the default
> device efiboot was loaded from w/o any partition magic - but I can't
> remember details. Maybe the non-disklabel part is not needed?

I don't think so, though I will admit I struggled for a long time trying to 
figure out how efiboot worked :-).

In order to correctly find a file, efi_block_parse needs not only a default 
device, but a default device with a partition on it.

And the code in efi_block_probe will only identify partitions if:

- it's GPT (mine isn't)

- it's MBR (mine is) and it's a NETBSD partition type (mine isn't)

Basically all my code does is add a the MSDOSFS partition to the list in the 
second case -- where there's no NetBSD partition (and also no disklabel).  
However, once my code is in place, it is possible to specify this DOS partition 
as default, and then the following EFI boot commands work:

dev hd0a
initrd ramdisk.fs
dtb dtbfile.dtb
boot netbsd

> Can you try the below patch instead of your first one?

It thought it would work, but it didn't.

Specifically, when I got to line ~322:

if ((err = ioread(f->fs, (c ? blkoff(f->fs, c) :
secbyt(f->fs->lsndir)) + off,
buf, n)))
goto out;

the code would fail for my disk (a 64GB SD card with a single FAT partition), 
which has these parameters at this point in the code:

fs->lndta = 30470
c = 1663485
fs->bshift = 15

With those parameters, the blkoff macro (with your change) still returns 
0xb1eb8c00, truncating the high bits.  The inline function returns the correct 
value of 0xcb1eb8c00.

I think the problem is that the blkbyt macro (used in the second part of the 
blkoff macro) is truncating to the u_int range before being added to the 
(casted up to uint64_t) portion in the blkoff macro.  (I'm not at all an expert 
with how the compiler handles automatic promotions/truncations/etc, which is 
why I turned to an inline function.)

With your change AND the following change to blkbyt, I was able to get thing to 
work with this disk:

-#define blkbyt(fs, b)  ((b) << (fs)->bshift)
+#define blkbyt(fs, b)  ((uint64_t)(b) << (fs)->bshift)

Does that make sense?  It's certainly a simpler set of patches to dosfs.c 
(though I have to swallow my angst over all the casting :-).

Thank you again for looking at this.

Rob



Re: 9.99.40: panic: kernel diagnostic assertion "ci->ci_biglock_count == 0" failed

2020-01-21 Thread Andrew Doran
Hi Thomas,

On Tue, Jan 21, 2020 at 08:47:44PM +0100, Thomas Klausner wrote:

> During a bulk build (in rust AFAICT), I got a panic with
> panic: kernel diagnostic assertion "ci->ci_biglock_count == 0" failed: file 
> "/usr/src/sys/sys/userret.h", line 88
> 
> That's this one:
> 
> static __inline void
> mi_userret(struct lwp *l)
> {
> struct cpu_info *ci;
> 
> KPREEMPT_DISABLE(l);
> ci = l->l_cpu;
> KASSERT(l->l_blcnt == 0);
> KASSERT(ci->ci_biglock_count == 0);
> 
> 
> 
> The backtrace in the crash dump is not very helpful:
> 
> (gdb) bt
> #0  0x80224315 in cpu_reboot (howto=howto@entry=260, 
> bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:720
> #1  0x809f5ec3 in kern_reboot (howto=howto@entry=260, 
> bootstr=bootstr@entry=0x0) at /usr/src/sys/kern/kern_reboot.c:61
> #2  0x80a37109 in vpanic (fmt=0x8135e980 "kernel %sassertion 
> \"%s\" failed: file \"%s\", line %d ", ap=ap@entry=0xad0928973f48)
> at /usr/src/sys/kern/subr_prf.c:336
> #3  0x80e7b0b3 in kern_assert (fmt=fmt@entry=0x8135e980 
> "kernel %sassertion \"%s\" failed: file \"%s\", line %d ")
> at /usr/src/sys/lib/libkern/kern_assert.c:51
> #4  0x802568ce in mi_userret (l=0xcfc320ca9c00) at 
> /usr/src/sys/sys/userret.h:91
> #5  userret (l=0xcfc320ca9c00) at ./machine/userret.h:81
> #6  syscall (frame=) at /usr/src/sys/arch/x86/x86/syscall.c:166
> #7  0x802096ad in handle_syscall ()

hannken@ supplied me with a repro for this one so I'm going to look into it
tomorrow morning.  syzbot has also run into it recently.

Andrew


9.99.40: panic: kernel diagnostic assertion "ci->ci_biglock_count == 0" failed

2020-01-21 Thread Thomas Klausner
During a bulk build (in rust AFAICT), I got a panic with
panic: kernel diagnostic assertion "ci->ci_biglock_count == 0" failed: file 
"/usr/src/sys/sys/userret.h", line 88

That's this one:

static __inline void
mi_userret(struct lwp *l)
{
struct cpu_info *ci;

KPREEMPT_DISABLE(l);
ci = l->l_cpu;
KASSERT(l->l_blcnt == 0);
KASSERT(ci->ci_biglock_count == 0);



The backtrace in the crash dump is not very helpful:

(gdb) bt
#0  0x80224315 in cpu_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:720
#1  0x809f5ec3 in kern_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at /usr/src/sys/kern/kern_reboot.c:61
#2  0x80a37109 in vpanic (fmt=0x8135e980 "kernel %sassertion 
\"%s\" failed: file \"%s\", line %d ", ap=ap@entry=0xad0928973f48)
at /usr/src/sys/kern/subr_prf.c:336
#3  0x80e7b0b3 in kern_assert (fmt=fmt@entry=0x8135e980 "kernel 
%sassertion \"%s\" failed: file \"%s\", line %d ")
at /usr/src/sys/lib/libkern/kern_assert.c:51
#4  0x802568ce in mi_userret (l=0xcfc320ca9c00) at 
/usr/src/sys/sys/userret.h:91
#5  userret (l=0xcfc320ca9c00) at ./machine/userret.h:81
#6  syscall (frame=) at /usr/src/sys/arch/x86/x86/syscall.c:166
#7  0x802096ad in handle_syscall ()

 Thomas



Re: Devices without power management support: dm0 dm1 (LVM / Device Mapper prevents ACPI Sleep State 3)

2020-01-21 Thread maya
On Wed, Jan 15, 2020 at 11:42:09AM +0100, Matthias Petermann wrote:
> Hello Maya,
> 
> On 15.01.20 07:55, m...@netbsd.org wrote:
> > > 
> > > Since I don't see any of this in the log, I'm not sure at all whether the
> > > code is actually executed. Is it generally the case that all device 
> > > drivers
> > > are "detached" before entering ACPI Sleep state 3? Or could this be a
> > > special case?
> > 
> > You will need to rebuild the modules, not the kernel.
> > 
> > build.sh  modules
> > sudo build.sh ... installmodules=/
> > 
> > Is how I usually do it.
> > 
> 
> I hadn't thought of that - thanks for the tip. It works now!
> 
> The X230 correctly enters ACPI sleep state 3 with the change you have
> proposed and wakes up without any functional restrictions.
> 
> How likely is it that the device mapper was only accidentally not taken into
> account in power management, or whether it should deliberately block the
> sleep state for technical reasons?
> 
> If nothing speaks against it, how do we get the patch in syssrc? Should I
> submit a bug report?
> 
> Best wishes
> Matthias
> 

Committed and pulled up to netbsd-9.
http://mail-index.netbsd.org/source-changes/2020/01/16/msg112900.html
http://mail-index.netbsd.org/source-changes/2020/01/21/msg113133.html
Thanks for testing.


NetBSD Security Advisory 2020-001: Missing permissions checks for network ioctls

2020-01-21 Thread NetBSD Security-Officer


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

NetBSD Security Advisory 2020-001
=

Topic:  Missing permissions checks for network ioctls

Version:NetBSD-current: affected
NetBSD 9.0_RC1: affected
NetBSD 8.1: partially affected
NetBSD 7.x: partially affected

Severity:   Local users can crash the machine

Fixed:  NetBSD-current: December 16, 2019
NetBSD-9 branch:December 17, 2019
NetBSD-8 branch:December 17, 2019
NetBSD-7 branch:December 17, 2019

Please note that NetBSD releases prior to 7.1 are no longer supported.
It is recommended that all users upgrade to a supported release.

Abstract


Three network interface related ioctls that should have been only allowed
for privileged users were not adequately protected. An unprivileged user
can set network interface descriptions, get and set diagnostic data from
some atheros interfaces, and retrieve descriptor information from umb (usb
mobile network device).

Technical Details
=

Specifically the following ioctls were missing permissions checks:

IOCTL   FUNCTIONIFACE   VERSION HOW
- 
---
SIOCGATHDIAGath_ioctl   ath *   get and set diagnostic info
SIOCSIFDESCRifioctl_common  *   9,CUR   set the interface description
SIOCGUMBINFOumb_ioctl   umb 9,CUR   get descriptor info/potentially
contains username/password
Solutions and Workarounds
=

Update the kernel to a fixed version and reboot.

To apply a fixed version from a releng build, fetch a fitting kern-GENERIC.tgz
from nyftp.netbsd.org and extract the fixed binaries:

cd /var/tmp
ftp 
https://nycdn.NetBSD.org/pub/NetBSD-daily/REL/latest/ARCH/binary/sets/kern-GENERIC.tgz
cd /
tar xzpf /var/tmp/kern-GENERIC.tgz

with the following replacements:
REL   = the release version you are using
ARCH  = your system's architecture

The following instructions describe how to upgrade your kernel by
updating your source tree and rebuilding and installing a new version.

For all NetBSD versions, you need to obtain fixed kernel sources,
rebuild and install the new kernel, and reboot the system.
  
The fixed source may be obtained from the NetBSD CVS repository.
The following instructions briefly summarise how to upgrade your
kernel.  In these instructions, replace:

  ARCH with your architecture (from uname -m), and  
  KERNCONF with the name of your kernel configuration file.

To update from CVS, re-build, and re-install the kernel:

# cd src
# cvs update -d -P src/sys/dev/ic/ath.c
# cvs update -d -P src/sys/dev/usb/if_umb.c
# cvs update -d -P src/sys/net/if.c
# ./build.sh kernel=KERNCONF
# mv /netbsd /netbsd.old
# cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd 
# shutdown -r now

For more information on how to do this, see:

   http://www.NetBSD.org/docs/guide/en/chap-kernel.html

The patches can be obtained from NetBSD-current with the following
commands:

cvs rdiff -u -r1.128 -r1.129 src/sys/dev/ic/ath.c
cvs rdiff -u -r1.9 -r1.10 src/sys/dev/usb/if_umb.c
cvs rdiff -u -r1.465 -r1.466 src/sys/net/if.c

Thanks To
=

Ilja Van Sprundel for reporting this vulnerability.

More Information


Advisories may be updated as new information becomes available.
The most recent version of this advisory (PGP signed) can be found at


https://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2020-001.txt.asc

Information about NetBSD and NetBSD security can be found at

https://www.NetBSD.org/
https://www.NetBSD.org/Security/

Copyright 2020, The NetBSD Foundation, Inc.  All Rights Reserved.
Redistribution permitted only in full, unmodified form.

$NetBSD: NetBSD-SA2020-001.txt.asc,v 1.1 2020/01/21 16:08:16 christos Exp $
-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJeJyHcAAoJEIkmHhf170n/uDMP+gIwylZuuX0DQFIBtPI7KFnu
/C7oJJ6mzk823iSlNxhew2WBoawyUEHeOm6hDUGQfokgCZX2DCTfhXMgdbFm9Nfk
2GQpwqVyZMUlA6UxYRm0fPtywksn5+z5JarwA2SqAk/jwZKb59baf9xDOPlzXHRJ
JdzGLGC9CdRMvghlb4a/P5v+0FAEKbf0roEtEMMtDwB3JbYI0F0KRc0xqvuRP2N9
UFfgEkIh0Dgz8Np0aZQdyh513L8r6y5sWDnjuT2RmA7PWUAz64FzOYBAYSP253wG
pBkUkQ9Z8wFVN3LDuOspjMxkj8pT2SvI9iq5DHYllDAqeHY8rA4E4/EVty0KDfm8
o3uHk3PJq/ngEJ6QW8dkDfsZNS3WlRkysYuVuEZ3fcIn25GgN228/CDmS0CbZ6eI
KUn7N8DEB2zQN2HGiso0gm+/EOUxGE6F5IBCmhxG5Vynh7gaUSHjZFYLpIvPur/s
tLZALUZ4bi0T/FVYgOdGp9Wn+Dnc5aa2xsEYBn+ytpcdu/GnS2cEoIhJ+I3Bi9s6
NTUlqqSZNzanCbpAWhxQWAedVbQ4dgwHmVF/EsDy29koFiBWEJStkUlsnv8+p0xj
ypbGclNtDWBZ/cmdYysbGcHx0s8mZabDuCJvWfudLICVzHaRjoVWySo1ePqK+AVQ

Re: graphical console: limit resolution?

2020-01-21 Thread Thomas Klausner
On Wed, Dec 11, 2019 at 08:24:09PM +0100, Michael van Elst wrote:
> On Wed, Dec 11, 2019 at 04:29:41PM +0100, Thomas Klausner wrote:
> > 
> > So it looks like radeondrmkmsfb does not (correctly) detect the active
> > output(s)?
> 
> Looks like it. There is lots of heuristics in that field.

Ok, so except for this issue, I'm successfully using the attached
diff.

What's the best way to do this, adding kernel options like:

   options CONSOLE_MAX_RESOLUTION_X 1920
   options CONSOLE_MAX_RESOLUTION_Y 1080

and using these defines in that location, or are there other suggestions?
 Thomas

Index: drm_modes.c
===
RCS file: /cvsroot/src/sys/external/bsd/drm2/dist/drm/drm_modes.c,v
retrieving revision 1.7
diff -u -r1.7 drm_modes.c
--- drm_modes.c 27 Aug 2018 04:58:19 -  1.7
+++ drm_modes.c 13 Jan 2020 16:02:32 -
@@ -1016,10 +1016,10 @@
 drm_mode_validate_size(const struct drm_display_mode *mode,
   int maxX, int maxY)
 {
-   if (maxX > 0 && mode->hdisplay > maxX)
+   if ((maxX > 0 && mode->hdisplay > maxX) || (mode->hdisplay > 1920))
return MODE_VIRTUAL_X;
 
-   if (maxY > 0 && mode->vdisplay > maxY)
+   if ((maxY > 0 && mode->vdisplay > maxY) || (mode->vdisplay > 1080))
return MODE_VIRTUAL_Y;
 
return MODE_OK;


Automated report: NetBSD-current/i386 build success

2020-01-21 Thread NetBSD Test Fixture
The NetBSD-current/i386 build is working again.

The following commits were made between the last failed build and the
successful build:

2020.01.21.06.44.40 mrg src/usr.sbin/sysinst/disklabel.c,v 1.32

Log files can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2020.01.html#2020.01.21.06.44.40