Re: Merging ugen into the usb stack
Hi, It doesn't solve the generic (no pun intended) problem of raw ugen access to arbitrary other devices, e.g. for use by USB over IP http://usbip.sourceforge.net/ Of course, a better approach may be to add detach kernel driver functionality: http://libusb.sourceforge.net/api-1.0/group__dev.html#ga21bd343325f558987ca57e4e281a6d47 While this may be a good idea in general, for this particular use case it will not work as expected (at lease expected by me): By detaching the (original) uftdi driver from the device, you would not only have to drive the jtag channel from userland, but the serial line on the second channel, too. Ciao, Wolfgang -- wolfg...@solfrank.net Wolfgang Solfrank
Re: Merging ugen into the usb stack
Hi Martin, Martin Husemann schrieb: On Thu, Feb 08, 2018 at 07:15:55PM +0100, Martin Husemann wrote: Seems to work for me as well: root file system type: ffs kern.module.path=/stand/i386/8.99.12/modules ugen0 at uhub0 port 1 configuration 1 interface 0 ugen0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, addr 2 uftdi0 at uhub0 port 1 configuration 1 interface 1 uftdi0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, addr 2 ucom1 at uftdi0 portno 2 Hmm, not quite, i can't use ttyU1 (or the other uftdi ones), while the uplcom based ttyU0 and ttyU2 work. What exactly do you mean with "can't use ttyU1"? Did you try to use it with nothing else going on? Or are you trying to access ttyU1 while using openocd at the same time? Does it crash? Hang? Unfortunately I'm currently unable to test this. While I still have the debug board available, the device to be debugged by this doesn't work any longer. And since the seial line is brought out of the debug board on the same ffc as the jtag connection, I don't have easy access to it. Ciao, Wolfgang -- wolfg...@solfrank.net Wolfgang Solfrank
Re: Merging ugen into the usb stack
Hi,
with the attached diffs I'm able to attach my debug board like this:
ugen0 at uhub5 port 1 configuration 1 interface 0
ugen0: OpenMoko (0x1457) Debug Board for Neo1973 (0x5118), rev 2.00/5.00, addr 3
uftdi0 at uhub5 port 1 configuration 1 interface 1
uftdi0: OpenMoko (0x1457) Debug Board for Neo1973 (0x5118), rev 2.00/5.00, addr
3
ucom0 at uftdi0 portno 2
(Actually, not, as the codes for my debug board are missing in usbdevs.)
Note that you have to be careful when using this ugen. There
is no restriction to interface 0, you can change configuration
and interfere with the ucom driver attached to interface 1.
The only configuration line needed for this (apart from including
usbdevices.config) is something like
ugen* at uhub? interface 0 flags 1
or, if you want to restrict this to some specific board:
ugen* at uhub? vendor 0x1457 product 0x5118 interface 0 flags 1
No need for the previously mentioned "no uftdi*", as the ugen
(due to the "flags 1") will attach with a higher priority.
Ciao,
Wolfgang
--
wolfg...@solfrank.net Wolfgang Solfrank
Index: files.usb
===
RCS file: /cvsroot/src/sys/dev/usb/files.usb,v
retrieving revision 1.148
diff -u -r1.148 files.usb
--- files.usb 10 Dec 2017 17:03:07 - 1.148
+++ files.usb 8 Feb 2018 16:15:11 -
@@ -138,6 +138,7 @@
# Generic devices
device ugen
attach ugen at usbdevif
+attach ugen at usbifif with ugenif
file dev/usb/ugen.c ugenneeds-flag
@@ -387,7 +388,7 @@
# FTDI serial driver
device uftdi: ucombus
-attach uftdi at usbdevif
+attach uftdi at usbifif
file dev/usb/uftdi.c uftdi
# Prolific PL2303 serial driver
Index: uftdi.c
===
RCS file: /cvsroot/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.66
diff -u -r1.66 uftdi.c
--- uftdi.c 22 Dec 2017 14:18:29 - 1.66
+++ uftdi.c 8 Feb 2018 16:15:11 -
@@ -62,9 +62,7 @@
#define DPRINTFN(n,x)
#endif
-#define UFTDI_CONFIG_INDEX 0
-#define UFTDI_IFACE_INDEX 0
-#define UFTDI_MAX_PORTS4
+#define UFTDI_CONFIG_NO1
/*
* These are the default number of bytes transferred per frame if the
@@ -83,17 +81,17 @@
struct uftdi_softc {
device_tsc_dev; /* base device */
struct usbd_device *sc_udev;/* device */
- struct usbd_interface * sc_iface[UFTDI_MAX_PORTS]; /* interface */
+ struct usbd_interface * sc_iface; /* interface */
+ int sc_iface_no;
enum uftdi_type sc_type;
u_int sc_hdrlen;
- u_int sc_numports;
u_int sc_chiptype;
u_char sc_msr;
u_char sc_lsr;
- device_tsc_subdev[UFTDI_MAX_PORTS];
+ device_tsc_subdev;
u_char sc_dying;
@@ -190,29 +188,30 @@
int
uftdi_match(device_t parent, cfdata_t match, void *aux)
{
- struct usb_attach_arg *uaa = aux;
+ struct usbif_attach_arg *uiaa = aux;
DPRINTFN(20,("uftdi: vendor=0x%x, product=0x%x\n",
-uaa->uaa_vendor, uaa->uaa_product));
+uiaa->uiaa_vendor, uiaa->uiaa_product));
- return uftdi_lookup(uaa->uaa_vendor, uaa->uaa_product) != NULL ?
- UMATCH_VENDOR_PRODUCT : UMATCH_NONE;
+ if (uiaa->uiaa_configno != UFTDI_CONFIG_NO)
+ return UMATCH_NONE;
+
+ return uftdi_lookup(uiaa->uiaa_vendor, uiaa->uiaa_product) != NULL ?
+ UMATCH_VENDOR_PRODUCT_CONF_IFACE : UMATCH_NONE;
}
void
uftdi_attach(device_t parent, device_t self, void *aux)
{
struct uftdi_softc *sc = device_private(self);
- struct usb_attach_arg *uaa = aux;
- struct usbd_device *dev = uaa->uaa_device;
- struct usbd_interface *iface;
+ struct usbif_attach_arg *uiaa = aux;
+ struct usbd_device *dev = uiaa->uiaa_device;
+ struct usbd_interface *iface = uiaa->uiaa_iface;
usb_device_descriptor_t *ddesc;
usb_interface_descriptor_t *id;
usb_endpoint_descriptor_t *ed;
char *devinfop;
- const char *devname = device_xname(self);
- int i,idx;
- usbd_status err;
+ int i;
struct ucom_attach_args ucaa;
DPRINTFN(10,("\nuftdi_attach: sc=%p\n", sc));
@@ -224,122 +223,86 @@
aprint_normal_dev(self, "%s\n", devinfop);
usbd_devinfo_free(devinfop);
- /* Move the device into the configured state. */
- err = usbd_set_config_index(dev, UFTDI_CONFIG_INDEX, 1);
- if (err) {
- aprint_error("\n%s: failed to set configurat
Re: Merging ugen into the usb stack
Hi again,
- 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.
Attached is a version of uftdi.c that works again with current (as of 1/29).
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.
Without any other change to kernel config files, uftdi will attach separately
to any uftdi interface found. I.e., with my board I get two instances of uftdi.
If you want uftdi only on the second port, you need, after including
usbdevices.config, something like:
no uftdi*
uftdi* at uhub? interface 1
While it is possible to restrict this to a specific device (with the vendor
and product attributes), it is not possible to have a generic uftdi
attachment in parallel to the above, as then the generic attachment
will match interface 0 on the device in question, too.
- 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 :-(
I will try to reconstruct this, too.
Ciao,
Wolfgang
--
wolfg...@solfrank.net Wolfgang Solfrank
/* $NetBSD: uftdi.c,v 1.66 2017/12/22 14:18:29 jakllsch 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.66 2017/12/22 14:18:29 jakllsch Exp $");
#ifdef _KERNEL_OPT
#include "opt_usb.h"
#endif
#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 */
struct usbd_device * sc_udev; /* device */
struct usbd_interface * sc_iface; /* interface */
int sc_iface_no;
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, u_char *, u_char *);
Static void uftdi_set(void *, int, int, int);
Static int uftdi_param(void *, int, struct termios *);
Static int uftdi_open(void *, int);
Static void uftdi_read(void *, int, u_char **, uint32_t *);
Static void uftdi_write(void *, int, u_char *, u_char *,
uint32_t *);
Static void uftdi_break(void *, int, int);
struct ucom_methods uftdi_methods = {
.ucom_get_status = uftdi_get_status,
.ucom_set = uftdi_set,
.ucom_param = uftdi_param,
.ucom_ioctl = NULL,
.ucom_open = uftdi_open,
.ucom_close = NULL,
.ucom_read = uftdi_read,
.ucom_write =
Re: Merging ugen into the usb stack
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_VEND
Re: Merging ugen into the usb stack
Hi Martin, I have a Guruplug JTAG device (and right now need to use it to unbrick one of my Guruplugs after some ... stupid u-boot experiment). I've got some similar device which also uses a 2 port uftdi, where one port is wired as a serial interface and the other is used for jtag. In order to support that, I changed the uftdi driver to match against an interface instead of the whole device. Thus you could specify uftdi1 at uhub? port ? configuration ? interface 1 ucom* at uftdi1 and leave interface 0 of uftdi alone, which then resulted in ugen to attach there. Unfortunately, this modification has bit rotted since then and doesn't work in its current state. I could hack uftdi to allow attaching a ugen child, but that sounds like a very special hack. Jared suggested to instead make ugen not a separate device, but globaly fold it into the usb stack. That would also solve similar issues we have seen with usb scanner devices and ulpts. So, how should we proceed here? However, I support the idea of allowing ugen to attach to some usb device independent of some other driver matching it. Of course, there needs to be some mutual exclusion between ugen and the other driver. Ciao, Wolfgang -- wolfg...@solfrank.net Wolfgang Solfrank
Re: History of disklables
Hi Edgar, 4.3 did not have on-disk disklabels. Really? My first encounter with BSD was ~1983 on a VAX 11/750 which switched between VMS and 4.2BSD (or 4.3, definitely not 4.4) every other day and I think it had two disc packs with different partition layouts. I also remember ws@ (who was the guy to introduce me to Unix) telling me that disklables were DEC’s native partitioning scheme. Wolfgang, liege ich total daneben? You must be misremembering something. As I didn't have access to any pre-4.4 BSD back then (only shortly to PWB and then to V7), I had no idea about "DEC's native partitioning scheme". Looking at the 4.3BSD sources (at http://minnie.tuhs.org/cgi-bin/utree.pl) seems to indicate that the partition tables were indeed compiled into the kernel (as they were with V7). However, by default the partition tables had some overlapping partitions, so you could access your packs with different layouts. Ciao, Wolfgang -- wolfg...@solfrank.net Wolfgang Solfrank
Re: UVM and the NULL page
Hi, Any cpu that doesn't require special instructions for copyin/out is susceptible to user processes mapping code to address 0 and converting a kernel 'jump through unset pointer' from a panic into a massive security hole (executing process code with the 'supervisor' bit set). Only if you do a naive implementation of copyin/out. Nothing prevents you from implementing copyin/out on these cpus by mapping only the relevant part of the user address space at some reserved address (maybe even one page at a time), do the copying and then unmap the user space part. No reason to share the user address space all the time. Ciao, Wolfgang -- wolfg...@solfrank.net Wolfgang Solfrank
Re: UVM and the NULL page
Hi all,
Paul Goyette schrieb:
On Fri, 29 Jul 2016, Joerg Sonnenberger wrote:
On Fri, Jul 29, 2016 at 10:08:48AM +0200, Maxime Villard wrote:
It is not possible to keep a sysctl, since VM_MIN_ADDRESS is a constant
used in assembly, so it won't be turned to a variable.
So find a different solution to fix the bugs.
Now, it is a little hard to know how many emulators or whatever rely on
null to be available. But many (most?) systems don't allow null nowadays,
and null dereferences are a well-known issue. It is more or less becoming
a standard. If a software fails on NetBSD because of a null mmap, then it
is likely to fail on many other systems.
Just because many newer ("hardened") systems break compatibility with
existing programs doesn't justify the same to be done to NetBSD.
I will commit [3] soon.
I strongly object that.
I also object.
Actually, if this nonsense is committed, I will stop contributing
to NetBSD!
Ciao,
Wolfgang
--
wolfg...@solfrank.net Wolfgang Solfrank
Re: UVM and the NULL page
Hi, Currently, there is no real way to make sure a userland process won't be able to allocate the NULL page. Why should this be restricted? Ciao, Wolfgang -- wolfg...@solfrank.net Wolfgang Solfrank
Re: In-kernel process exit hooks?
Hi, We all agree that filemon(4) is an ugly hack. It probably should never have gotten committed. But it is there now, and there are a (very) few use-cases. So we don't want to remove it without having a replacement implementation. Well, can you explain? Why would we not want to remove it and be done with that nonsense? Ciao, Wolfgang -- wolfg...@solfrank.net Wolfgang Solfrank
Re: How to go on with ISO 9660 large file support ?
Hi Thomas, unfortunately, I'm a bit scarce on round tuits right now, so here only some random comments: - cd9660_readdir() serving as VOP_READDIR(9) The case of mount -o norrip,nogens already used a delivery function with delayed file candidates: cd9660_vnops.c : iso_shipdir(). Originally it only had the task to find the youngest version of a ISO 9660 data file. Now it also counts the follow-up directory records of the same file and skips over them. Don't forget that in case of -o norrip, iso_shipdir is also complicated by associated files - cd9660_lookup() as VOP_LOOKUP(9) mount -o norrip returned the last record of matching name, whereas -o rrip returned the first matching record. RRIP doesn't have the concept of multiple versions of a file. There is also an ISO image emerging which (by hex editor) exposes exotic or even illegal situations. 6.1.3 and the host operating system show interesting effects when mounting it. What 6.1.3 do you refer to here? Certainly not to the entry in ECMA-119 labelled Volume Space? - I could not yet find ISO images or software which would provide test opportunities for ISO 9660 Associated Files or Extented Attributes (which are not related to getextattr(1)/extattr(9)). Regarding associated files, I saw those used by Apple for their resource fork. Albeit I haven't seen any ISOs with them recently. Ciao, Wolfgang -- wolfg...@solfrank.net Wolfgang Solfrank
Re: suprious reboot on netbsd-6:i386 with PAE
Hi Emanuel,
sorry for not being helpful with the other problems, but
Unfortunately using a -current kernel is not an option just right now,
because of kernel bugs. For a reason I have not yet tracked down, dovecot
is broken (IPC between (pop|imap)-login and auth process is screwed), and
sshd randomly cuts connexions because of an invalid HMAC. If the two problems
rings a bell for someone, I am interested.
In case you are using dovecot2, try the attached patch.
The problem is a change in the semantics of local domain
socket addresses. Previously, they had a fixed size, and the
path name contained within the address was therefor normally
'\0'-terminated. Now the address is the common socket address
part plus the pathname, where the terminating '\0' is _not_
part of the address. When the kernel copies out some local
domain part, the user has to supply the terminator, if it wants
to use the path as some ordinary string, e.g. in strlen.
I haven't made up my mind on how to really fix this, but I
tend to include the terminating '\0' within the address.
Note that there are even programs within our own
distribution which trigger core dumps due to this change
(at least kdump does).
Ciao,
Wolfgang
--
wolfg...@solfrank.net Wolfgang Solfrank
--- src/lib/net.c.orig 2013-11-24 16:45:57.0 +0100
+++ src/lib/net.c 2013-11-24 16:53:55.0 +0100
@@ -28,7 +28,10 @@
union sockaddr_union_unix {
struct sockaddr sa;
- struct sockaddr_un un;
+ struct {
+ struct sockaddr_un un;
+ char terminator;
+ } _un;
};
#ifdef HAVE_IPV6
@@ -280,8 +283,8 @@
int fd, ret;
memset(sa, 0, sizeof(sa));
- sa.un.sun_family = AF_UNIX;
- if (i_strocpy(sa.un.sun_path, path, sizeof(sa.un.sun_path)) 0) {
+ sa._un.un.sun_family = AF_UNIX;
+ if (i_strocpy(sa._un.un.sun_path, path, sizeof(sa._un.un.sun_path))
0) {
/* too long path */
#ifdef ENAMETOOLONG
errno = ENAMETOOLONG;
@@ -744,13 +747,14 @@
union sockaddr_union_unix so;
socklen_t addrlen = sizeof(so);
+ memset(so, 0, sizeof so);
if (getsockname(fd, so.sa, addrlen) 0)
return -1;
- if (so.un.sun_family != AF_UNIX) {
+ if (so._un.un.sun_family != AF_UNIX) {
errno = ENOTSOCK;
return -1;
}
- *name_r = t_strdup(so.un.sun_path);
+ *name_r = t_strdup(so._un.un.sun_path);
return 0;
}
smime.p7s
Description: S/MIME Cryptographic Signature
Re: suprious reboot on netbsd-6:i386 with PAE
Hi, Attached is a patch that seems to solve the problem at mine. Dovecot works again and kdump does not dumps core anymore. Your patch doesn't look right, and is probably incomplete, too. For one thing, you append the trailing '\0' one byte beyond the end of the the now extended mbuf. In addition, there are other places where the additional byte needs to be accounted for, e.g. in makeun() within this file. Not sure whether there are others. I am not sure I did the (nam-m_len MLEN !ext) case correctly, though. I'd do the '\0'-terminating right after the memcpy. And we now report the path length including the trailing zero, I do not know if it is right or nor. That's the whole purpose of this, isn't it? If you don't include it in the mbuf length, it will not be copied out to the user. Ciao, Wolfgang -- wolfg...@solfrank.net Wolfgang Solfrank smime.p7s Description: S/MIME Cryptographic Signature
Re: suprious reboot on netbsd-6:i386 with PAE
Hi,
In addition, there are other places where the additional byte
needs to be accounted for, e.g. in makeun() within this file.
Not sure whether there are others.
There is already a +1 in makeun.
*addrlen = nam-m_len + 1;
Yes, that's what I was trying to hint at. Here the m_len
does include the terminating '\0' byte, so it should be
something like (untested):
static struct sockaddr_un *
makeun(struct mbuf *nam, size_t *addrlen) {
*addrlen = nam-m_len;
sun = malloc(*addrlen, M_SONAME, M_WAITOK);
m_copydata(nam, 0, nam-m_len, (void *)sun);
sun-sun_len = strlen(sun-sun_path) +
offsetof(struct sockaddr_un, sun_path);
return sun;
}
Ciao,
Wolfgang
--
wolfg...@solfrank.net Wolfgang Solfrank
smime.p7s
Description: S/MIME Cryptographic Signature
Re: suprious reboot on netbsd-6:i386 with PAE
Hi, That's an argument for doing this for COMPAT_* code. It's not an argument for doing it for non-compat programs. Indeed, I think it's actually better to break code depending on such incorrect assumptions, beacuse it makes it easier to find (and then fix) them. While in principle I agree with Mouse, in this particular case I'm not that sure. To the best of my knowledge, it was long unspecified whether the terminating '\0' was part of the address or not. In fact, historical behavior had a fixed size structure for local domain socket addresses with 104 bytes for the path name. AFAICS if a user program provided space for this and was somehow sure to use names shorter than this, the returned sockaddr_un would include the '\0' beyond the end of the path name. So while those programs are indeed incorrect with respect to the definition in our current manual page, they are more or less correct with respect to historical behavior. Ciao, Wolfgang -- wolfg...@solfrank.net Wolfgang Solfrank smime.p7s Description: S/MIME Cryptographic Signature
Re: Rewriting kernfs and procfs - GSoC'12
Hi, I was initially reticent to reply to this thread at this time, because some details might be out of the scope of the GSoC project. But I think that those questions are important to consider in the design of a new procfs implementation, and the project description was very summary, so I decided to post them anyway: Given that even Linux walks away from placing non-process related data into in /proc, slowly putting it into /sys instead, IMHO this is going in the wrong direction. I once thought that it might be useful to export procfs via NFS, but our current implementation doesn't support it. Is this something that a new implementation should allow? While I once tried that (quite long ago), it turned out that the buffering the NFS client does somewhat conflicts the dynamic nature of /proc and /kern. However, maybe it could work better with NFSv3 or even NFSv4? Ciao, Wolfgang -- wolfg...@solfrank.net Wolfgang Solfrank
Re: reading /dev/mem panics a domU
Hi, I just discovered the oddity below, on a netbsd-5 domU. Is there a reason for not calling that a bug? Does it happens only at mine? # strings /dev/mem /dev/null xpq_flush_queue: 1 entries 0xa8b5e948: 0x0221 panic: HYPERVISOR_mmu_update failed No, this is not a bug, especially not, if this is run by root. /dev/mem is by definition the possibility to access the physical address space of the machine. That is, apart from allowing access to the physical memory, it also allows access to memory mapped I/O etc. Reading sequentially through this may or may not stumble upon one of these addresses before getting some error result (depending on the machine in question and the access rights). Access to /dev/mem requires specially crafted tools that know what they are doing. Regarding the mentioning of root in my first sentence, what I meant was that in (most of) our ports, there is code in the kernel that (depending on the secmodel in place) allows non-root users access only to real memory and returns an error otherwise (which happens to be wrong anyway, as it returns KAUTH_RESULT_* values as errno values, as I just found out when looking into this). From a security POV, access to /dev/mem should be restricted to root anyway (ok, based on the secmodel in place. However, the current restriction of non-root access to memory only doesn't make too much sense; maybe a relict from some early frame buffer access?) Ciao, Wolfgang -- wolfg...@solfrank.net Wolfgang Solfrank
