Re: [PATCH v3 1/3] vt: preserve unicode values corresponding to screen characters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 11, 2018 at 2:18 AM, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Jul 10, 2018 at 05:52:01PM -0700, Kees Cook wrote:
>> On Tue, Jun 26, 2018 at 8:56 PM, Nicolas Pitre <nicolas.pitre@xxxxxxxxxx> wrote:
>> > The vt code translates UTF-8 strings into glyph index values and stores
>> > those glyph values directly in the screen buffer. Because there can only
>> > be at most 512 glyphs, it is impossible to represent most unicode
>> > characters, in which case a default glyph (often '?') is displayed
>> > instead. The original unicode value is then lost.
>> >
>> > This patch implements the basic screen buffer handling to preserve unicode
>> > values alongside corresponding display glyphs.  It is not activated by
>> > default, meaning that people not relying on that functionality won't get
>> > the implied overhead.
>> >
>> > Signed-off-by: Nicolas Pitre <nico@xxxxxxxxxx>
>> > Tested-by: Dave Mielke <Dave@xxxxxxxxx>
>> > Acked-by: Adam Borowski <kilobyte@xxxxxxxxxx>
>> > ---
>> >  drivers/tty/vt/vt.c            | 220 +++++++++++++++++++++++++++++++--
>> >  include/linux/console_struct.h |   2 +
>> >  2 files changed, 211 insertions(+), 11 deletions(-)
>> >
>> > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
>> > index 1eb1a376a0..7b636638b3 100644
>> > --- a/drivers/tty/vt/vt.c
>> > +++ b/drivers/tty/vt/vt.c
>> > [...]
>> > +static void vc_uniscr_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
>> > +                            enum con_scroll dir, unsigned int nr)
>> > +{
>> > +       struct uni_screen *uniscr = get_vc_uniscr(vc);
>> > +
>> > +       if (uniscr) {
>> > +               unsigned int s, d, rescue, clear;
>> > +               char32_t *save[nr];
>>
>> Can you adjust this to avoid the VLA here? I've almost gotten all VLAs
>> removed from the kernel[1], and this is introducing a new one. :)
>
> This is already in my tree, sorry :(

Yup, that's fine. (It's how I noticed it: linux-next VLA build tests.)
I'm just hoping it can get solved before the merge window opens. :)

There are still a bunch of VLAs I'm chipping away at, but this was a
newly added one, so I was hoping Nicolas (when he's back from
vacation) will have ideas on how to best avoid it.

Thanks!

-Kees

-- 
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Audio]     [Hams]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Samba]     [Fedora Users]

  Powered by Linux