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]

Message-ID: <DB9PR10MB58818736388F209396CEA749E0259@DB9PR10MB5881.EURPRD10.PROD.OUTLOOK.COM>
Date:   Thu, 13 Oct 2022 11:09:02 +0000
From:   "Starke, Daniel" <daniel.starke@...mens.com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "jirislaby@...nel.org" <jirislaby@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/1] tty: n_gsm: make n_gsm line number configurable

> > 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.

Thank you for your feedback and review. I understand your points.
Please discard this patch.

> > --- 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...)

I am surprised about this as gsm_netconfig already uses unsigned short.

Best regards,
Daniel Starke