linux-kernel - Re: [PATCH RFC 00/20] Setting up Binder for the future

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:   Thu,  2 Nov 2023 13:33:58 +0000
From:   Alice Ryhl <aliceryhl@...gle.com>
To:     cmllamas@...gle.com
Cc:     a.hindborg@...sung.com, alex.gaynor@...il.com,
        aliceryhl@...gle.com, arve@...roid.com, benno.lossin@...ton.me,
        bjorn3_gh@...tonmail.com, boqun.feng@...il.com, brauner@...nel.org,
        gary@...yguo.net, gregkh@...uxfoundation.org, jeffv@...gle.com,
        joel@...lfernandes.org, linux-kernel@...r.kernel.org,
        maco@...roid.com, mattgilbride@...gle.com, mmaurer@...gle.com,
        ojeda@...nel.org, rust-for-linux@...r.kernel.org,
        surenb@...gle.com, tkjos@...roid.com, wedsonaf@...il.com
Subject: Re: [PATCH RFC 00/20] Setting up Binder for the future

Carlos Llamas <cmllamas@...gle.com> writes:
> On Wed, Nov 01, 2023 at 06:01:30PM +0000, Alice Ryhl wrote:
>> Although this rewrite completely rethinks how the code is structured and
>> how assumptions are enforced, we do not fundamentally change *how* the
>> driver does the things it does. A lot of careful thought has gone into
>> the existing design. The rewrite is aimed rather at improving code
>> health, structure, readability, robustness, security, maintainability
>> and extensibility. We also include more inline documentation, and
> 
> Can you expand a bit more on what the plan is here? Is it a two step
> process? e.g. replacing first and then revisiting the *how* binder does
> things later?

Yes, a big part of the motivation behind this rewrite is to make it
easier to continue evolving Binder.

For example, we would like to make Binder have more thorough epoll
support and the ability for a single-threaded server to handle many
incoming transactions at the same time, similar to how you can use many
non-blocking tcp sockets on a single thread today. This would have a
number of performance benefits, like fewer threads, less contact
switching, etc.

We would prefer to not attempt this in the C driver because of how
challenging it is to make significant changes.

Alice