linux-kernel - Re: [PATCH 1/1] tty: n_gsm: make n

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:   Wed, 12 Oct 2022 08:50:19 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     "D. Starke" <daniel.starke@...mens.com>
Cc:     linux-serial@...r.kernel.org, jirislaby@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] tty: n_gsm: make n_gsm line number configurable

On Wed, Oct 12, 2022 at 08:17:15AM +0200, D. Starke wrote:
> From: Daniel Starke <daniel.starke@...mens.com>
> 
> Currently, the n_gsm line number and its derived virtual ttys are assigned
> in the order of allocations with no means to change this.

Which is fine, why do you need this to be changed?  What relies on
specific line numbers in userspace that can not handle things correctly
with the normal userspace tools we have for this type of thing?

> Introduce additional ioctl parameters numValid and num to configure the
> line number to allow predictable virtual tty allocation and numbering.
> Especially when using multiple n_gsm instances at the same time.

Ick, please no.  That should never be needed, the kernel number and name
can be anything random (and people have suggested that we do make them
random at times).  Don't hard-code numbers in your userspace tools, that
is just wrong.

> --- a/include/uapi/linux/gsmmux.h
> +++ b/include/uapi/linux/gsmmux.h
> @@ -19,7 +19,9 @@ struct gsm_config
>  	unsigned int mtu;
>  	unsigned int k;
>  	unsigned int i;
> -	unsigned int unused[8];		/* Padding for expansion without
> +	unsigned short numValid;
> +	unsigned short num;

This would never work anyway (hint "short" is not a valid uapi data
type...)

thanks,

greg k-h