MFC r340771: proto: change device permissions to 0600

C Turt reports that the driver is not thread safe and may have
exploitable races.

Note that the proto device is intended for prototyping and development,
and is not for use on production systems. From the man page:

SECURITY CONSIDERATIONS
Because programs have direct access to the hardware, the proto
driver is inherently insecure. It is not advisable to use this
driver on a production machine.

The proto device is not included in any of FreeBSD's kernel config files
(although the module is built).

The issues in the proto device still need to be fixed, and the device is
inherently (and intentionally) insecure, but it might as well be limited
to root only.

admbugs: 782
Reported by: C Turt <ecturt@gmail.com>
Sponsored by: The FreeBSD Foundation

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.

On some architectures, u_long isn't large enough for resource definitions.
Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but
type `long' is only 32-bit. This extends rman's resources to uintmax_t. With
this change, any resource can feasibly be placed anywhere in physical memory
(within the constraints of the driver).

Why uintmax_t and not something machine dependent, or uint64_t? Though it's
possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on
32-bit architectures. 64-bit architectures should have plenty of RAM to absorb
the increase on resource sizes if and when this occurs, and the number of
resources on memory-constrained systems should be sufficiently small as to not
pose a drastic overhead. That being said, uintmax_t was chosen for source
clarity. If it's specified as uint64_t, all printf()-like calls would either
need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t
aren't horrible, but it would also bake into the API for
resource_list_print_type() either a hidden assumption that entries get cast to
uintmax_t for printing, or these calls would need the PRI*64 macros. Since
source code is meant to be read more often than written, I chose the clearest
path of simply using uintmax_t.

Tested on a PowerPC p5020-based board, which places all device resources in
0xfxxxxxxxx, and has 8GB RAM.
Regression tested on qemu-system-i386
Regression tested on qemu-system-mips (malta profile)

Tested PAE and devinfo on virtualbox (live CD)

Special thanks to bz for his testing on ARM.

Reviewed By: bz, jhb (previous)
Relnotes: Yes
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D4544

Check the sync operation.

o make sure the boundary is a power of 2, when not zero.
o don't convert 0 to ~0 just so that we can use MIN. ~0 is not a
valid boundary. Introduce BNDRY_MIN that deals with 0 values
that mean no boundary.

Check the hw.proto.attach environment variable for devices that
proto(4) should attach to instead of the normal driver.

Document the variable.

Implement unload and sync operations.

Add create, destroy and load of memory descriptors.

Add an ISA/ACPI bus attachment to proto(4).

Change the probe to what was intended: attach to devices with
a type 0 header and not to function 0 devices.

We need to handle 64-bit BARs ourselves to avoid that the
PCI infrastructure instantiates a non-existent resource.
This has BARs suddenly show up with pciconf(8) under
VMware as well. Now that we read the BAR ourselves, ask
for the correct resource type.

Load the allocated memory and return both the physical
address and the bus address to the application.

Implement mmap(2) for the busdma resource.

Add DMA memory allocation and freeing.
Slightly rework the tag handling.

DMA support part 1: DMA tag create & destroy

Create a special resource (= device special file) for management
of tags and maps, as well as for mapping memory into the address
space. DMA resources are managed using the PROTO_IOC_BUSDMA ioctl.
Part 1 implements tag creation, derivation and destruction.

Add proto(4): A driver for prototyping and diagnostics.
It exposes I/O resources to user space, so that programs can peek
and poke at the hardware. It does not itself have knowledge about
the hardware device it attaches to.

Sponsored by: Juniper Networks, Inc.