[PATCH] add Gemini Lake SoC pcidevs

2018-12-11 Thread James Hastings
Index: dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1870
diff -u -p -r1.1870 pcidevs
--- dev/pci/pcidevs 30 Nov 2018 19:18:31 -  1.1870
+++ dev/pci/pcidevs 12 Dec 2018 04:47:11 -
@@ -4384,6 +4384,36 @@ product INTEL RCU32  0x3092  RCU32 I2O RA
 product INTEL 3124 0x3124  3124 SATA
 product INTEL WL_3165_10x3165  Dual Band Wireless AC 3165
 product INTEL WL_3165_20x3166  Dual Band Wireless AC 3165
+product INTEL GEMINILAKE_IGD_1 0x3184  UHD Graphics 605
+product INTEL GEMINILAKE_IGD_2 0x3185  UHD Graphics 600
+product INTEL GEMINILAKE_DPTF  0x318c  Gemini Lake DPTF
+product INTEL GEMINILAKE_GNA   0x3190  Gemini Lake GNA
+product INTEL GEMINILAKE_PMC   0x3194  Gemini Lake PMC
+product INTEL GEMINILAKE_HDA   0x3198  Gemini Lake HD Audio
+product INTEL GEMINILAKE_MEI   0x319a  Gemini Lake MEI
+product INTEL GEMINILAKE_XHCI  0x31a8  Gemini Lake xHCI
+product INTEL GEMINILAKE_I2C_1 0x31ac  Gemini Lake I2C
+product INTEL GEMINILAKE_UART_10x31bc  Gemini Lake HSUART
+product INTEL GEMINILAKE_UART_20x31be  Gemini Lake HSUART
+product INTEL GEMINILAKE_UART_30x31c0  Gemini Lake HSUART
+product INTEL GEMINILAKE_SPI_1 0x31c2  Gemini Lake SPI
+product INTEL GEMINILAKE_SPI_2 0x31c4  Gemini Lake SPI
+product INTEL GEMINILAKE_SPI_3 0x31c6  Gemini Lake SPI
+product INTEL GEMINILAKE_SD0x31ca  Gemini Lake SD/MMC
+product INTEL GEMINILAKE_EMMC  0x31cc  Gemini Lake eMMC
+product INTEL GEMINILAKE_SDIO  0x31d0  Gemini Lake SDIO
+product INTEL GEMINILAKE_SMB   0x31d4  Gemini Lake SMBus
+product INTEL GEMINILAKE_PCIE_10x31d6  Gemini Lake PCIE
+product INTEL GEMINILAKE_PCIE_20x31d7  Gemini Lake PCIE
+product INTEL GEMINILAKE_PCIE_30x31d8  Gemini Lake PCIE
+product INTEL GEMINILAKE_PCIE_40x31d9  Gemini Lake PCIE
+product INTEL GEMINILAKE_PCIE_50x31da  Gemini Lake PCIE
+product INTEL GEMINILAKE_PCIE_60x31db  Gemini Lake PCIE
+product INTEL GEMINIlAKE_WL0x31dc  Gemini Lake CNVi
+product INTEL GEMINILAKE_AHCI  0x31e3  Gemini Lake AHCI
+product INTEL GEMINILAKE_LPC   0x31e8  Gemini Lake LPC
+product INTEL GEMINILAKE_UART_40x31ee  Gemini Lake HSUART
+product INTEL GEMINILAKE_HOST  0x31f0  Gemini Lake Host
 product INTEL 312440x3200  31244 SATA
 product INTEL 82855PM_HB   0x3340  82855PM Host
 product INTEL 82855PM_AGP  0x3341  82855PM AGP



Re: allow if_output to be specialised on ethernet interfaces

2018-12-11 Thread Claudio Jeker
On Wed, Dec 12, 2018 at 11:54:39AM +1000, David Gwynne wrote:
> this makes it nicer to set up a custom output routine on ethernet
> interfaces. rather than overwriting it after ether_ifattach is called,
> you can set it up with the rest of the callbacks and the ether layer
> will respect it.
> 
> ok?

Are you sure that all ifp are allocated with zeroed out memory?
Apart from that OK claudio@
 
> Index: if_ethersubr.c
> ===
> RCS file: /cvs/src/sys/net/if_ethersubr.c,v
> retrieving revision 1.254
> diff -u -p -r1.254 if_ethersubr.c
> --- if_ethersubr.c11 Dec 2018 01:27:08 -  1.254
> +++ if_ethersubr.c11 Dec 2018 23:48:17 -
> @@ -510,7 +510,8 @@ ether_ifattach(struct ifnet *ifp)
>   ifp->if_addrlen = ETHER_ADDR_LEN;
>   ifp->if_hdrlen = ETHER_HDR_LEN;
>   ifp->if_mtu = ETHERMTU;
> - ifp->if_output = ether_output;
> + if (ifp->if_output == NULL)
> + ifp->if_output = ether_output;
>   ifp->if_rtrequest = ether_rtrequest;
>  
>   if_ih_insert(ifp, ether_input, NULL);
> 

-- 
:wq Claudio



Re: kdump -f -

2018-12-11 Thread Theo de Raadt
ok deraadt



Re: make build as root fails when SUDO=doas

2018-12-11 Thread Ted Unangst
Marc Espie wrote:
> There is a kind of mixed model there.
> 
> Because make build still goes thru regress for obj and cleandir
> 
> Yet the rest of the build doesn't!
> 
> So, if we agree that it needs to stay the way it currently is, then
> the SUDO in that Makefile might trigger while running as root...
> 
> ... or we could change all the ports tree and rename SUDO to something
> else in there so that it doesn't interfere at all.  But I see most porters
> not too happy with that choice.
> 
> As Mr Morden would say "what do you want ?"...

I would say the regress test should try to avoid creating files that can only
be deleted by root.

I can't actually find where anything sets SUDO_CLEAN. Is this whole fuss over
an rm -f with no arguments?



Re: make build as root fails when SUDO=doas

2018-12-11 Thread Marc Espie
On Tue, Dec 11, 2018 at 10:55:25PM +0100, Claudio Jeker wrote:
> On Tue, Dec 11, 2018 at 02:35:33PM -0700, Theo de Raadt wrote:
> > Ted Unangst  wrote:
> > 
> > > Marc Espie wrote:
> > > > > > - try to remove the files normally first
> > > > > >  rm -f ${SUDO_CLEAN} || test -z "${SUDO}" || ${SUDO} rm -f 
> > > > > > ${SUDO_CLEAN}
> > > > > > 
> > > > > > this should actually fix the issue.
> > > > > > 
> > > > > > Any other directory with that problem ?
> > > > > 
> > > > > that fix the issue and the build continues fine
> > > > 
> > > > So okay from source people ? tedu, guenther, theo, krw ? somebody else ?
> > > 
> > > does anywhere else in the tree do this? aren't most (all) things either 
> > > done
> > > as root or not done as root?
> > 
> > I also don't understand what the point is here.
> > 
> > release(9) shows the correct build process.
> > 
> > you start build as root, to permit the priv-drop security model we
> > designed in 2017.
> > 
> > If on the other hand you build from a regular user below, with doas
> > configured to allow escalation at any point in time, the regular user
> > below CAN ALWAYS BECOME ROOT SO YOU HAVE NO SECURITY MODEL IN MIND AT
> > ALL, while you operate on Makefile and such you downloaded from elsewhere
> > 
> > Such use of sudo/doas is an ANTI-PATTERN
> 
> I think the main issue is that /usr/sr/regress was not moved to the
> priv-drop security model. There is bunch of code which needs root but I
> don't want to run all of regress as user root. 

There is a kind of mixed model there.

Because make build still goes thru regress for obj and cleandir

Yet the rest of the build doesn't!

So, if we agree that it needs to stay the way it currently is, then
the SUDO in that Makefile might trigger while running as root...

... or we could change all the ports tree and rename SUDO to something
else in there so that it doesn't interfere at all.  But I see most porters
not too happy with that choice.

As Mr Morden would say "what do you want ?"...



kdump -f -

2018-12-11 Thread Ted Unangst
I have some trace files that are gzipped to save space. (They compress really
well.) It would be convenient if I could simply zcat them into kdump for
inspection.

