From: Carlos Llamas <cmllamas@google.com>
To: "Tiffany Y. Yang" <ynaffit@google.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arve Hjønnevåg" <arve@android.com>,
"Todd Kjos" <tkjos@android.com>,
"Martijn Coenen" <maco@android.com>,
"Joel Fernandes" <joel@joelfernandes.org>,
"Christian Brauner" <brauner@kernel.org>,
"Suren Baghdasaryan" <surenb@google.com>,
linux-kernel@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH v3 2/2] binder: Create safe versions of binder log files
Date: Wed, 7 May 2025 23:27:30 +0000 [thread overview]
Message-ID: <aBvsYmqnMZnK-Aoh@google.com> (raw)
In-Reply-To: <20250507211005.449435-4-ynaffit@google.com>
On Wed, May 07, 2025 at 09:10:06PM +0000, Tiffany Y. Yang wrote:
> Binder defines several seq_files that can be accessed via debugfs or
> binderfs. Some of these files (e.g., 'state' and 'transactions')
> contain more granular information about binder's internal state that
> is helpful for debugging, but they also leak userspace address data
> through user-defined 'cookie' or 'ptr' values. Consequently, access
> to these files must be heavily restricted.
>
> Add two new files, 'state_hashed' and 'transactions_hashed', that
> reproduce the information in the original files but use the kernel's
> raw pointer obfuscation to hash any potential user addresses. This
> approach allows systems to grant broader access to the new files
> without having to change the security policy around the existing ones.
>
> In practice, userspace populates these fields with user addresses, but
> within the driver, these values only serve as unique identifiers for
> their associated binder objects. Consequently, binder logs can
> obfuscate these values and still retain meaning. While this strategy
> prevents leaking information about the userspace memory layout in the
> existing log files, it also decouples log messages about binder
> objects from their user-defined identifiers.
>
> Acked-by: Carlos Llamas <cmllamas@google.com>
> Signed-off-by: Tiffany Y. Yang <ynaffit@google.com>
> ---
> ---
> V2->V3: Cast binder_uintptr_t to long before casting to ptr
I just tried a W=1 build and I confirm it fixes the 32bit warn. Thanks!
Tested-by: Carlos Llamas <cmllamas@google.com>
next prev parent reply other threads:[~2025-05-07 23:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-07 21:10 [PATCH v3 1/2] binder: Refactor binder_node print synchronization Tiffany Y. Yang
2025-05-07 21:10 ` [PATCH v3 2/2] binder: Create safe versions of binder log files Tiffany Y. Yang
2025-05-07 23:27 ` Carlos Llamas [this message]
2025-05-08 12:27 ` [PATCH v3 1/2] binder: Refactor binder_node print synchronization Alice Ryhl
2025-05-08 19:01 ` Tiffany Yang
2025-05-09 8:57 ` Alice Ryhl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aBvsYmqnMZnK-Aoh@google.com \
--to=cmllamas@google.com \
--cc=arve@android.com \
--cc=brauner@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=joel@joelfernandes.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maco@android.com \
--cc=surenb@google.com \
--cc=tkjos@android.com \
--cc=ynaffit@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox