Hi
On Tue, May 28, 2024, at 7:13 PM, Jeff Xu wrote:
>> > Another solution is to change memfd to be by-default sealable,
>> > although that will be an api change, but what side effect will it be
>> > ?
>> > If we are worried about the memfd being sealed by an attacker, the
>> > malicious code coul
Hi
On Thu, May 23, 2024, at 6:55 PM, Jeff Xu wrote:
> On Thu, May 23, 2024 at 9:20 AM Jeff Xu wrote:
>> On Thu, May 23, 2024 at 1:24 AM David Rheinsberg wrote:
>> > We asked for exactly this fix before, so I very much support this. Our
>> > test-suite in `dbus-broke
ll break. Luckily, this only
> affects the test suite, it does not affect
> the normal operations of dbus-broker. There is a PR with a fix[2]. In
> addition, David Rheinsberg also raised similar fix in [3]
>
> [1]:
> https://github.com/bus1/dbus-broker/blob/9eb0b7e5826fc7
..@readahead.eu/
Note that this fix is particularly important in combination with
`vm.memfd_noexec=2`, since this breaks existing user-space by enabling sealing
on all memfds unconditionally. I also encourage backporting to stable kernels.
Reviewed-by: David Rheinsberg
Thanks
David
