linux-kernel - Re: line BRK detection on ttyS0

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] [day] [month] [year] [list]

Message-ID: <20100923222326.543f3365@lxorguk.ukuu.org.uk>
Date:	Thu, 23 Sep 2010 22:23:26 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	markh@...pro.net
Cc:	linux-kernel@...r.kernel.org
Subject: Re: line BRK detection on ttyS0

On Thu, 23 Sep 2010 16:48:14 -0400
Mark Hounschell <markh@...pro.net> wrote:

> On 09/22/2010 08:03 PM, Alan Cox wrote:
> > On Wed, 22 Sep 2010 15:36:48 -0400
> > Mark Hounschell <markh@...pro.net> wrote:
> > 
> >> Does the kernel support sending a SIGINT from a line BRK on ttyS0 to a thread of a process
> >> where the process has a controlling terminal that is NOT ttyS0 and the thread is using ttyS0
> >> in a cfmakeraw mode? I see doc that implies that ttyS0 must be the controlling terminal but
> >> can my thread have a controlling terminal while my main process has it's own ?
> > 
> > If they have two different ttys open then yes at least as far as Linux is
> > concerned. I don't know how glibc handles it as it can do signal groups
> > and the like and delivery of signals to process not threads etc.
> > 
> > You can see parity anyway. In PARMRK mode you get \377 \0 [whatever] for
> > parity/break etc but \377 is also doubled for a real one - ie \377 \377
> > 
> 
> \377 \0  or  [whatever] just looks like valid data to my thread though.

If you have PARMRK mode set then you need to parse the data stream. If
you see \377 \0 then you know it is control information because any \377
received from the other device will be passed to you as \377\377

> So you're saying it's gonna be a glibc thing and not a kernel thing that
> prevents my thread from getting a signal?

I'm saying you need to ask glibc people - I'm not sure exactly how they
set up the posix signals for threads, and posix thread signalling is
fairly demented.

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