linux-kernel - Re: [PATCH v2 0/4] have the vt console preserve unicode characters

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: <20180625003303.fqq6kr2dg4lffcve@angband.pl>
Date:   Mon, 25 Jun 2018 02:33:03 +0200
From:   Adam Borowski <kilobyte@...band.pl>
To:     Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Dave Mielke <Dave@...lke.cc>,
        Samuel Thibault <samuel.thibault@...-lyon.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/4] have the vt console preserve unicode characters

On Wed, Jun 20, 2018 at 10:59:08PM -0400, Nicolas Pitre wrote:
> On Thu, 21 Jun 2018, Adam Borowski wrote:
> 
> > On Tue, Jun 19, 2018 at 11:34:34AM -0400, Nicolas Pitre wrote:
> > > On Tue, 19 Jun 2018, Adam Borowski wrote:
> > > > Thus, it'd be nice to use the structure you add to implement full Unicode
> > > > range for the vast majority of people.  This includes even U+2800..FF.  :)

> > > If the core console code makes the switch to full unicode then yes, that 
> > > would be the way to go to maintain backward compatibility. However 
> > > vgacon users would see a performance drop when switching between VT's 
> > > and we used to brag about how fast the Linux console used to be 20 years 
> > > ago. Does it still matter today?
> 
> > * VT switch
> > * scrollback
> > 
> > The last two cases are initiated by the user, and within human reaction time
> > you need to convert usually 2000 -- up to 20k-ish -- characters.  The
> > conversion is done by a 3-level array.  I think a ZX Spectrum can handle
> > this fine without a visible slowdown.
> 
> In the scrollback case, currently each driver is doing its own thing. 
> The vgacon driver is probably the most efficient as it only moves the 
> base memory register around without copying anything at all. And that 
> part doesn't have to change.

As long as the data is still in video memory, yeah.  Soft scrollback is not
yet the default, because some userspace tools assume vt switch clears
scrollback and do so for security reasons.  All known tools that do so have
been fixed (at least in Debian), but as you can run new kernels with
arbitrarily old userspace, it's better to wait a bit longer before switching
to something effectively identical to soft scrollback.  Failure mode: after
logout, you can scroll back to the supposedly cleared content of the old
session.

Your code avoids this, at the cost of losing data about anything
representable by the currently loaded charset for anything inside
scrollback.

But in the near future, it'd be good to have soft scrollback work the same
for all drivers.

> > Right, let's see if your patchset gets okayed before building atop it.
> 
> May I add your ACK to it?

I don't believe I'm knowledgeful nor active enough in this part for my ACKs
to be meaningful.  On the other hand, I've analyzed your patchset long
enough to see no problems with it, thus if you have an use for my tags, then
sure, you have my ACK.

Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones.
⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes
⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious.  It's also interesting to see OSes
⠈⠳⣄⠀⠀⠀⠀ go back and forth wrt their intended target.