linux-kernel - Re: why were GIO_FONTX/PIO_FONTX dropped? i was using them

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <YNG+CSsO0K5/WgT5@kroah.com>
Date:   Tue, 22 Jun 2021 12:40:09 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     nick black <dankamongmen@...il.com>
Cc:     Jiri Slaby <jirislaby@...nel.org>,
        "Maciej W. Rozycki" <macro@...am.me.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: why were GIO_FONTX/PIO_FONTX dropped? i was using them

On Tue, Jun 22, 2021 at 03:18:28AM -0400, nick black wrote:
> Jiri et al,
> 
> I'm the author of Notcurses, a library for "blingful terminal
> UIs". As part of this, I was using the GIO_FONTX and PIO_FONTX
> ioctl()s to reprogram the Linux console fonts. I proposed this
> functionality on 2019-12-22 in Notcurses bug #201:
> 
>  https://github.com/dankamongmen/notcurses/issues/201
> 
> On 2020-05-13, I began using these two ioctls (along with their
> _UNIMAP equivalents), as documented in console_ioctl(2), to
> recover the font, scan it for Unicode block- and line-drawing
> characters, and add them if absent:
> 
>  https://github.com/dankamongmen/notcurses/pull/795/files
>  https://github.com/dankamongmen/notcurses/pull/794/files
> 
> some happy initial results were saved for posterity; i've
> reproduced them here:
> 
>  https://nick-black.com/images/you-stole-my-ioctls.jpg
> 
> this worked perfectly, and I extended my Quadblitter to it, and
> cheerfully considered this a completed feature. You can see the
> results in this video from September 2020. it starts at 192s in,
> though you ought just watch the whole thing because it's
> awesome [0]:
> 
>  https://www.youtube.com/watch?v=cYhZ7myXyyg&t=192s
> 
> How sad, then, when a few weeks back I noticed that this
> working code was no longer working on newer kernels:
> 
>  https://github.com/dankamongmen/notcurses/issues/1726
> 
> I assumed it was my bug, having heard something over the years
> of Linux's commitment to APIs and not breaking working code. but
> today i went through the console_ioctl(2) man page (2017-09-15),
> and my code, and strace, and finally the kbd 2.3.3 source, where
> i found out about KDFONTOP. ok, but why weren't FONTX working?
> then i found ff2047fb755d4415ec3c70ac799889371151796d:
> 
>  "As was demonstrated by commit 90bfdeef83f1 (tty: make FONTX ioctl use
>   the tty pointer they were actually passed), these ioctls are not used
>   from userspace, as:
>   1) they used to be broken (set up font on current console, not the open
>      one) and racy (before the commit above)
>   2) KDFONTOP ioctl is used for years instead"
>     
> as hopefully demonstrated here, they *were* used from userspace.
> i'm happy to move to KDFONTOP (since it doesn't appear to be in
> the 5.11 man pages, maybe i'll write it up), but this was
> somewhat rude, and maybe the ioctls weren't as broken as you
> think?

They were still quite broken and racy and given that we could not find
any users in our search, we felt it was safe to remove them.

As you say, moving to KDFONTOP works, that's great, all is well, sorry
for breaking the existing code you had, but part of removing things is
seeing if there are valid users that can not change.  Sorry for missing
your usages.

> also, i notice the definitions weren't removed. if no userspace
> was using them, they could have been, right? that would have
> been better than the ioctl()s mysteriously failing with ENOTTY.

We can remove them, want to send a patch to do so?

thanks,

greg k-h