linux-kernel - Re: tty TTY

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: <4F04A187.2050705@compro.net>
Date:	Wed, 04 Jan 2012 13:59:19 -0500
From:	Mark Hounschell <markh@...pro.net>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Linux-kernel <linux-kernel@...r.kernel.org>,
	Mark Hounschell <dmarkh@....rr.com>
Subject: Re: tty  TTY_HUPPED anomaly

On 01/04/2012 11:27 AM, Alan Cox wrote:
>> But what has carrier dropping got to do with an TIOCSETD ioctl. For that
>
> When the carrier is dropped and HUPCL is set then the tty is disconnected
> from the physical interface. It's specified behaviour and required for
> security. So by the time you go to issue the TIOCSETD you are no longer
> connected to the tty. That may well just be a timing change.
>
>> What can be done to prevent tty_hangup from being called after opening
>> the port? And if this is really supposed to happen, why does it not
>> always happen?
>
> It should only happen if the carrier is dropped.
>
>> Even if the first thing I do after opening the port is to clear HUPCL
>> and set CLOCAL, this still randomly happens the first time I open the
>> port after booting.
>
> I'd expect the behaviour to either be
>
> carrier high, stays high - open works, no hangup events seen
>
> or
>
> carrier low, stays low - open blocks, but open with O_NDELAY works,
> hangup events not seen.
>
> It's the act of the drop which is a hangup not the presence of low
> carrier if I remember the spec properly. The Synclink GT correctly does
> this as far as I can tell (I have no hardware or docs for it) but the
> code indicates that the hardware reports changes and it acts on them
> properly (checking CLOCAL etc).
>
>
> I would guess (given the distro change is the trigger) that you've got a
> SuSE problem not a kernel one. The kernel behaviour and code looks
> correct. My guess therefore is that newer SuSE is running stuff in the
> boot which is probing serial ports and messing with the carrier wrongly
> and in ways it didn't use to. That would fit the fact that something
> similarly broken has apparently also appeared in the Fedora user space
> bootup.
>

Yes,  I never really though it was a kernel problem. All though I can't 
say I agree with the HUPCL/security thing. In any case, with the 
Synclink cards, at first open after boot of SuSE-12.1, CLOCAL is not 
set. Whereas all pre SuSE-12.1 releases do have CLOCAL set.


Mark

--
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/