linux-kernel - Re: [PATCH] vt: configurable number of console devices

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: <CAG0f_nYQSn8eFHH3EcV4zxia0C6v7PfCvXybx40em9KgtzMGqQ@mail.gmail.com>
Date:   Wed, 29 May 2019 15:09:11 -0700
From:   Trevor Bourget <tgb.kernel@...il.com>
To:     Jiri Slaby <jslaby@...e.cz>
Cc:     gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        dhowells@...hat.com
Subject: Re: [PATCH] vt: configurable number of console devices

Sorry, I hadn't registered that was uapi. You are right, as a
configuration setting it's an odd thing to expose there.
That define won't really be any use to user space except for type
range validation, and as such it would actually be unhelpful for it to
be other than 63.

I will add if defined(__KERNEL__) to improve that, so that it will be
constant for uapi.

btw The idea is obviously not new. I can give credit to James Cox who
posted an actual patch 15 years ago that never merged.
https://lore.kernel.org/lkml/E1BFhPh-00027s-IL@smtp.gentoo.org/

-- Trevor

On Wed, May 29, 2019 at 4:03 AM Jiri Slaby <jslaby@...e.cz> wrote:
>
> On 28. 05. 19, 6:31, Trevor Bourget wrote:
> > --- a/include/uapi/linux/vt.h
> > +++ b/include/uapi/linux/vt.h
> > @@ -8,9 +8,13 @@
> >   * resizing).
> >   */
> >  #define MIN_NR_CONSOLES 1       /* must be at least 1 */
> > +#ifdef CONFIG_MAX_NR_CONSOLES
> > +#define MAX_NR_CONSOLES CONFIG_MAX_NR_CONSOLES
>
> This is an uapi header. Will the #ifdef work there? As I don't think
> CONFIG_* (i.e. autoconf.h) is available in userspace...
>
> Also, I am not sure if there is any consumer of this macro in userspace
> at all -- so what are the possible effects of this being "incorrect"?
>
> BTW having headers from one kernel and booting another with different
> settings makes this definition also incorrect. The same as for e.g. the
> HZ constant. Again, not sure if this is a problem at all.
>
> thanks,
> --
> js
> suse labs