linux-kernel - Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

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: <1491242719.3704.33.camel@linux.intel.com>
Date:   Mon, 03 Apr 2017 19:05:19 +0100
From:   Alan Cox <alan@...ux.intel.com>
To:     Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Rob Herring <robh@...nel.org>,
        Peter Hurley <peter@...leysoftware.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for
 embedded systems

> evertheless very convenient to be able to use a standard
> shell 
> with it.

A standard shell will work over things other than a tty device. It
really doesn't care so long as it gets a stream of data punctuated by
end of statement symbols. It'll work over pipes, sockets, from files.

> I beg to disagree here.  First, before you call my code "totally 
> unmaintainable" I'd politely ask you to have a look at it first.

I said the combination makes it more unmaintainable. If you have two
tty layers one of them faking the API of the other at various interface
points then if the core tty layer wants to make a major change it no
longer can - because it'll break the other tty layer. In addition I
worry it won't be long before someone wants kgdb, gdbstubs and sysrq
over the cut down console and on it will go.

The uart layer is also known broken as an API - it is itself bloated
and over-locking (for example if it was being written today kfifo would
be used). What happens if we want to abolish it or encourage people to
move away from it (as we IMHO should be) ?

The serio code started with exactly the same problem, but now at least
talks tty layer. In your case you are tying it to something we
eventually ought to get rid of.

I also find the large scale need for it hard to believe. If you are
within 64K of running out of memory on your debug/devel device how are
you going to have space to fix security holes and do upgrades as they
occur in production (where presumably you don't need the tty driver) ?
The kernel doesn't exactly get smaller each release.

Alan