linux-kernel - Re: AUTOSEL process

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:   Sun, 12 Mar 2023 11:57:46 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Amir Goldstein <amir73il@...il.com>
Cc:     Eric Biggers <ebiggers@...nel.org>, Willy Tarreau <w@....eu>,
        Theodore Ts'o <tytso@....edu>,
        Matthew Wilcox <willy@...radead.org>,
        Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, viro@...iv.linux.org.uk,
        linux-fsdevel@...r.kernel.org,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>
Subject: Re: AUTOSEL process

On Sun, Mar 12, 2023 at 09:42:59AM +0200, Amir Goldstein wrote:
>On Sun, Mar 12, 2023 at 7:41 AM Eric Biggers <ebiggers@...nel.org> wrote:
>>
>...
>> I mean, "patches welcome" is a bit pointless when there is nothing to patch, is
>> it not?  Even Sasha's stable-tools, which he finally gave a link to, does not

"finally" being all the way back in 2015
(https://lkml.org/lkml/2015/11/9/422), and getting no contributions from
3rd parties for the next 7 years.

Really, we're not pushing back on ideas, we're just saying that this is
something has happened before ("open up your scripts so we can
reuse/improve") and getting nowhere.

>> include anything related to AUTOSEL.  It seems AUTOSEL is still closed source.

Not as much as closed source as a complete mess on a VM I'm afraid to
lose.

I didn't really want to try and invest the effort into extracting it out
becuase:

1. It's one of the first things I did when I started learning about
neural networks, and in practice it's inefficient and could use a
massive overhaul (or rewrite). For example, it currently has ~15k
inputs, which means that it needs a beefy GPU to be able to run on (it
won't run on your home GPU)..

2. At that time I wasn't familiar with coding for NN either, so it's a
mess of LUA code to run under Torch (yes, not even pytorch).

3. It's very tied to how VMs on Azure operate, and could use a lot of
abstraction.

So really, I'd much rather invest effort into rewriting this mess rather
than digging it out of the crevices of the VM it's sitting in.

>> BTW, I already did something similar "off to the side" a few years ago when I
>> wrote a script to keep track of and prioritize syzbot reports from
>> https://syzkaller.appspot.com/, and generate per-subsystem reminder emails.
>>
>> I eventually ended up abandoning that, because doing something off to the side
>> is not very effective and is hard to keep up with.  The right approach is to
>> make improvements to the "upstream" process (which was syzbot in that case), not
>> to bolt something on to the side to try to fix it after the fact.
>>
>> So I hope people can understand where I'm coming from, with hoping that what the
>> stable maintainers are doing can just be improved directly, without first
>> building something from scratch off to the side as that is just not a good way
>> to do things.  But sure, if that's the only option to get anything nontrivial
>> changed, I'll try to do it.
>>
>
>Eric,
>
>Did you consider working to improve or add functionality to b4?

FTR, I'm happy to shift investment into tooling for stable maintenance
into b4.

-- 
Thanks,
Sasha