linux-kernel - Re: [PATCH] tty: Remove dead termiox code

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:   Fri, 4 Dec 2020 09:51:07 +0100
From:   Jiri Slaby <jirislaby@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Jann Horn <jannh@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tty: Remove dead termiox code

On 04. 12. 20, 9:36, Greg Kroah-Hartman wrote:
> On Fri, Dec 04, 2020 at 09:20:39AM +0100, Jiri Slaby wrote:
>> On 04. 12. 20, 9:17, Greg Kroah-Hartman wrote:
>>> On Fri, Dec 04, 2020 at 08:22:41AM +0100, Jiri Slaby wrote:
>>>> On 03. 12. 20, 3:03, Jann Horn wrote:
>>>>> set_termiox() and the TCGETX handler bail out with -EINVAL immediately
>>>>> if ->termiox is NULL, but there are no code paths that can set
>>>>> ->termiox to a non-NULL pointer; and no such code paths seem to have
>>>>> existed since the termiox mechanism was introduced back in
>>>>> commit 1d65b4a088de ("tty: Add termiox") in v2.6.28.
>>>>> Similarly, no driver actually implements .set_termiox; and it looks like
>>>>> no driver ever has.
>>>>
>>>> Nice!
>>>>
>>>>> Delete this dead code; but leave the definition of struct termiox in the
>>>>> UAPI headers intact.

Note this ^^^^^. He is talking about _not_ touching the definition in 
the UAPI header. Does the rest below makes more sense now?

>>>> I am thinking -- can/should we mark the structure as deprecated so that
>>>> userspace stops using it eventually?
>>>
>>> If it doesn't do anything, how can userspace even use it today?  :)
>>
>> Well, right. I am in favor to remove it, BUT: what if someone tries that
>> ioctl and bails out if EINVAL is returned. I mean: if they define a local
>> var of that struct type and pass it to the ioctl, we would break the build
>> by removing the struct completely. Even if the code didn't do anything
>> useful, it still could be built. So is this very potential breakage OK?
> 
> I'm sorry, but I don't understand.  This is a kernel-internal-only
> structure, right?  If someone today tries to call these ioctls, they
> will get a -EINVAL error as no serial driver in the tree supports them.
> 
> If we remove the structure (i.e. what this patch does), and someone
> makes an ioctl call, they will still get the same -EINVAL error they did
> before.
> 
> So nothing has changed as far as userspace can tell.
> 
> Now if they have an out-of-tree serial driver that does implement this
> call, then yes, they will have problems, but that's not our problem,
> that is theirs for not ever submitting their code.  We don't support
> in-kernel apis with no in-kernel users.
> 
> Or am I still confused?
> 
> thanks,
> 
> greg k-h
> 


-- 
js