This patch allows -f - to read from stdin. (Curiously, kdump always reads from
stdin, but uses freopen on the trace file.)

Unsure about man page. I think many utilities just generally assume the user
knows - means stdin/out?


Index: kdump.c
===
RCS file: /cvs/src/usr.bin/kdump/kdump.c,v
retrieving revision 1.135
diff -u -p -r1.135 kdump.c
--- kdump.c 21 Oct 2018 19:56:26 -  1.135
+++ kdump.c 12 Dec 2018 03:26:08 -
@@ -208,16 +208,18 @@ main(int argc, char *argv[])
if (argc > optind)
usage();
 
-   if (unveil(tracefile, "r") == -1)
-   err(1, "unveil");
+   if (strcmp(tracefile, "-") != 0)
+   if (unveil(tracefile, "r") == -1)
+   err(1, "unveil");
if (pledge("stdio rpath getpw", NULL) == -1)
err(1, "pledge");
 
m = malloc(size = 1025);
if (m == NULL)
err(1, NULL);
-   if (!freopen(tracefile, "r", stdin))
-   err(1, "%s", tracefile);
+   if (strcmp(tracefile, "-") != 0)
+   if (!freopen(tracefile, "r", stdin))
+   err(1, "%s", tracefile);
 
if (fread_tail(_header, sizeof(struct ktr_header), 1) == 0 ||
ktr_header.ktr_type != htobe32(KTR_START))



let etherip(4) output directly to the ip stack

2018-12-11 Thread David Gwynne
with the previous if_ethersubr.c diff, this allows etherip(4) to output
directly to the network stack.

direct output relies on the interface using priq, since hfsc uses the
ifq machinery to work. priq implies you dont want to delay packets, so
it lets etherip push the packet straight through.

i dont think the ifq stuff is slow, but it does allow the stack to
concurrently send packets with etherip without having to create an ifq
per cpu. it does rely on per cpu counters, but theyre relatively small.

the other advantage is it stops ether_output recursing in the etherip
path. this helps profiling, but that is a fairly niche benefit so maybe
just focus on the concurrency.

ok?

Index: if_etherip.c
===
RCS file: /cvs/src/sys/net/if_etherip.c,v
retrieving revision 1.40
diff -u -p -r1.40 if_etherip.c
--- if_etherip.c12 Nov 2018 23:57:06 -  1.40
+++ if_etherip.c12 Dec 2018 01:58:57 -
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -102,7 +103,10 @@ void etheripattach(int);
 int etherip_clone_create(struct if_clone *, int);
 int etherip_clone_destroy(struct ifnet *);
 int etherip_ioctl(struct ifnet *, u_long, caddr_t);
-void etherip_start(struct ifnet *);
+int etherip_output(struct ifnet *, struct mbuf *, struct sockaddr *,
+struct rtentry *rt);
+void etherip_start(struct ifqueue *);
+void etherip_send(struct ifnet *, struct mbuf *);
 int etherip_media_change(struct ifnet *);
 void etherip_media_status(struct ifnet *, struct ifmediareq *);
 int etherip_set_tunnel(struct etherip_softc *, struct if_laddrreq *);
