linux-kernel - Re: tty contention resulting from tty_open_by

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:   Sat, 8 Jul 2017 10:01:13 +0100
From:   Okash Khawaja <okash.khawaja@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Jiri Slaby <jslaby@...e.com>,
        Samuel Thibault <samuel.thibault@...-lyon.org>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org,
        Kirk Reiser <kirk@...sers.ca>,
        Chris Brannon <chris@...-brannons.com>,
        speakup@...ux-speakup.org
Subject: Re: tty contention resulting from tty_open_by_device export

On Sat, Jul 08, 2017 at 10:38:03AM +0200, Greg Kroah-Hartman wrote:

> > +
> > +        if (tty) {
> > +                tty_kref_put(tty);  /* drop kref from tty_driver_lookup_tty() */
> 
> Put the comment above the line?
> 
Sure

> > +                tty = ERR_PTR(-EBUSY);
> > +        } else { /* Returns with the tty_lock held for now */
> 
> I don't understand this comment.
> 
This is same comment in tty_open_by_driver. Basically, tty_init_dev
returns tty locked so that it doesn't dissapear from underneath the
caller. I am not sure about the "for now" part of the comment. I'll
remove it.

> > +                tty = tty_init_dev(driver, index);
> > +                set_bit(TTY_KOPENED, &tty->flags);
> > +        }
> > +out:
> > +        mutex_unlock(&tty_mutex);
> > +        tty_driver_kref_put(driver);
> > +        return tty;
> > +}
> > +EXPORT_SYMBOL(tty_kopen);
> 
> EXPORT_SYMBOL_GPL()?  :)
> 
Of course, will update
> >  /**
> >   *	tty_open		-	open a tty device
> > --- a/include/linux/tty.h
> > +++ b/include/linux/tty.h
> > @@ -362,6 +362,7 @@ struct tty_file_private {
> >  #define TTY_NO_WRITE_SPLIT 	17	/* Preserve write boundaries to driver */
> >  #define TTY_HUPPED 		18	/* Post driver->hangup() */
> >  #define TTY_LDISC_HALTED	22	/* Line discipline is halted */
> > +#define TTY_KOPENED             23      /* TTY exclusively opened by kernel */
> 
> Minor nit, please use tabs here.
> 
Will do

> Overall, the idea looks sane to me.  Keeping userspace from opening a
> tty that the kernel has opened internally makes sense, hopefully
> userspace doesn't get too confused when that happens.  I don't think we
> normally return -EBUSY from an open call, have you seen what happens
> with apps when you do this (like minicom?)
> 
Yes, returning -EBUSY is a change in the interface. I will test against
applications like minicom before resubmitting this.

Thanks,
Okash