netdev - Re: [PATCH 5/5] isdn: move capi drivers to staging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190429095856.jedh4ujwjkslpyp5@intra2net.com>
Date:   Mon, 29 Apr 2019 11:58:56 +0200
From:   Thomas Jarosch <thomas.jarosch@...ra2net.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Karsten Keil <isdn@...ux-pingi.de>,
        Networking <netdev@...r.kernel.org>,
        Tilman Schmidt <tilman@...p.cc>,
        Paul Bolle <pebolle@...cali.nl>,
        gigaset307x-common@...ts.sourceforge.net,
        isdn4linux@...tserv.isdn4linux.de,
        Al Viro <viro@...iv.linux.org.uk>,
        Holger Schurig <holgerschurig@...glemail.com>
Subject: Re: [PATCH 5/5] isdn: move capi drivers to staging

Hi Arnd,

You wrote on Thu, Apr 25, 2019 at 01:24:09PM +0200:
> > > Right, this is what I'm trying to find out here. I realize that there
> > > are (very few) remaining users of ISDN voice services, but this only
> > > matters if someone uses them
> > >
> > > 1. with a modern Linux kernel, and planning to upgrade beyond linux-5.3
> > > 2. with a device driver that ships with the kernel
> > > 3. using the CAPI subsystem
> > >
> > > I suspect that all three of the above are true in isolation, but onless
> > > at least one person needs all three combined, that doesn't stop us
> > > from staging them out.
> >
> > 1. + 3. applies to us. The mISDN drivers are based on the kernel ones,
> > but maintained in an extra git tree on top of the kernel. The situation
> > is not ideal but that's what it currently is. git repo:
> > https://github.com/ISDN4Linux/mISDN
> 
> I'm still confused by this: You say here that you use the CAPI
> subsystem from the mainline kernel (i.e. /dev/capi20 rather
> than mISDNcapid), but this does not appear to interact at all with
> mISDN, neither the in-kernel variant nor the one you link to.

my working theory was that a userspace capi application
talks to mISDNcapid via the kernel's CAPI layer as a proxy.

Karsten's original announcement mentioned
mISDN v2 CAPI support is userspace only:
https://isdn4linux.listserv.isdn4linux.narkive.com/bRkOUkZG/announcement-misdn-fax-capi-2-0-support


I did some preliminary research by removing the /dev/capi20 device node
and checked if "capiinfo" still works via strace -> it does.

# strace -e open,connect capiinfo
open("/usr/lib/libcapi20.so.3", O_RDONLY|O_CLOEXEC) = 3
open("/dev/shm/sem.CAPI20_shared_sem.v01000010", O_RDWR|O_NOFOLLOW) = 3
open("/dev/shm/CAPI20_shared_memory.v01000010", O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0666) = 3
open("/usr/lib/capi/lib_capi_mod_misdn.so.2", O_RDONLY|O_CLOEXEC) = 5
open("/usr/lib/capi/lib_capi_mod_std.so.2", O_RDONLY|O_CLOEXEC) = 5
open("/root/.capi20rc", O_RDONLY)       = -1 ENOENT (No such file or directory)
open("/etc/capi20.conf", O_RDONLY)      = 4
open("/dev/capi20", O_RDWR)             = -1 ENOENT (No such file or directory)
open("/dev/isdn/capi20", O_RDWR)        = -1 ENOENT (No such file or directory)
connect(4, {sa_family=AF_UNIX, sun_path="/var/run/mISDNcapid/sock"}, 110) = 0
Number of Controllers : 1
connect(5, {sa_family=AF_UNIX, sun_path="/var/run/mISDNcapid/sock"}, 110) = 0
Controller 1:
Manufacturer: mISDN
CAPI Version: 2.0
Manufacturer Version: 0.1
Serial Number: 0000001
..

The trick is the lib_capi_mod_misdn.so library.
It's a plugin for the CAPI tools to directly talk to mISDNcapid.

I will do more thorough research next week if the CAPI userspace stuff runs with 
 the kernel CAPI layer disabled. It could be that the userspace tools like 
"capiinit" check for the presence of the kernel CAPI interface but don't really 
need it. We'll find out.

Intra2net officially supports AVM b1 and c4 cards for fax but we didn't
encounter these cards for years in customer support and I'm also 
willing to officially cancel support for those.

-> it's good to move the drivers to staging.

Best regards,
Thomas