Re: struct ifnet locking [was Re: IFEF_MPSAFE]

2017-12-18 Thread Nick Hudson 

On 19/12/2017 03:43, Ryota Ozaki wrote:



BTW I committed a change that disables IFEF_MPSAFE by default on
all interfaces because it seems that IFEF_MPSAFE requires additional
changes to work safely with it. We should enable it by default if an
interface is guaranteed to be safe.

What additional changes?

Thanks,
Nick

Re: RFC: ipsec(4) pseudo interface

2017-12-18 Thread Christos Zoulas 
In article <20171218184400.ga27...@britannica.bec.de>,
Joerg Sonnenberger   wrote:
>On Mon, Dec 18, 2017 at 06:49:44PM +0900, Kengo NAKAHARA wrote:
>> (a) Add if_ipsec.4
>> (b) move current ipsec.4(for ipsec protocol) to ipsec.9, and then
>> add ipsec.4(for ipsec pseudo interface)
>> (c) any other
>
>I'd call it either ifipsec(4) or ipsecif(4).

Traditionally the names of devices drivers and protocols go to section 4.
So we have a conflict here, use one of the names Joerg suggested and cross
reference it on the top of the ipsec.4 page:

.Pp
This manual pages describes the IPSEC.
For the network device driver please see
.Xr ifipsec 4 .

christos

Re: getsockopt(2)

2017-12-18 Thread Robert Swindells 

David Holland  wrote:
>On Mon, Dec 18, 2017 at 07:21:33PM +, David Holland wrote:
> > On Thu, Dec 07, 2017 at 03:04:32PM +, Robert Swindells wrote:
> >  > I wrote:
> >  >> Does anyone know why we don't use the input 'optlen' parameter to the
> >  >> getsockopt(2) syscall, we do write back to it on return.
> >  >>  [...]
> >  >> 
> >  >> There are also lots of places in sctp_usrreq that want to use it.
> >  >> 
> >  >> I can set it with the following patch (line numbers will be slightly
> >  >> out), but wondered if there was a reason for the current behaviour.
> >  >>  [...]
> >  > 
> >  > Has anyone had any other thoughts on this ?
> >  > 
> >  > I still think that the one line change shown here is correct, it will 
> >  > allocate a buffer that gets filled by the stuff to be copied back to
> >  > userspace.
> > 
> > The man page for getsockopt says [irrelevant stuff]
>
>Oops, I guess I am missing something.

The current code isn't wrong.

In the "get" path, sockopt_set() or sockopt_setmbuf() will allocate a
buffer if needed, most other values are ints and can go in the 4 byte
buffer in the sockopt.

I guess it avoids needing to free the buffer if there is an error while
building up the data to return.

Re: getsockopt(2)

2017-12-18 Thread David Holland 
On Mon, Dec 18, 2017 at 07:21:33PM +, David Holland wrote:
 > On Thu, Dec 07, 2017 at 03:04:32PM +, Robert Swindells wrote:
 >  > I wrote:
 >  >> Does anyone know why we don't use the input 'optlen' parameter to the
 >  >> getsockopt(2) syscall, we do write back to it on return.
 >  >>  [...]
 >  >> 
 >  >> There are also lots of places in sctp_usrreq that want to use it.
 >  >> 
 >  >> I can set it with the following patch (line numbers will be slightly
 >  >> out), but wondered if there was a reason for the current behaviour.
 >  >>  [...]
 >  > 
 >  > Has anyone had any other thoughts on this ?
 >  > 
 >  > I still think that the one line change shown here is correct, it will 
 >  > allocate a buffer that gets filled by the stuff to be copied back to
 >  > userspace.
 > 
 > The man page for getsockopt says [irrelevant stuff]

Oops, I guess I am missing something.

-- 
David A. Holland
dholl...@netbsd.org

Re: getsockopt(2)

2017-12-18 Thread David Holland 
On Thu, Dec 07, 2017 at 03:04:32PM +, Robert Swindells wrote:
 > I wrote:
 >> Does anyone know why we don't use the input 'optlen' parameter to the
 >> getsockopt(2) syscall, we do write back to it on return.
 >>  [...]
 >> 
 >> There are also lots of places in sctp_usrreq that want to use it.
 >> 
 >> I can set it with the following patch (line numbers will be slightly
 >> out), but wondered if there was a reason for the current behaviour.
 >>  [...]
 > 
 > Has anyone had any other thoughts on this ?
 > 
 > I still think that the one line change shown here is correct, it will 
 > allocate a buffer that gets filled by the stuff to be copied back to
 > userspace.

