Re: 8250 serial console fixes -- issue

[Glen Turner <glen.turner@aarnet.edu.au>]

Russell King wrote:

> My point stands - if the user can provide an arbitary string to printk,
> they can fake any kernel message.  That in itself is a security bug.
> If there is an instance of that, then that's the real bug which would
> need fixing.
> 
> Once those bugs have been fixed, your claimed bug is also magically
> fixed.

Hi Russell,

Thanks for the explanation of where the kernel should handle
covert channels.

How about the other bugs reported by people who have used
the Remote-Serial-Console-HOWTO:

   - writing any text to an idle (DCD not asserted) modem still
     causes incoming calls to be hung up on.  That's not good
     as sysadmins can't connect to systems with failing hardware.

     [Note that modems really need the 'r' option, so it's
      fine to continue to write with DCD unasserted without
      the 'r' option.]

   - the huge boot times with the 'r' option and an idle/
     unconnected modem/terminal server.  This is caused by
     the CTS timing out per character even when CTS is
     floating (CTS is not defined unless DSR is asserted).
     This basically makes the 'r' option impossible to
     use on production systems.  Not using the 'r' option
     with a terminal server brings other problems (notably
     character loss problems when people paste a large
     number of characters into the SSH session through
     the terminal server to the remote host).

   - writing LF CR rather than CR LF unfortunately causes
     issues with some terminals.

I'm really only the messenger here.  I've collected bug reports
from readers of the HOWTO and written a patch to address their
experiences.  I'm sure people with much more familiarity with
the kernel can do it better.

Thanks,
Glen

-- 
  Glen Turner         Tel: (08) 8303 3936 or +61 8 8303 3936
  Australia's Academic & Research Network  www.aarnet.edu.au