linux-kernel - Re: [PATCH] Kernel fbcon UNICODE font support

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: <20101127125742.GD4865@const.famille.thibault.fr>
Date:	Sat, 27 Nov 2010 13:57:42 +0100
From:	Samuel Thibault <samuel.thibault@...-lyon.org>
To:	microcai@...oraproject.org
Cc:	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	brad@...uo.com
Subject: Re: [PATCH] Kernel fbcon UNICODE font support

Hello,

Microcai, le Fri 26 Nov 2010 13:53:45 +0800, a écrit :
>  I know there are most people speaking only English, and never meet
> non-ASCII characters on console. But, hey , what about others ?

Well, you can't deny that there _is_ some support for non-ASCII. But
just at most 512 glyphs and single width, indeed.

>  The first thing I need to handle is that, currently there is no room
> for adding UNICODE font, only 8bit for characters, how can you do?

(or 9bit, but no more indeed)

>  Also , some characters are double-width. So the solution is  make an
> backing store. 0xFE and 0xFF stands for character value store else
> where, and 0xFF means , left-half of the else where character, and 0xFE
> means right-half of the else where character. 
> 
>  This is a basic solution, the best is that making vc->vc_screenbuf
> store full UNICODE/attribute value, But changing it may break some
> drivers, so , currently I won't try that way. 

I'd much prefer the full unicode way, however.  Trying to hack around
with 0xFE/0xFF will just bring hard-to-fix bugs, while it's quite easy
to make sure we capture not-up-to-date drivers by changing field names
for instance.  I'd say we should first do that, and then it'll be
easy to move the old vgaposition/glyph translation cruft into the few
drivers that need it.  Yes, this seems to be the hard way.  But that's
the short-term hard then mid-term easy way, which is way easier to
accept than the short-term easy then mid/long-term tedious way that you
propose.

> The UNICODE font just too large to be included in e-mail, please follow

There is no way we want to include a big unicode font in the kernel :)

> In future, we don't have to compile  that big font into kernel, we
> should use setfont to load UNICODE font.

Yes.

> But, .psf does not support that much charcount (or maybe yes, and  I
> need some search? )

That's just a matter of fixing tools: the newer version of the psf
format already supports 2^16 glyphs.

> So, here is the patch that add UNICODE font handling functionary.

I've just had a quick glance over it, and there are quite a few things
that bother me, including:

> @@ -296,6 +295,8 @@ int set_selection(const struct tiocl_selection
> __user *sel, struct tty_struct *t
>  			}
>  			obp = bp;
>  		}
> +		if (c > 0x80)
> +			i += 2;
>  	}
>  	sel_buffer_lth = bp - sel_buffer;
>  	return 0;

That is the kind of hack that really shows your current approach will
most probably just bring us bugs.

> @@ -2171,6 +2205,8 @@ static int do_con_write(struct tty_struct *tty,
> const unsigned char *buf, int co
>  		rescan = 0;
>  		inverse = 0;
>  		width = 1;
> +		vc->vc_utf = 1;

?!
There is now way we can accept to systematically switch to utf-8.

> -		vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_NOWAIT);
> +		vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size * 2, GFP_NOWAIT);

With a proper switch to a "unicode character" type, this would rather be
"* sizeof(something)", so that choosing between 16bit unicode and 32bit
unicode would even be trivial.

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