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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <682df554-0602-2f94-22d1-e39a4dd8f366@kernel.org>
Date:   Fri, 16 Sep 2022 10:45:50 +0200
From:   Jiri Slaby <jirislaby@...nel.org>
To:     Theodore Ts'o <tytso@....edu>,
        наб <nabijaczleweli@...ijaczleweli.xyz>
Cc:     Federico Vaga <federico.vaga@...a.pv.it>,
        Alex Shi <alexs@...nel.org>,
        Yanteng Si <siyanteng@...ngson.cn>,
        Hu Haowen <src.res@...il.cn>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-doc-tw-discuss@...ts.sourceforge.net
Subject: Re: [PATCH 1/5] tty: remove TTY_MAGIC

On 16. 09. 22, 9:33, Theodore Ts'o wrote:
> On Fri, Sep 16, 2022 at 03:54:59AM +0200, наб wrote:
>> According to Greg, in the context of magic numbers as defined in
>> magic-number.rst, "the tty layer should not need this and I'll gladly
>> take patches"
>>
>> Ref: https://lore.kernel.org/linux-doc/YyMlovoskUcHLEb7@kroah.com/
> 
> Well, I would disagree with Greg K-H on this --- but I haven't been
> tty maintainer in well over a decade.  Assuming code is Bug-Free(tm),
> sure, it's not necessary.  But there is any kind of memory bug (e.g.,
> a corrupted pointer,

I don't think it can help with corrupted pointer much, but:

> a use-after free, some other structure
> corruption), this catches the problem earlier rather than later, and
> it's a light-weight to do a quick sanity check.

Although it's light-weight, it's also NOT that useful. Maybe tty 
_userspace_ functions return EIO, but that's about it (kernel does not 
check magic in any of its code paths, if I am looking correctly). I bet 
users would notice a corrupted tty structure even without this, and 
maybe earlier. And in that case, kmemcheck is next on the list. And that 
tells us much more than "we are corrupted".

> It has certainly caught problems in the past, and I still use this
> programming technique in programs that I do maintain, such as
> e2fsprogs.

Asking google about:
"tty_paranoia_check" "bad magic number"
gives ~149 results, the last one from 2008. And it seems to be the only 
report, the others are links to sources. So yes, it triggered at least 
once, but is it that useful? Looking at the results, I don't think so.

thanks,
-- 
js
suse labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