linux-kernel - Re: [PATCH 4/6] drivers:misc: sources for Init manager module

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]

Date:	Wed, 24 Mar 2010 22:35:23 +0530 (IST)
From:	Pavan Savoy <pavan_savoy@...oo.co.in>
To:	Greg KH <gregkh@...e.de>
Cc:	Marcel Holtmann <marcel@...tmann.org>,
	PavanSavoy <pavan_savoy@...com>,
	"alan@...rguk.ukuu.org.uk" <alan@...rguk.ukuu.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module

--- On Wed, 24/3/10, Greg KH <gregkh@...e.de> wrote:

> From: Greg KH <gregkh@...e.de>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan_savoy@...oo.co.in>
> Cc: "Marcel Holtmann" <marcel@...tmann.org>, "PavanSavoy" <pavan_savoy@...com>, "alan@...rguk.ukuu.org.uk" <alan@...rguk.ukuu.org.uk>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
> Date: Wednesday, 24 March, 2010, 10:22 PM
> On Wed, Mar 24, 2010 at 10:05:19PM
> +0530, Pavan Savoy wrote:
> > --- On Wed, 24/3/10, Greg KH <gregkh@...e.de>
> wrote:
> > 
> > > From: Greg KH <gregkh@...e.de>
> > > Subject: Re: [PATCH 4/6] drivers:misc: sources
> for Init manager module
> > > To: "Marcel Holtmann" <marcel@...tmann.org>
> > > Cc: "Pavan Savoy" <pavan_savoy@...oo.co.in>,
> "PavanSavoy" <pavan_savoy@...com>,
> "alan@...rguk.ukuu.org.uk"
> <alan@...rguk.ukuu.org.uk>,
> "linux-kernel@...r.kernel.org"
> <linux-kernel@...r.kernel.org>
> > > Date: Wednesday, 24 March, 2010, 9:56 PM
> > > On Wed, Mar 24, 2010 at 09:11:45AM
> > > -0700, Marcel Holtmann wrote:
> > > > > I wanted to somehow put this in staging
> because
> > > then it would probably have a thorough
> architectural review
> > > process.
> > > > > Some details about this driver - 
> > > > > 
> > > > > 1. This driver will be used by
> > > Bluetooth-BlueZ/FM-V4L2 and GPS (probably
> character device
> > > driver) using the EXPORTED symbols
> (-register/_unregister).
> > > > > 
> > > > > 2. Much like the hciattach daemon which
> maintains
> > > N_HCI bluetooth line discipline, this driver will
> also have
> > > a User-Space? N_TI_WL Init manager (UIM)
> maintaining
> > > the Line discipline.
> > > > 
> > > > can you explain why you think this is needed
> and we
> > > can not interface
> > > > this directly. If it is a serial port, what
> protocol
> > > does it talk?
> > > > 
> > > > > 3. Because of the UIM should know when
> to
> > > install/uninstall line discipline, the /sys entry
> is created
> > > a root called UIM (a new kobject) and UIM daemon
> would write
> > > it's PID to it.
> > > > 
> > > > I don't understand this. This sounds like a
> broken
> > > concept to me.
> > > 
> > > I also agree, those sysfs files are not
> acceptable, and
> > > will not work
> > > as-designed due to the pid namespace issues :(
> > 
> > Ok, How do I then from kernel space, ask a user-space
> daemon to open the TTY port and do a tiocsetd on it ? 
> > [i.e ask for a line discipline to be installed ?]
> 
> What would cause the kernel to want to tell userspace to do
> this?  Is it
> an external event that happens somehow that userspace
> should know to
> look for?

Yes, Userspace events like opening the /dev/radio0 device for FM, or hci0 interface for BT.
However the apps/stack would not want to know what LDISC is being used underneath, well they might not even want to know whether it's TTY or USB/i2C - right ?

> > Can't open the TTY and TIOCSETD upon boot, because BT,
> FM and GPS
> > might be used or not used anytime.
> 
> What causes them to want to be used?  The user,
> right?
> 
> > And the idea of creating a device node, specifically
> for this and then
> > doing an fasync/SIGIO was somehow rubbished.
> 
> Why?

It does pretty much the same thing, But we would be stuffing in more interfaces to the already huge driver.
I mean just 3 fops on the device ? open/ioctl-fasync/close - but it also uses the SIGnaling concept - but not via PID though.

Alan's talking about opening up the LDISC installation to kernel (say EXPORTING tty_set_ldisc/tiocsetd), That's like ideal scenario in this case.

> 
> thanks,
> 
> greg k-h
> 


      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/