@@ -144,9 +148,10 @@ etherip_clone_create(struct if_clone *if
ifp->if_softc = sc;
ifp->if_hardmtu = ETHER_MAX_HARDMTU_LEN;
ifp->if_ioctl = etherip_ioctl;
-   ifp->if_start = etherip_start;
+   ifp->if_output = etherip_output;
+   ifp->if_qstart = etherip_start;
ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
-   ifp->if_xflags = IFXF_CLONED;
+   ifp->if_xflags = IFXF_MPSAFE | IFXF_CLONED;
IFQ_SET_MAXLEN(>if_snd, IFQ_MAXLEN);
ifp->if_capabilities = IFCAP_VLAN_MTU;
ether_fakeaddr(ifp);
@@ -159,6 +164,8 @@ etherip_clone_create(struct if_clone *if
if_attach(ifp);
ether_ifattach(ifp);
 
+   if_counters_alloc(ifp);
+
NET_LOCK();
TAILQ_INSERT_TAIL(_list, >sc_tunnel, t_entry);
NET_UNLOCK();
@@ -201,40 +208,65 @@ etherip_media_status(struct ifnet *ifp, 
 }
 
 void
-etherip_start(struct ifnet *ifp)
+etherip_send(struct ifnet *ifp, struct mbuf *m)
 {
struct etherip_softc *sc = ifp->if_softc;
-   struct mbuf *m;
int error;
-#if NBPFILTER > 0
-   caddr_t if_bpf;
-#endif
 
-   while ((m = ifq_dequeue(>if_snd)) != NULL) {
 #if NBPFILTER > 0
-   if_bpf = ifp->if_bpf;
-   if (if_bpf)
-   bpf_mtap_ether(if_bpf, m, BPF_DIRECTION_OUT);
+   caddr_t if_bpf = ifp->if_bpf;
+   if (if_bpf)
+   bpf_mtap_ether(if_bpf, m, BPF_DIRECTION_OUT);
 #endif
 
-   switch (sc->sc_tunnel.t_af) {
-   case AF_INET:
-   error = ip_etherip_output(ifp, m);
-   break;
+   switch (sc->sc_tunnel.t_af) {
+   case AF_INET:
+   error = ip_etherip_output(ifp, m);
+   break;
 #ifdef INET6
-   case AF_INET6:
-   error = ip6_etherip_output(ifp, m);
-   break;
-#endif
-   default:
-   /* unhandled_af(sc->sc_tunnel.t_af); */
-   m_freem(m);
-   continue;
-   }
+   case AF_INET6:
+   error = ip6_etherip_output(ifp, m);
+   break;
+#endif
+   default:
+   /* unhandled_af(sc->sc_tunnel.t_af); */
+   m_freem(m);
+   error = ENETDOWN;
+   break;
+   }
+
+   if (error)
+   counters_inc(ifp->if_counters, ifc_oerrors);
+}
 
-   if (error)
-   ifp->if_oerrors++;
+void
+etherip_start(struct ifqueue *ifq)
+{
+   struct ifnet *ifp = ifq->ifq_if;
+   struct mbuf *m;
+
+   while ((m = ifq_dequeue(ifq)) != NULL)
+   etherip_send(ifp, m);
+}
+
+int
+etherip_output(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst,
+struct rtentry *rt)
+{
+   int error;
+
+   m = ether_encap(ifp, m, dst, rt, );
+   if (m == NULL)
+   return (error);
+
+   if (ifq_is_priq(>if_snd)) {
+   counters_pkt(ifp->if_counters,
+   ifc_opackets, ifc_obytes, m->m_pkthdr.len); 
+   etherip_send(ifp, m);
+   return (0);
}
+
+   return (ifq_enqueue(>if_snd, m));
 }
 
 int



allow if_output to be specialised on ethernet interfaces

2018-12-11 Thread David Gwynne
this makes it nicer to set up a custom output routine on ethernet
interfaces. rather than overwriting it after ether_ifattach is called,
you can set it up with the rest of the callbacks and the ether layer
will respect it.

ok?

Index: if_ethersubr.c
===
RCS file: /cvs/src/sys/net/if_ethersubr.c,v
retrieving revision 1.254
diff -u -p -r1.254 if_ethersubr.c
--- if_ethersubr.c  11 Dec 2018 01:27:08 -  1.254
+++ if_ethersubr.c  11 Dec 2018 23:48:17 -
@@ -510,7 +510,8 @@ ether_ifattach(struct ifnet *ifp)
ifp->if_addrlen = ETHER_ADDR_LEN;
ifp->if_hdrlen = ETHER_HDR_LEN;
ifp->if_mtu = ETHERMTU;
-   ifp->if_output = ether_output;
+   if (ifp->if_output == NULL)
+   ifp->if_output = ether_output;
ifp->if_rtrequest = ether_rtrequest;
 
if_ih_insert(ifp, ether_input, NULL);



running Xorg without root

2018-12-11 Thread Lauri Tirkkonen
Hi,

since the Xorg setuid bit was removed, I looked a little bit into what
it would take to run it without root privs. I have a proof of concept
put together, and things seem to work (on an X220 amd64 + modesetting
driver, inteldrm; login on ttyC0 and running xinit).  Testing the waters
here to see if anyone else is interested :)

First, we need Xorg to attempt xf86OpenConsole even when we're not uid
0. That will call xf86OpenWScons (through xf86ConsTab), which opens the
console device and does wscons ioctls on it -- succeeding if the user
running X has logged in on that console.

diff --git a/xserver/hw/xfree86/common/xf86Init.c 
b/xserver/hw/xfree86/common/xf86Init.c
index 2a04da045..b814eb412 100644
--- a/xserver/hw/xfree86/common/xf86Init.c
+++ b/xserver/hw/xfree86/common/xf86Init.c
@@ -967,9 +967,13 @@ OsVendorInit(void)
 #endif
 #endif
 #if defined(X_PRIVSEP)
-  if (!beenHere && !xf86KeepPriv && geteuid() == 0) {
- xf86PrivilegedInit();
- xf86DropPriv();
+  if (!beenHere) {
+ if(!xf86KeepPriv && geteuid() == 0) {
+ xf86PrivilegedInit();
+ xf86DropPriv();
+ } else {
+ xf86OpenConsole();
+ }
   }
 #endif
 

Next, we need the user logging in on ttyC0 to be able to access
/dev/pci0 and /dev/ttyC4:

diff --git a/etc/etc.amd64/fbtab b/etc/etc.amd64/fbtab
index 79cfb535c9f..b746b7684f7 100644
--- a/etc/etc.amd64/fbtab
+++ b/etc/etc.amd64/fbtab
@@ -1 +1 @@
-/dev/ttyC0 0600
/dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/drm0
+/dev/ttyC0 0600
/dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/drm0:/dev/pci0:/dev/ttyC4


Finally, there's a check in drm_drv.c that only allows superuser to
become a master on /dev/drm0 and fails the open for other users. I
removed the superuser check; filesystem permissions should prevent
anyone except the user logging in on ttyC0 from accessing this device
anyway. I haven't studied what exactly being the master allows here and
if there's possible privilege escalation hiding there; my reading of
drm_do_ioctl is that ioctls marked DRM_ROOT_ONLY will still fail, so I
admit I don't really know what the check was there for...

Still, this allows running X without any user processes as root (and
unbreaks xinit/startx) - is there any potential here? :)

diff --git a/sys/dev/pci/drm/drm_drv.c b/sys/dev/pci/drm/drm_drv.c
index e09380e3257..be9773b0671 100644
--- a/sys/dev/pci/drm/drm_drv.c
+++ b/sys/dev/pci/drm/drm_drv.c
@@ -745,14 +745,10 @@ drmopen(dev_t kdev, int flags, int fmt, struct proc *p)
}
 
mutex_lock(>struct_mutex);
-   /* first opener automatically becomes master if root */
-   if (SPLAY_EMPTY(>files) && !DRM_SUSER(p)) {
-   mutex_unlock(>struct_mutex);
-   ret = EPERM;
-   goto free_priv;
-   }
-
+   /* first opener automatically becomes master */
file_priv->is_master = SPLAY_EMPTY(>files);
+   if (!file_priv->authenticated)
+   file_priv->authenticated = file_priv->is_master;
 
SPLAY_INSERT(drm_file_tree, >files, file_priv);
mutex_unlock(>struct_mutex);

-- 
Lauri Tirkkonen | lotheac @ IRCnet



Re: allow weak passwd

2018-12-11 Thread Chris Cappuccio
Ted Unangst [t...@tedunangst.com] wrote:
> 
> i get tired of typing the same password five times.

The first three times, just hit 'a' 
The fourth time, enter the password you want



Re: make build as root fails when SUDO=doas

2018-12-11 Thread Marc Espie
On Tue, Dec 11, 2018 at 02:35:33PM -0700, Theo de Raadt wrote:
> Ted Unangst  wrote:
> 
> > Marc Espie wrote:
> > > > > - try to remove the files normally first
> > > > >  rm -f ${SUDO_CLEAN} || test -z "${SUDO}" || ${SUDO} rm -f 
> > > > > ${SUDO_CLEAN}
> > > > > 
> > > > > this should actually fix the issue.
> > > > > 
> > > > > Any other directory with that problem ?
> > > > 
> > > > that fix the issue and the build continues fine
> > > 
> > > So okay from source people ? tedu, guenther, theo, krw ? somebody else ?
> > 
> > does anywhere else in the tree do this? aren't most (all) things either done
> > as root or not done as root?
> 
> I also don't understand what the point is here.
> 
> release(9) shows the correct build process.
> 
> you start build as root, to permit the priv-drop security model we
> designed in 2017.
> 
> If on the other hand you build from a regular user below, with doas
> configured to allow escalation at any point in time, the regular user
> below CAN ALWAYS BECOME ROOT SO YOU HAVE NO SECURITY MODEL IN MIND AT
> ALL, while you operate on Makefile and such you downloaded from elsewhere
> 
> Such use of sudo/doas is an ANTI-PATTERN

Ah, so actually just
rm -f ${SUDO_CLEAN}

should be fine ?



Re: make build as root fails when SUDO=doas

2018-12-11 Thread Theo de Raadt
Claudio Jeker  wrote:

> I think the main issue is that /usr/sr/regress was not moved to the
> priv-drop security model. There is bunch of code which needs root but I
> don't want to run all of regress as user root. 

regress is very special



Re: make build as root fails when SUDO=doas

2018-12-11 Thread Claudio Jeker
On Tue, Dec 11, 2018 at 02:35:33PM -0700, Theo de Raadt wrote:
> Ted Unangst  wrote:
> 
> > Marc Espie wrote:
> > > > > - try to remove the files normally first
> > > > >  rm -f ${SUDO_CLEAN} || test -z "${SUDO}" || ${SUDO} rm -f 
> > > > > ${SUDO_CLEAN}
> > > > > 
> > > > > this should actually fix the issue.
> > > > > 
> > > > > Any other directory with that problem ?
> > > > 
> > > > that fix the issue and the build continues fine
> > > 
> > > So okay from source people ? tedu, guenther, theo, krw ? somebody else ?
> > 
> > does anywhere else in the tree do this? aren't most (all) things either done
> > as root or not done as root?
> 
> I also don't understand what the point is here.
> 
> release(9) shows the correct build process.
> 
> you start build as root, to permit the priv-drop security model we
> designed in 2017.
> 
> If on the other hand you build from a regular user below, with doas
> configured to allow escalation at any point in time, the regular user
> below CAN ALWAYS BECOME ROOT SO YOU HAVE NO SECURITY MODEL IN MIND AT
> ALL, while you operate on Makefile and such you downloaded from elsewhere
> 
> Such use of sudo/doas is an ANTI-PATTERN

I think the main issue is that /usr/sr/regress was not moved to the
priv-drop security model. There is bunch of code which needs root but I
don't want to run all of regress as user root. 

-- 
:wq Claudio



Re: allow weak passwd

2018-12-11 Thread Mark Kettenis
> Date: Tue, 11 Dec 2018 22:39:37 +0100
> From: Antoine Jacoutot 
> 
> On Tue, Dec 11, 2018 at 04:27:19PM -0500, Ted Unangst wrote:
> > Mark Kettenis wrote:
> > > > From: "Ted Unangst" 
> > > > Date: Mon, 10 Dec 2018 14:14:08 -0500
> > > > Content-Type: text/plain; charset=utf-8
> > > > 
> > > > So I was actually looking at the passwd check rules because I wanted
> > > > to add a flag to disable the 3 bad passwords then ok whatever.
> > > > 
> > > > This adds passwd -w to allow user to skip the default 3 warnings and
> > > > just do what they want. If, by chance, you have configured warnings
> > > > in login.conf then they can't override that.
> > > 
> > > What is the motivation for this diff?
> > 
> > i get tired of typing the same password five times.
>  
> I also get tired of running 'doas foo' as root and being denied... Not trying
> to hijack the thread but could we "fix" that as well?

Add

permit nopass keepenv root as root

in your /etc/doas.conf



Re: allow weak passwd

2018-12-11 Thread Antoine Jacoutot
On Tue, Dec 11, 2018 at 04:27:19PM -0500, Ted Unangst wrote:
> Mark Kettenis wrote:
> > > From: "Ted Unangst" 
> > > Date: Mon, 10 Dec 2018 14:14:08 -0500
> > > Content-Type: text/plain; charset=utf-8
> > > 
> > > So I was actually looking at the passwd check rules because I wanted
> > > to add a flag to disable the 3 bad passwords then ok whatever.
> > > 
> > > This adds passwd -w to allow user to skip the default 3 warnings and
> > > just do what they want. If, by chance, you have configured warnings
> > > in login.conf then they can't override that.
> > 
> > What is the motivation for this diff?
> 
> i get tired of typing the same password five times.
 
I also get tired of running 'doas foo' as root and being denied... Not trying
to hijack the thread but could we "fix" that as well?

-- 
Antoine



Re: allow weak passwd

2018-12-11 Thread Mark Kettenis
> From: "Ted Unangst" 
> Cc: tech@openbsd.org
> Date: Tue, 11 Dec 2018 16:27:19 -0500
> Content-Type: text/plain; charset=utf-8
> 
> Mark Kettenis wrote:
> > > From: "Ted Unangst" 
> > > Date: Mon, 10 Dec 2018 14:14:08 -0500
> > > Content-Type: text/plain; charset=utf-8
> > > 
> > > So I was actually looking at the passwd check rules because I wanted
> > > to add a flag to disable the 3 bad passwords then ok whatever.
> > > 
> > > This adds passwd -w to allow user to skip the default 3 warnings and
> > > just do what they want. If, by chance, you have configured warnings
> > > in login.conf then they can't override that.
> > 
> > What is the motivation for this diff?
> 
> i get tired of typing the same password five times.

Even one simple enough to trigger the warnings?

The current behaviour isn't really advertised.  I fear that adding -w
would encourage people to actually use it.



Re: make build as root fails when SUDO=doas

2018-12-11 Thread Theo de Raadt
Ted Unangst  wrote:

> Marc Espie wrote:
> > > > - try to remove the files normally first
> > > >  rm -f ${SUDO_CLEAN} || test -z "${SUDO}" || ${SUDO} rm -f 
> > > > ${SUDO_CLEAN}
> > > > 
> > > > this should actually fix the issue.
> > > > 
> > > > Any other directory with that problem ?
> > > 
> > > that fix the issue and the build continues fine
> > 
> > So okay from source people ? tedu, guenther, theo, krw ? somebody else ?
> 
> does anywhere else in the tree do this? aren't most (all) things either done
> as root or not done as root?

I also don't understand what the point is here.

release(9) shows the correct build process.

you start build as root, to permit the priv-drop security model we
designed in 2017.

If on the other hand you build from a regular user below, with doas
configured to allow escalation at any point in time, the regular user
below CAN ALWAYS BECOME ROOT SO YOU HAVE NO SECURITY MODEL IN MIND AT
ALL, while you operate on Makefile and such you downloaded from elsewhere

Such use of sudo/doas is an ANTI-PATTERN



Re: make build as root fails when SUDO=doas

2018-12-11 Thread Ted Unangst
Marc Espie wrote:
> > > - try to remove the files normally first
> > >  rm -f ${SUDO_CLEAN} || test -z "${SUDO}" || ${SUDO} rm -f 
> > > ${SUDO_CLEAN}
> > > 
> > > this should actually fix the issue.
> > > 
> > > Any other directory with that problem ?
> > 
> > that fix the issue and the build continues fine
> 
> So okay from source people ? tedu, guenther, theo, krw ? somebody else ?

does anywhere else in the tree do this? aren't most (all) things either done
as root or not done as root?



Re: allow weak passwd

2018-12-11 Thread Ted Unangst
Mark Kettenis wrote:
> > From: "Ted Unangst" 
> > Date: Mon, 10 Dec 2018 14:14:08 -0500
> > Content-Type: text/plain; charset=utf-8
> > 
> > So I was actually looking at the passwd check rules because I wanted
> > to add a flag to disable the 3 bad passwords then ok whatever.
> > 
> > This adds passwd -w to allow user to skip the default 3 warnings and
> > just do what they want. If, by chance, you have configured warnings
> > in login.conf then they can't override that.
> 
> What is the motivation for this diff?

i get tired of typing the same password five times.



Re: sysv shm free(9) sizes

2018-12-11 Thread Alexander Bluhm
On Tue, Dec 11, 2018 at 02:45:47PM -0200, Martin Pieuchot wrote:
> ok?

OK bluhm@

> Index: kern/sysv_shm.c
> ===
> RCS file: /cvs/src/sys/kern/sysv_shm.c,v
> retrieving revision 1.69
> diff -u -p -r1.69 sysv_shm.c
> --- kern/sysv_shm.c   15 Sep 2016 02:00:16 -  1.69
> +++ kern/sysv_shm.c   11 Dec 2018 16:42:55 -
> @@ -506,16 +506,18 @@ shmexit(struct vmspace *vm)
>  {
>   struct shmmap_head *shmmap_h;
>   struct shmmap_state *shmmap_s;
> + size_t size;
>   int i;
>  
>   shmmap_h = (struct shmmap_head *)vm->vm_shm;
>   if (shmmap_h == NULL)
>   return;
> + size = sizeof(int) + shmmap_h->shmseg * sizeof(struct shmmap_state);
>   for (i = 0, shmmap_s = shmmap_h->state; i < shmmap_h->shmseg;
>   i++, shmmap_s++)
>   if (shmmap_s->shmid != -1)
>   shm_delete_mapping(vm, shmmap_s);
> - free(vm->vm_shm, M_SHM, 0);
> + free(vm->vm_shm, M_SHM, size);
>   vm->vm_shm = NULL;
>  }
>  
> @@ -594,7 +596,8 @@ sysctl_sysvshm(int *name, u_int namelen,
>   M_SHM, M_WAITOK|M_ZERO);
>   memcpy(newsegs, shmsegs,
>   shminfo.shmmni * sizeof(struct shmid_ds *));
> - free(shmsegs, M_SHM, 0);
> + free(shmsegs, M_SHM,
> + shminfo.shmmni * sizeof(struct shmid_ds *));
>   shmsegs = newsegs;
>   newseqs = mallocarray(val, sizeof(unsigned short), M_SHM,
>   M_WAITOK|M_ZERO);



Re: SVID semaphores free(9) sizes

2018-12-11 Thread Alexander Bluhm
On Tue, Dec 11, 2018 at 02:40:16PM -0200, Martin Pieuchot wrote:
> ok?

OK bluhm@

> Index: kern/sysv_sem.c
> ===
> RCS file: /cvs/src/sys/kern/sysv_sem.c,v
> retrieving revision 1.53
> diff -u -p -r1.53 sysv_sem.c
> --- kern/sysv_sem.c   14 Mar 2015 03:38:50 -  1.53
> +++ kern/sysv_sem.c   11 Dec 2018 16:36:20 -
> @@ -275,7 +275,8 @@ semctl1(struct proc *p, int semid, int s
>   semaptr->sem_perm.cuid = cred->cr_uid;
>   semaptr->sem_perm.uid = cred->cr_uid;
>   semtot -= semaptr->sem_nsems;
> - free(semaptr->sem_base, M_SEM, 0);
> + free(semaptr->sem_base, M_SEM,
> + semaptr->sem_nsems * sizeof(struct sem));
>   pool_put(_pool, semaptr);
>   sema[ix] = NULL;
>   semundo_clear(ix, -1);
> @@ -881,8 +882,8 @@ sysctl_sysvsem(int *name, u_int namelen,
>   M_WAITOK|M_ZERO);
>   memcpy(newseqs, semseqs,
>   seminfo.semmni * sizeof(unsigned short));
> - free(sema, M_SEM, 0);
> - free(semseqs, M_SEM, 0);
> + free(sema, M_SEM, seminfo.semmni * sizeof(struct semid_ds *));
> + free(semseqs, M_SEM, seminfo.semmni * sizeof(unsigned short));
>   sema = sema_new;
>   semseqs = newseqs;
>   seminfo.semmni = val;



Re: bridge nits

2018-12-11 Thread Alexander Bluhm
On Tue, Dec 11, 2018 at 03:17:46PM -0200, Martin Pieuchot wrote:
> - Unify the two hooks by passing the same argument
> - Check for nullity before dereferencing `if_bridgeport', this will
>   matter when we go MP
> - Use the same pattern to find a member in the ioctl path
> 
> ok?

OK bluhm@

>  void
>  bridge_ifdetach(void *arg)
>  {
> + struct bridge_iflist *bif = (struct bridge_iflist *)arg;

You don't need this cast.  The compiler knows how to convert a void
pointer.



Re: make build as root fails when SUDO=doas

2018-12-11 Thread Marc Espie
On Tue, Dec 11, 2018 at 06:50:07PM +0100, Solene Rapenne wrote:
> Marc Espie  wrote:
> > On Mon, Dec 10, 2018 at 01:33:49PM +0100, Solene Rapenne wrote:
> > > hi
> > > 
> > > I have SUDO=doas in /etc/mk.conf for ports, this is preventing a `make 
> > > build`
> > > in /usr/src as root if /etc/doas.conf doesn't have a line "permit nopass 
> > > root
> > > as root". This fails when using "doas" in regress/usr/bin/ssh/
> > > 
> > > doas: Operation not permitted
> > > *** Error 1 in regress/usr.bin/ssh (Makefile:212 'clean')
> > > *** Error 1 in regress/usr.bin (:48 'cleandir')
> > > *** Error 1 in regress (:48 'cleandir')
> > > *** Error 1 in . (:48 'cleandir')
> > > *** Error 1 in . (Makefile:86 'do-build')
> > > *** Error 1 in /usr/src (Makefile:74 'build')
> > > 
> > > 
> > > the issue comes from the 3rd line of that extract from Makefile:212
> > > 
> > > clean: ${CLEAN_SUBDIR}
> > > rm -f ${CLEANFILES}
> > > test -z "${SUDO}" || ${SUDO} rm -f ${SUDO_CLEAN}
> > > rm -rf .putty
> > > 
> > > Not sure how to fix it. Maybe people shouldn't try to compile as root when
> > > having SUDO=doas set and then, it's not an issue anymore?
> > 
> > There are several possibilities:
> > - add a test similar to the one in src/Makefile, e.g., not run
> > sudo if you're root already (relatively complicated for no obvious benefit)
> > 
> > - try to remove the files normally first
> >  rm -f ${SUDO_CLEAN} || test -z "${SUDO}" || ${SUDO} rm -f 
> > ${SUDO_CLEAN}
> > 
> > this should actually fix the issue.
> > 
> > Any other directory with that problem ?
> 
> that fix the issue and the build continues fine

So okay from source people ? tedu, guenther, theo, krw ? somebody else ?



Re: make build as root fails when SUDO=doas

2018-12-11 Thread Solene Rapenne
Marc Espie  wrote:
> On Mon, Dec 10, 2018 at 01:33:49PM +0100, Solene Rapenne wrote:
> > hi
> > 
> > I have SUDO=doas in /etc/mk.conf for ports, this is preventing a `make 
> > build`
> > in /usr/src as root if /etc/doas.conf doesn't have a line "permit nopass 
> > root
> > as root". This fails when using "doas" in regress/usr/bin/ssh/
> > 
> > doas: Operation not permitted
> > *** Error 1 in regress/usr.bin/ssh (Makefile:212 'clean')
> > *** Error 1 in regress/usr.bin (:48 'cleandir')
> > *** Error 1 in regress (:48 'cleandir')
> > *** Error 1 in . (:48 'cleandir')
> > *** Error 1 in . (Makefile:86 'do-build')
> > *** Error 1 in /usr/src (Makefile:74 'build')
> > 
> > 
> > the issue comes from the 3rd line of that extract from Makefile:212
> > 
> > clean: ${CLEAN_SUBDIR}
> > rm -f ${CLEANFILES}
> > test -z "${SUDO}" || ${SUDO} rm -f ${SUDO_CLEAN}
> > rm -rf .putty
> > 
> > Not sure how to fix it. Maybe people shouldn't try to compile as root when
> > having SUDO=doas set and then, it's not an issue anymore?
> 
> There are several possibilities:
> - add a test similar to the one in src/Makefile, e.g., not run
> sudo if you're root already (relatively complicated for no obvious benefit)
> 
> - try to remove the files normally first
>  rm -f ${SUDO_CLEAN} || test -z "${SUDO}" || ${SUDO} rm -f 
> ${SUDO_CLEAN}
> 
> this should actually fix the issue.
> 
> Any other directory with that problem ?

that fix the issue and the build continues fine



bridge nits

2018-12-11 Thread Martin Pieuchot
- Unify the two hooks by passing the same argument
- Check for nullity before dereferencing `if_bridgeport', this will
  matter when we go MP
- Use the same pattern to find a member in the ioctl path

ok?

Index: net/if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.314
diff -u -p -r1.314 if_bridge.c
--- net/if_bridge.c 7 Dec 2018 16:19:40 -   1.314
+++ net/if_bridge.c 11 Dec 2018 17:13:24 -
@@ -297,9 +297,10 @@ bridge_ioctl(struct ifnet *ifp, u_long c
}
 
/* If it's in the span list, it can't be a member. */
-   TAILQ_FOREACH(bif, >sc_spanlist, next)
+   TAILQ_FOREACH(bif, >sc_spanlist, next) {
if (bif->ifp == ifs)
break;
+   }
if (bif != NULL) {
error = EBUSY;
break;
@@ -335,7 +336,7 @@ bridge_ioctl(struct ifnet *ifp, u_long c
SIMPLEQ_INIT(>bif_brlout);
ifs->if_bridgeport = (caddr_t)bif;
bif->bif_dhcookie = hook_establish(ifs->if_detachhooks, 0,
-   bridge_ifdetach, ifs);
+   bridge_ifdetach, bif);
if_ih_insert(bif->ifp, bridge_input, NULL);
TAILQ_INSERT_TAIL(>sc_iflist, bif, next);
break;
@@ -399,17 +400,20 @@ bridge_ioctl(struct ifnet *ifp, u_long c
case SIOCBRDGDELS:
if ((error = suser(curproc)) != 0)
break;
+   ifs = ifunit(req->ifbr_ifsname);
+   if (ifs == NULL) {
+   error = ENOENT;
+   break;
+   }
TAILQ_FOREACH(bif, >sc_spanlist, next) {
-   if (strncmp(bif->ifp->if_xname, req->ifbr_ifsname,
-   sizeof(bif->ifp->if_xname)) == 0) {
-   bridge_spandetach(bif);
+   if (bif->ifp == ifs)
break;
-   }
}
if (bif == NULL) {
error = ENOENT;
break;
}
+   bridge_spandetach(bif);
break;
case SIOCBRDGGIFFLGS:
ifs = ifunit(req->ifbr_ifsname);
@@ -569,12 +573,8 @@ bridge_ioctl(struct ifnet *ifp, u_long c
 void
 bridge_ifdetach(void *arg)
 {
-   struct ifnet *ifp = (struct ifnet *)arg;
-   struct bridge_softc *sc;
-   struct bridge_iflist *bif;
-
-   bif = (struct bridge_iflist *)ifp->if_bridgeport;
-   sc = bif->bridge_sc;
+   struct bridge_iflist *bif = (struct bridge_iflist *)arg;
+   struct bridge_softc *sc = bif->bridge_sc;
 
bridge_delete(sc, bif);
 }
@@ -713,6 +713,7 @@ int
 bridge_output(struct ifnet *ifp, struct mbuf *m, struct sockaddr *sa,
 struct rtentry *rt)
 {
+   struct bridge_iflist *bif;
struct ether_header *eh;
struct ifnet *dst_if = NULL;
struct bridge_rtnode *dst_p = NULL;
@@ -727,11 +728,12 @@ bridge_output(struct ifnet *ifp, struct 
KERNEL_ASSERT_LOCKED();
 
/* ifp must be a member interface of the bridge. */
-   if (ifp->if_bridgeport == NULL) {
+   bif = (struct bridge_iflist *)ifp->if_bridgeport;
+   if (bif == NULL) {
m_freem(m);
return (EINVAL);
}
-   sc = ((struct bridge_iflist *)ifp->if_bridgeport)->bridge_sc;
+   sc = bif->bridge_sc;
 
if (m->m_len < sizeof(*eh)) {
m = m_pullup(m, sizeof(*eh));
Index: net/bridgectl.c
===
RCS file: /cvs/src/sys/net/bridgectl.c,v
retrieving revision 1.12
diff -u -p -r1.12 bridgectl.c
--- net/bridgectl.c 14 Nov 2018 17:07:44 -  1.12
+++ net/bridgectl.c 11 Dec 2018 17:04:16 -
@@ -355,10 +355,14 @@ void
 bridge_rtagenode(struct ifnet *ifp, int age)
 {
struct bridge_softc *sc;
+   struct bridge_iflist *bif;
struct bridge_rtnode *n;
int i;
 
-   sc = ((struct bridge_iflist *)ifp->if_bridgeport)->bridge_sc;
+   bif = (struct bridge_iflist *)ifp->if_bridgeport;
+   if (bif == NULL)
+   return;
+   sc = bif->bridge_sc;
if (sc == NULL)
return;
 
@@ -525,7 +529,11 @@ bridge_update(struct ifnet *ifp, struct 
addr = (u_int8_t *)ea;
 
bif = (struct bridge_iflist *)ifp->if_bridgeport;
+   if (bif == NULL)
+   return;
sc = bif->bridge_sc;
+   if (sc == NULL)
+   return;
 
/*
 * Update the bridge interface if it is in



Re: Importing FreeBSD eMMC code

2018-12-11 Thread Heppler, J. Scott

The FreeBSD 12 code, released today, does recognize the eMMC drive

mmc0:  on sdhci_pci0
mmcsd0: 31GB  at mmc0 
200.0MHz/8bit/8192-block
mmcsd0boot0: 4MB partion 1 at mmcsd0
mmcsd0boot1: 4MB partion 2 at mmcsd0
mmcsd0rpmb: 4MB partion 3 at mmcsd0


The drive was accessible by FreeBSD's fdisk/parted.

--
J. Scott Heppler
--- Begin Message ---
Heppler, J. Scott [shep...@centurylink.net] wrote:
> I'll add my dmesg from an HP Stream 14 cb112wm
> 
> OpenBSD 6.4-current (RAMDISK_CD) #465: Wed Nov 28 22:26:21 MST 2018
>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> sdhc0 at pci0 dev 28 function 0 vendor "Intel", unknown product 0x31cc rev 
> 0x03: apic 1 int 39
> sdhc0: SDHC 3.0, 200 MHz base clock
> sdmmc0 at sdhc0: 8-bit, sd high-speed, mmc high-speed, dma
...
> sdmmc0: can't enable card
...

Looks like you are hitting a bug...
--- End Message ---


sysv shm free(9) sizes

2018-12-11 Thread Martin Pieuchot
ok?

Index: kern/sysv_shm.c
===
RCS file: /cvs/src/sys/kern/sysv_shm.c,v
retrieving revision 1.69
diff -u -p -r1.69 sysv_shm.c
--- kern/sysv_shm.c 15 Sep 2016 02:00:16 -  1.69
+++ kern/sysv_shm.c 11 Dec 2018 16:42:55 -
@@ -506,16 +506,18 @@ shmexit(struct vmspace *vm)
 {
struct shmmap_head *shmmap_h;
struct shmmap_state *shmmap_s;
+   size_t size;
int i;
 
shmmap_h = (struct shmmap_head *)vm->vm_shm;
if (shmmap_h == NULL)
return;
+   size = sizeof(int) + shmmap_h->shmseg * sizeof(struct shmmap_state);
for (i = 0, shmmap_s = shmmap_h->state; i < shmmap_h->shmseg;
i++, shmmap_s++)
if (shmmap_s->shmid != -1)
shm_delete_mapping(vm, shmmap_s);
-   free(vm->vm_shm, M_SHM, 0);
+   free(vm->vm_shm, M_SHM, size);
vm->vm_shm = NULL;
 }
 
@@ -594,7 +596,8 @@ sysctl_sysvshm(int *name, u_int namelen,
M_SHM, M_WAITOK|M_ZERO);
memcpy(newsegs, shmsegs,
shminfo.shmmni * sizeof(struct shmid_ds *));
-   free(shmsegs, M_SHM, 0);
+   free(shmsegs, M_SHM,
+   shminfo.shmmni * sizeof(struct shmid_ds *));
shmsegs = newsegs;
newseqs = mallocarray(val, sizeof(unsigned short), M_SHM,
M_WAITOK|M_ZERO);



SVID semaphores free(9) sizes

2018-12-11 Thread Martin Pieuchot
ok?

Index: kern/sysv_sem.c
===
RCS file: /cvs/src/sys/kern/sysv_sem.c,v
retrieving revision 1.53
diff -u -p -r1.53 sysv_sem.c
--- kern/sysv_sem.c 14 Mar 2015 03:38:50 -  1.53
+++ kern/sysv_sem.c 11 Dec 2018 16:36:20 -
@@ -275,7 +275,8 @@ semctl1(struct proc *p, int semid, int s
semaptr->sem_perm.cuid = cred->cr_uid;
semaptr->sem_perm.uid = cred->cr_uid;
semtot -= semaptr->sem_nsems;
-   free(semaptr->sem_base, M_SEM, 0);
+   free(semaptr->sem_base, M_SEM,
+   semaptr->sem_nsems * sizeof(struct sem));
pool_put(_pool, semaptr);
sema[ix] = NULL;
semundo_clear(ix, -1);
@@ -881,8 +882,8 @@ sysctl_sysvsem(int *name, u_int namelen,
M_WAITOK|M_ZERO);
memcpy(newseqs, semseqs,
seminfo.semmni * sizeof(unsigned short));
-   free(sema, M_SEM, 0);
-   free(semseqs, M_SEM, 0);
+   free(sema, M_SEM, seminfo.semmni * sizeof(struct semid_ds *));
+   free(semseqs, M_SEM, seminfo.semmni * sizeof(unsigned short));
sema = sema_new;
semseqs = newseqs;
seminfo.semmni = val;



Re: OpenBSD kernel implementation

2018-12-11 Thread Jason A. Donenfeld
Hi Brad,

Exciting to see you working on this. However, I'm afraid the
implementation you describe sounds deeply flawed and kind of misses
the point of WireGuard.

On Tue, Dec 11, 2018 at 2:24 PM  wrote:
> Currently, I want to take all the code that doesn't need to be in the
> kernel and move it to userspace, which is essentially the handshake
> code, timeout timers and state machine functions. What is left is
> essentially the transport function (IPSEC transform equivalent),
> peforming simple crypto on incoming/outgoing packets. This design is
> somewhat similar to how IPSEC is currently implemented in OpenBSD. I
> believe this is a reasonable approach, but welcome comments on things I
> may not have considered.

Do not do this. This is entirely unacceptable and wholly contrary to
the design approach of WireGuard. The transport layer and handshake
layer exist on the same state machine, and I designed the handshake
specifically to be extremely simple and implementable in kernel space.
I'm happy to help you clean up your current approach -- which seems
nicer and closer to the goal -- but your proposed separated approach
is really deeply flawed, and overly complex. Do not make this mistake.

Rather, let's clean up your current WIP together. If you're on IRC,
I'm happy to discuss with you there (I'm zx2c4 on Freenode) and we can
get this into shape.

Regards,
Jason



Re: request for testing: patch for boot loader out of mem

2018-12-11 Thread Otto Moerbeek
On Mon, Dec 10, 2018 at 11:44:47AM +0100, Otto Moerbeek wrote:

> On Mon, Dec 10, 2018 at 08:30:10AM +0100, Otto Moerbeek wrote:
> 
> > Hi,
> > 
> > the bootloader uses a very simple allocator for dynamic memory. It
> > maintains a list of free allocations. If it needs a block, it searches
> > the freelist and returns the smallest allocation that fits.
> > 
> > Allocation patterns like this (starting with an empty freelist)
> > 
> > alloc(big)
> > free(big)
> > alloc(small)
> > 
> > will assigned a big block for the small allocation, wasting most
> > memory. The allocator does not split up this block. After this, a new
> > big allocation will grow the heap with the big amount. This diff
> > changes the strategy by not re-using a block from the free list if
> > half the space or more would be wasted. Instead, it grows the heap by
> > the requested amount.
> > 
> > This make it possible for me to boot using a root fs with a large
> > blocksize. There have been several reports of large roots not working
> > (the bootloader allocates memory based om the blocksize of the file
> > system, and by default larger filesystems use larger blocks).
> > 
> > How to test
> > ===
> > 
> > Apply diff and do a full build including building release. After that,
> > either upgrade using your newly built cd64.iso, bsd.rd or other
> > mechanism or do a full install. Test that you can boot afterwards.
> > 
> > This needs to be tested on various platforms, both will small and big
> > (> 600G) root filesystems.  Yes, this is tedious, but we want large
> > coverage of different cases.
> > 
> > -Otto
> 
> As it turns out by my own testing, on amd64 root filssytems using 32k
> blocks now work fine, but 64k fs blocks still hit a ceiling. This
> corresponds to > 512G disks if you use the defaults.
> 
>   -Otto
> 

New diff that also works on root filesystems > 500G. It avoid using a
large bouncebuffer by reding large buffers in a loop instead of one go.

-Otto

Index: arch/amd64/stand/libsa/biosdev.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/libsa/biosdev.c,v
retrieving revision 1.32
diff -u -p -r1.32 biosdev.c
--- arch/amd64/stand/libsa/biosdev.c10 Aug 2018 16:41:35 -  1.32
+++ arch/amd64/stand/libsa/biosdev.c11 Dec 2018 13:00:02 -
@@ -340,11 +340,26 @@ biosd_io(int rw, bios_diskinfo_t *bd, u_
return error;
 }
 
+#define MAXSECTS 32
+
 int
 biosd_diskio(int rw, struct diskinfo *dip, u_int off, int nsect, void *buf)
 {
-   return biosd_io(rw, >bios_info, off, nsect, buf);
+   int i, n, ret;
+
+   /*
+* Avoid doing too large reads, the bounce buffer used by biosd_io()
+* might run us out-of-mem.
+*/
+   for (i = 0, ret = 0; ret == 0 && nsect > 0;
+   i += MAXSECTS, nsect -= MAXSECTS) {
+   n = nsect >= MAXSECTS ? MAXSECTS : nsect;
+   ret = biosd_io(rw, >bios_info, off + i, n,
+   buf + i * DEV_BSIZE);
+   }
+   return ret;
 }
+
 /*
  * Try to read the bsd label on the given BIOS device.
  */
@@ -715,7 +730,6 @@ biosstrategy(void *devdata, int rw, dadd
 size_t *rsize)
 {
struct diskinfo *dip = (struct diskinfo *)devdata;
-   bios_diskinfo_t *bd = >bios_info;
u_int8_t error = 0;
size_t nsect;
 
@@ -732,7 +746,7 @@ biosstrategy(void *devdata, int rw, dadd
if (blk < 0)
error = EINVAL;
else
-   error = biosd_io(rw, bd, blk, nsect, buf);
+   error = biosd_diskio(rw, dip, blk, nsect, buf);
 
 #ifdef BIOS_DEBUG
if (debug) {
Index: arch/i386/stand/libsa/biosdev.c
===
RCS file: /cvs/src/sys/arch/i386/stand/libsa/biosdev.c,v
retrieving revision 1.98
diff -u -p -r1.98 biosdev.c
--- arch/i386/stand/libsa/biosdev.c 6 Sep 2018 11:50:54 -   1.98
+++ arch/i386/stand/libsa/biosdev.c 11 Dec 2018 13:00:02 -
@@ -341,11 +341,26 @@ biosd_io(int rw, bios_diskinfo_t *bd, u_
return error;
 }
 
+#define MAXSECTS 32
+
 int
 biosd_diskio(int rw, struct diskinfo *dip, u_int off, int nsect, void *buf)
 {
-   return biosd_io(rw, >bios_info, off, nsect, buf);
+   int i, n, ret;
+
+   /*
+* Avoid doing too large reads, the bounce buffer used by biosd_io()
+* might run us out-of-mem.
+*/
+   for (i = 0, ret = 0; ret == 0 && nsect > 0;
+   i += MAXSECTS, nsect -= MAXSECTS) {
+   n = nsect >= MAXSECTS ? MAXSECTS : nsect;
+   ret = biosd_io(rw, >bios_info, off + i, n,
+   buf + i * DEV_BSIZE);
+   }
+   return ret;
 }
+
 /*
  * Try to read the bsd label on the given BIOS device.
  */
@@ -716,7 +731,6 @@ biosstrategy(void *devdata, int rw, dadd
 size_t *rsize)
 {
struct diskinfo *dip = (struct diskinfo *)devdata;
-   bios_diskinfo_t *bd = >bios_info;
u_int8_t 

Re: snmpctl walk don't show neighbours

2018-12-11 Thread Martijn van Duren
As requested by deraadt@, here's a diff that includes the leaf value
itself.

$ ./snmpctl snmp walk host oid 1.3.6.1.4.1.9.9.273.1.1.2.1.1  
1.1=1
1.2=5
$ ./snmpctl snmp walk host oid 1.3.6.1.4.1.9.9.273.1.1.2.1.1.1
1=1
$

On 12/11/18 1:10 PM, Martijn van Duren wrote:
> So I got puzzled because of a behavioural difference between snmpwalk
> and snmpctl walk.
> 
> snmp returns the next element after the requested element for a
> getNextRequest. So for a leaf-element this can be it's closest
> neighbour. e.g.
> $ make && snmpctl snmp walk host oid 1.3.6.1.4.1.9.9.273.1.1.2.1.1
> 1.1=1
> 1.2=5
> icinga2$ make && snmpctl snmp walk host oid 1.3.6.1.4.1.9.9.273.1.1.2.1.1.1
> 2=5
> icinga2$ make && snmpctl snmp walk host oid 1.3.6.1.4.1.9.9.273.1.1.2.1.1.2
> 1=0
> 
> snmpwalk returns the requested leaf if no subelements can be found:
> $ snmpwalk -v2c -c public host 1.3.6.1.4.1.9.9.273.1.1.2.1.1.1
> SNMPv2-SMI::enterprises.9.9.273.1.1.2.1.1.1 = Gauge32: 1
> $ snmpwalk -v2c -c public host 1.3.6.1.4.1.9.9.273.1.1.2.1.1.2
> SNMPv2-SMI::enterprises.9.9.273.1.1.2.1.1.2 = Gauge32: 5
> 
> The problem for snmpctl is that we always return the first match, even
> if even if it's not in our scope. The diff below removes that
> requirement and also makes sure we also match itself, so to keep
> "snmp get" working.
> 
> Note that this diff doesn't include the value of the leaf itself, unlike 
> snmpwalk, since that would require extra wiring and isn't exactly what's
> being asked. If people would like this it could probably be added.
> 
> $ ./snmpctl snmp walk host oid 1.3.6.1.4.1.9.9.273.1.1.2.1.1.1
> $ ./snmpctl snmp get 10.17.11.27 oid 1.3.6.1.4.1.9.9.273.1.1.2.1.1.1
> 1=1
> $
> 
> OK?
> 
> martijn@
> 

Index: snmpclient.c
===
RCS file: /cvs/src/usr.sbin/snmpctl/snmpclient.c,v
retrieving revision 1.18
diff -u -p -r1.18 snmpclient.c
--- snmpclient.c25 Nov 2018 14:58:28 -  1.18
+++ snmpclient.c11 Dec 2018 13:02:06 -
@@ -220,6 +220,11 @@ snmpc_request(struct snmpc *sc, unsigned
if ((ret = snmpc_response(sc)) != 0) { 
if (ret == -1)
err(1, "response");
+   if (sc->sc_nresp == 0) {
+   bcopy(>sc_root_oid, >sc_oid,
+   sizeof(sc->sc_oid));
+   snmpc_request(sc, SNMP_C_GETREQ);
+   }
return;
}   
 
@@ -235,7 +240,7 @@ snmpc_response(struct snmpc *sc)
char buf[BUFSIZ];
struct ber_element  *resp = NULL, *s, *e;
char*value = NULL, *p;
-   int  ret = 0;
+   int  ret = 0, bercmp;
 
/* Receive response */
if (snmpc_recvresp(sc->sc_fd, sc->sc_version,
@@ -250,12 +255,12 @@ snmpc_response(struct snmpc *sc)
goto fail;
 
/* Break if the returned OID is not a child of the root. */
-   if (sc->sc_nresp &&
-   (ber_oid_cmp(>sc_root_oid, >sc_oid) != 2 ||
+   bercmp = ber_oid_cmp(>sc_root_oid, >sc_oid);
+   if ((bercmp != 0 && bercmp != 2) ||
e->be_class == BER_CLASS_CONTEXT ||
-   e->be_type == BER_TYPE_NULL)) {
-   ret = 1; 
-   break;
+   e->be_type == BER_TYPE_NULL) {
+   ber_free_elements(resp);
+   return 1;
}   
 
if ((value = smi_print_element(e)) != NULL) {



snmpctl walk include 0 oids

2018-12-11 Thread Martijn van Duren
The diff below allows me to walk oids that contain a 0, while at the 
same time disallow the walking of neighbouring nodes.

I only lightly tested this with snmpctl walk and I haven't looked at
how snmpd hooks into this, but considering reyk put the function there
with the "Add initial SNMP client utility to snmpctl(8)." commit I
reckon it's unused. Some input from snmpd experts would be welcome
though.

$ snmpctl -n snmp walk 10.17.11.26 oid 0.0 | head -1
1.0.8802.1.1.2.1.3.1.0=4
$ ./snmpctl -n snmp walk 10.17.11.26 oid 0.0 | head -1
$ snmpctl -n snmp walk 10.17.11.26 oid 1.0.8802  
1.0.8802.1.1.2.1.3.1.0=4
$ ./snmpctl -n snmp walk 10.17.11.26 oid 1.0.8802 
1.0.8802.1.1.2.1.3.1.0=4
1.0.8802.1.1.2.1.3.2.0=""
1.0.8802.1.1.2.1.3.3.0=""
...
$ snmpwalk -v2c -cpublic 10.17.11.26 1.0.8802
iso.0.8802.1.1.2.1.3.1.0 = INTEGER: 4
iso.0.8802.1.1.2.1.3.2.0 = Hex-STRING: XX XX XX XX XX XX 
iso.0.8802.1.1.2.1.3.3.0 = STRING: ""
...

martijn@

Index: ber.c
===
RCS file: /cvs/src/usr.sbin/snmpd/ber.c,v
retrieving revision 1.50
diff -u -p -r1.50 ber.c
--- ber.c   27 Nov 2018 12:10:29 -  1.50
+++ ber.c   11 Dec 2018 12:41:18 -
@@ -456,23 +456,23 @@ int
 ber_oid_cmp(struct ber_oid *a, struct ber_oid *b)
 {
size_t   i;
-   for (i = 0; i < BER_MAX_OID_LEN; i++) {
-   if (a->bo_id[i] != 0) {
-   if (a->bo_id[i] == b->bo_id[i])
-   continue;
-   else if (a->bo_id[i] < b->bo_id[i]) {
-   /* b is a successor of a */
-   return (1);
-   } else {
-   /* b is a predecessor of a */
-   return (-1);
-   }
-   } else if (b->bo_id[i] != 0) {
-   /* b is larger, but a child of a */
-   return (2);
-   } else
-   break;
+   /* b is a predecessor of a */
+   if (a->bo_n > b->bo_n)
+   return -1;
+   for (i = 0; i < a->bo_n; i++) {
+   if (a->bo_id[i] == b->bo_id[i])
+   continue;
+   else if (a->bo_id[i] < b->bo_id[i]) {
+   /* b is a successor of a */
+   return (1);
+   } else {
+   /* b is a predecessor of a */
+   return (-1);
+   }
}
+   /* b is larger, but a child of a */
+   if (a->bo_n < b->bo_n)
+   return (2);
 
/* b and a are identical */
return (0);



snmpctl walk don't show neighbours

2018-12-11 Thread Martijn van Duren
So I got puzzled because of a behavioural difference between snmpwalk
and snmpctl walk.

snmp returns the next element after the requested element for a
getNextRequest. So for a leaf-element this can be it's closest
neighbour. e.g.
$ make && snmpctl snmp walk host oid 1.3.6.1.4.1.9.9.273.1.1.2.1.1
1.1=1
1.2=5
icinga2$ make && snmpctl snmp walk host oid 1.3.6.1.4.1.9.9.273.1.1.2.1.1.1
2=5
icinga2$ make && snmpctl snmp walk host oid 1.3.6.1.4.1.9.9.273.1.1.2.1.1.2
1=0

snmpwalk returns the requested leaf if no subelements can be found:
$ snmpwalk -v2c -c public host 1.3.6.1.4.1.9.9.273.1.1.2.1.1.1
SNMPv2-SMI::enterprises.9.9.273.1.1.2.1.1.1 = Gauge32: 1
$ snmpwalk -v2c -c public host 1.3.6.1.4.1.9.9.273.1.1.2.1.1.2
SNMPv2-SMI::enterprises.9.9.273.1.1.2.1.1.2 = Gauge32: 5

The problem for snmpctl is that we always return the first match, even
if even if it's not in our scope. The diff below removes that
requirement and also makes sure we also match itself, so to keep
"snmp get" working.

Note that this diff doesn't include the value of the leaf itself, unlike 
snmpwalk, since that would require extra wiring and isn't exactly what's
being asked. If people would like this it could probably be added.

$ ./snmpctl snmp walk host oid 1.3.6.1.4.1.9.9.273.1.1.2.1.1.1
$ ./snmpctl snmp get 10.17.11.27 oid 1.3.6.1.4.1.9.9.273.1.1.2.1.1.1
1=1
$

OK?

martijn@

Index: snmpclient.c
===
RCS file: /cvs/src/usr.sbin/snmpctl/snmpclient.c,v
retrieving revision 1.18
diff -u -p -r1.18 snmpclient.c
--- snmpclient.c25 Nov 2018 14:58:28 -  1.18
+++ snmpclient.c11 Dec 2018 12:05:46 -
@@ -56,7 +56,6 @@ struct snmpc {
int  sc_retry_max;
const char  *sc_community;
int  sc_version;
-   int  sc_nresp;
 };
 
 #defineSNMPC_RETRY_MAX 3
@@ -180,8 +179,6 @@ snmpc_run(struct snmpc *sc, enum actions
if (sc->sc_oid.bo_n > 2)
sc->sc_root_len = sc->sc_oid.bo_n - 1;
 
-   sc->sc_nresp = 0;
-
if (action == GET)
snmpc_request(sc, SNMP_C_GETREQ);
else if (action == BULKWALK)
@@ -235,7 +232,7 @@ snmpc_response(struct snmpc *sc)
char buf[BUFSIZ];
struct ber_element  *resp = NULL, *s, *e;
char*value = NULL, *p;
-   int  ret = 0;
+   int  ret = 0, bercmp;
 
/* Receive response */
if (snmpc_recvresp(sc->sc_fd, sc->sc_version,
@@ -250,10 +247,10 @@ snmpc_response(struct snmpc *sc)
goto fail;
 
/* Break if the returned OID is not a child of the root. */
-   if (sc->sc_nresp &&
-   (ber_oid_cmp(>sc_root_oid, >sc_oid) != 2 ||
+   bercmp = ber_oid_cmp(>sc_root_oid, >sc_oid);
+   if ((bercmp != 0 && bercmp != 2) ||
e->be_class == BER_CLASS_CONTEXT ||
-   e->be_type == BER_TYPE_NULL)) {
+   e->be_type == BER_TYPE_NULL) {
ret = 1; 
break;
}   
@@ -271,8 +268,6 @@ snmpc_response(struct snmpc *sc)
}
bcopy(>sc_oid, >sc_last_oid, sizeof(sc->sc_last_oid));
}
-
-   sc->sc_nresp++;
 
ber_free_elements(resp);
return (ret);