The man page for getsockopt says that the optlen argument should be
initialized with the size before calling getsockopt:

 The parameters optval and optlen are used to access option values for
 setsockopt().  For getsockopt() they identify a buffer in which the value
 for the requested option(s) are to be returned.  For getsockopt(), optlen
 is a value-result parameter, initially containing the size of the buffer
 pointed to by optval, and modified on return to indicate the actual size
 of the value returned.

This is also the traditional behavior of this type of call (compare
e.g. getpeername) and there's no particular reason getsockopt should
be different.

So I think (a) any code we have that doesn't initialize the value is
wrong and should be fixed; (b) any existing kernel code that blats
values out to the buffer without checking the user's length is wrong
and should be fixed; and (c) if this is an endemic problem we should
fix all the wrong user code and then version the syscall before
changing the kernel to behave as documented. (but hopefully that isn't
necessary)

Am I missing something? I'm not sure how the subsequent discussion
morphed into ways to hack setsockopt to serve as getsockopt...

-- 
David A. Holland
dholl...@netbsd.org

Re: sstk(2) removal proposal

2017-12-18 Thread David Holland 
On Sat, Dec 16, 2017 at 06:40:04AM +0100, Kamil Rytarowski wrote:
 > I propose to remove the sstk syscall.
 > 
 > It has been added in day0 by  with the initial NetBSD commit and
 > never implemented. It has been purged from OpenBSD and is still around
 > in FreeBSD as never implemented and commented for removal (in capabilities).
 > 
 > It used to mean "change stack section size", and it's from the same
 > family of functions as sbrk(2) and brk(2).
 > 
 > It does not look like a candidate for being relevant again in the age of
 > UVM, mmap(2) and 32/64-bit address space.

That really is obsolete trash; please nuke it...

-- 
David A. Holland
dholl...@netbsd.org

Re: RFC: ipsec(4) pseudo interface

2017-12-18 Thread Joerg Sonnenberger 
On Mon, Dec 18, 2017 at 06:49:44PM +0900, Kengo NAKAHARA wrote:
> (a) Add if_ipsec.4
> (b) move current ipsec.4(for ipsec protocol) to ipsec.9, and then
> add ipsec.4(for ipsec pseudo interface)
> (c) any other

I'd call it either ifipsec(4) or ipsecif(4).

Joerg

Re: RFC: ipsec(4) pseudo interface

2017-12-18 Thread Christos Zoulas 
In article <02c36311-2fcd-08cf-cc71-b472e7c01...@iij.ad.jp>,
Kengo NAKAHARA   wrote:
>Hi,
>
>We implement ipsec(4) pseudo interface for route-based VPNs. This pseudo
>interface manages its security policy(SP) by itself, in particular, we do
># ifconfig ipsec0 tunnel 10.0.0.1 10.0.0.2
>the SPs "10.0.0.1 -> 10.0.0.2"(out) and "10.0.0.2 -> 10.0.0.1"(in) are
>generated automatically and atomically. And then, when we do
># ifconfig ipsec0 deletetunnel
>the SPs are destroyed automatically and atomically, too.
>
>Here is the patches and an unified patch.
>http://netbsd.org/~knakahara/if_ipsec/if_ipsec.tgz
>http://netbsd.org/~knakahara/if_ipsec/if_ipsec-unified.patch
>
>By the way, I have one question. In the above patch(s), I temporarily add
>manual for ipsecX pseudo interface as if_ipsec.4, because there is already
>ipsec.4 for general ipsec protocol. How should I add the man of ipsec(4)
>pseudo interface?
>(a) Add if_ipsec.4
>(b) move current ipsec.4(for ipsec protocol) to ipsec.9, and then
>add ipsec.4(for ipsec pseudo interface)
>(c) any other
>
>Could you comment the patch or the question?

I've wanted this feature for a long time! Looks ok to me, but the
sockaddr_copy()/port setting code, should be abstracted to a single
function since it is repeated in ioctl().

christos

Re: Merging ugen into the usb stack

2017-12-18 Thread Wolfgang Solfrank 

Hi Martin,


  - add a variation of uftdi that attaches on single interfaces (Wolfgang,
can you share your code, even if it does not work with -current?), and
either always use this variant, or use this variant on chips matched
by above mentioned quirks table.


See attached.

The only other change required is in files.usb, where I had to change the
"attach uftdi at usbdevif" to "attach uftdi at usbifif".  With these changes
I was able to  attach uftdi by specifying an interface.


  - make ugen be able to attach to single/specific interfaces as well (off
hand I'm not sure this would need code changes, but again, Wolfgang,
could you make your patches available?)


