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]
Date:   Sun, 18 Dec 2022 16:25:01 +0100
From:   Alexey Gladkov <legion@...nel.org>
To:     Samuel Thibault <samuel.thibault@...-lyon.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>, kbd@...ts.altlinux.org,
        linux-kernel@...r.kernel.org
Subject: Re: [kbd] [patchv2 3/3] VT: Bump font size limitation to 64x128
 pixels

On Sun, Dec 18, 2022 at 03:55:32PM +0100, Samuel Thibault wrote:
> Hello,
> 
> Alexey Gladkov, le dim. 18 déc. 2022 15:39:38 +0100, a ecrit:
> > On Sun, Dec 18, 2022 at 01:32:12AM +0100, Samuel Thibault wrote:
> > > This moves 32x32 font size limitation checking down to drivers, so that
> > > fbcon can allow large fonts.
> > > 
> > > We still keep a limitation to 64x128 pixels so as to have a simple bounded
> > > allocation for con_font_get and in the userland kbd tool. That glyph size
> > > will however be enough to have 128x36 characters on a "16/9 8K display".
> > > 
> > > Signed-off-by: Samuel Thibault <samuel.thibault@...-lyon.org>
> > > 
> > > ---
> > > V1 -> V2: Switch con_font_get to kvmalloc/kvfree instead of kmalloc/kfree
> > > 
> > > Index: linux-6.0/drivers/tty/vt/vt.c
> > > ===================================================================
> > > --- linux-6.0.orig/drivers/tty/vt/vt.c
> > > +++ linux-6.0/drivers/tty/vt/vt.c
> > > @@ -4575,17 +4575,20 @@ void reset_palette(struct vc_data *vc)
> > >  /*
> > >   *  Font switching
> > >   *
> > > - *  Currently we only support fonts up to 32 pixels wide, at a maximum height
> > > - *  of 32 pixels. Userspace fontdata is stored with 32 bytes (shorts/ints, 
> > > - *  depending on width) reserved for each character which is kinda wasty, but 
> > > - *  this is done in order to maintain compatibility with the EGA/VGA fonts. It 
> > > - *  is up to the actual low-level console-driver convert data into its favorite
> > > - *  format (maybe we should add a `fontoffset' field to the `display'
> > > - *  structure so we won't have to convert the fontdata all the time.
> > > + *  Currently we only support fonts up to 128 pixels wide, at a maximum height
> > > + *  of 128 pixels. Userspace fontdata may have to be stored with 32 bytes
> > > + *  (shorts/ints, depending on width) reserved for each character which is
> > > + *  kinda wasty, but this is done in order to maintain compatibility with the
> > > + *  EGA/VGA fonts. It is up to the actual low-level console-driver convert data
> > > + *  into its favorite format (maybe we should add a `fontoffset' field to the
> > > + *  `display' structure so we won't have to convert the fontdata all the time.
> > >   *  /Jes
> > >   */
> > >  
> > > -#define max_font_size 65536
> > > +#define max_font_width	64
> > > +#define max_font_height	128
> > > +#define max_font_glyphs	512
> > > +#define max_font_size	(max_font_glyphs*max_font_width*max_font_height)
> > 
> > As a suggestion that you can safely ignore. Maybe make max_font_glyphs a
> > sysctl parameter to be able to use larger fonts ?
> > 
> > I get requests from time to time in kbd that it is not possible to load a
> > larger font.
> 
> 64KiB was really low, while the theoretically possible max was
> 32*32*512 = 512KB, so I understand there used to be such requests :)
> 
> Here, by setting the max to 64x128*512, I don't think we'll need more.

I was not talking about the size of one glyph, but about the number of
glyphs in the font. Right now the font cannot have more than 512 glyphs.

> Even with a 8K screen (will such really exist and want a text console?)
> the max 64x128 gets 128 characters on a single line, for soemthing like
> 36 lines. So I guess it's not worth adding yet another sysctl :)

Ok.

> Samuel
> 

-- 
Rgrds, legion

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