Sorry, looks like I lost any changes I made to ugen.c :-(

Ciao,
Wolfgang
--
wolfg...@solfrank.net   Wolfgang Solfrank
/*	$NetBSD: uftdi.c,v 1.60 2015/02/20 14:50:53 nonaka Exp $	*/

/*
 * Copyright (c) 2000 The NetBSD Foundation, Inc.
 * All rights reserved.
 *
 * This code is derived from software contributed to The NetBSD Foundation
 * by Lennart Augustsson (lenn...@augustsson.net).
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
 * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
 * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.
 */

#include 
__KERNEL_RCSID(0, "$NetBSD: uftdi.c,v 1.60 2015/02/20 14:50:53 nonaka Exp $");

#include 
#include 
#include 
#include 
#include 
#include 

#include 

#include 
#include 
#include 

#include 

#include 

#ifdef UFTDI_DEBUG
#define DPRINTF(x)	if (uftdidebug) printf x
#define DPRINTFN(n,x)	if (uftdidebug>(n)) printf x
int uftdidebug = 0;
#else
#define DPRINTF(x)
#define DPRINTFN(n,x)
#endif

#define UFTDI_CONFIG_NO		1

/*
 * These are the default number of bytes transferred per frame if the
 * endpoint doesn't tell us.  The output buffer size is a hard limit
 * for devices that use a 6-bit size encoding.
 */
#define UFTDIIBUFSIZE 64
#define UFTDIOBUFSIZE 64

/*
 * Magic constants!  Where do these come from?  They're what Linux uses...
 */
#define	UFTDI_MAX_IBUFSIZE	512
#define	UFTDI_MAX_OBUFSIZE	256

struct uftdi_softc {
	device_t		sc_dev;		/* base device */
	usbd_device_handle	sc_udev;	/* device */

	int			sc_iface_no;
	usbd_interface_handle	sc_iface;	/* interface */

	enum uftdi_type		sc_type;
	u_int			sc_hdrlen;
	u_int			sc_chiptype;

	u_char			sc_msr;
	u_char			sc_lsr;

	device_t		sc_subdev;

	u_char			sc_dying;

	u_int			last_lcr;

};

Static void	uftdi_get_status(void *, int portno, u_char *lsr, u_char *msr);
Static void	uftdi_set(void *, int, int, int);
Static int	uftdi_param(void *, int, struct termios *);
Static int	uftdi_open(void *sc, int portno);
Static void	uftdi_read(void *sc, int portno, u_char **ptr,u_int32_t *count);
Static void	uftdi_write(void *sc, int portno, u_char *to, u_char *from,
			u_int32_t *count);
Static void	uftdi_break(void *sc, int portno, int onoff);

struct ucom_methods uftdi_methods = {
	uftdi_get_status,
	uftdi_set,
	uftdi_param,
	NULL,
	uftdi_open,
	NULL,
	uftdi_read,
	uftdi_write,
};

/* 
 * The devices default to UFTDI_TYPE_8U232AM.
 * Remember to update uftdi_attach() if it should be UFTDI_TYPE_SIO instead
 */
static const struct usb_devno uftdi_devs[] = {
	{ USB_VENDOR_BBELECTRONICS, USB_PRODUCT_BBELECTRONICS_USOTL4 },
	{ USB_VENDOR_FALCOM, USB_PRODUCT_FALCOM_TWIST },
	{ USB_VENDOR_FALCOM, USB_PRODUCT_FALCOM_SAMBA },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_SERIAL_230X },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_SERIAL_232H },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_SERIAL_232RL },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_SERIAL_2232C },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_SERIAL_4232H },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_SERIAL_8U100AX },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_SERIAL_8U232AM },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_MHAM_KW },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_MHAM_YS },
	{

RFC: ipsec(4) pseudo interface

2017-12-18 Thread Kengo NAKAHARA 
Hi,

We implement ipsec(4) pseudo interface for route-based VPNs. This pseudo
interface manages its security policy(SP) by itself, in particular, we do
# ifconfig ipsec0 tunnel 10.0.0.1 10.0.0.2
the SPs "10.0.0.1 -> 10.0.0.2"(out) and "10.0.0.2 -> 10.0.0.1"(in) are
generated automatically and atomically. And then, when we do
# ifconfig ipsec0 deletetunnel
the SPs are destroyed automatically and atomically, too.

Here is the patches and an unified patch.
http://netbsd.org/~knakahara/if_ipsec/if_ipsec.tgz
http://netbsd.org/~knakahara/if_ipsec/if_ipsec-unified.patch

By the way, I have one question. In the above patch(s), I temporarily add
manual for ipsecX pseudo interface as if_ipsec.4, because there is already
ipsec.4 for general ipsec protocol. How should I add the man of ipsec(4)
pseudo interface?
(a) Add if_ipsec.4
(b) move current ipsec.4(for ipsec protocol) to ipsec.9, and then
add ipsec.4(for ipsec pseudo interface)
(c) any other

Could you comment the patch or the question?


Thanks,

-- 
//
Internet Initiative Japan Inc.

Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit

Kengo NAKAHARA