linux-kernel - Re: Crash when attaching uretprobes to processes running in Docker

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]

Message-Id: <EBE7D529-5418-4BD6-B9B5-64BE0FBE8569@gmail.com>
Date: Tue, 14 Jan 2025 16:09:08 -0800
From: Eyal Birger <eyal.birger@...il.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Oleg Nesterov <oleg@...hat.com>, Jiri Olsa <olsajiri@...il.com>,
 Sarai Aleksa <cyphar@...har.com>, mhiramat@...nel.org,
 linux-kernel <linux-kernel@...r.kernel.org>,
 linux-trace-kernel@...r.kernel.org, BPF-dev-list <bpf@...r.kernel.org>,
 Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
 John Fastabend <john.fastabend@...il.com>, peterz@...radead.org,
 tglx@...utronix.de, bp@...en8.de, x86@...nel.org, linux-api@...r.kernel.org,
 Andrii Nakryiko <andrii@...nel.org>,
 Daniel Borkmann <daniel@...earbox.net>,
 Alexei Starovoitov <ast@...nel.org>, rostedt@...dmis.org, rafi@....io,
 Shmulik Ladkani <shmulik.ladkani@...il.com>
Subject: Re: Crash when attaching uretprobes to processes running in Docker

Hi,

> On Jan 14, 2025, at 15:52, Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:
> 
> On Tue, Jan 14, 2025 at 2:11 PM Oleg Nesterov <oleg@...hat.com> wrote:
>> 
>>> On 01/14, Andrii Nakryiko wrote:
>>> 
>>> On Tue, Jan 14, 2025 at 12:40 PM Oleg Nesterov <oleg@...hat.com> wrote:
>>>> 
>>>> But, unlike sys_uretprobe(), sys_rt_sigreturn() is old, so the existing
>>>> setups must know that sigreturn() should be respected...
>>> 
>>> someday sys_uretprobe will be old as well ;) FWIW, systemd allowlisted
>>> sys_uretprobe, see [0]
>> 
>> And I agree! ;)
>> 
>> I mean, I'd personally prefer to do nothing and wait until userspace figures
>> out that we have another "special" syscall.
>> 
>> But can we do it? I simply do not know. Can we ignore this (valid) bug report?
>> 
> 
> Seems wrong for kernel to try to guess whether some syscall is
> filtered by some policy or not (though maybe I'm misunderstanding the
> details and it's kernel-originated problem?). Seems like a recipe for
> more problems.
> 
> Nothing is really fundamentally broken. Some piece of software needs
> an upgraded library to not disable the kernel's special syscall (just
> like sys_rt_sigreturn, nothing "new" here, really). Users can't do
> uprobing in such broken setups (but not in general), seems like a good
> incentive for everyone to push for the right thing here: fixed up to
> date software.

It’s not “users” doing the uprobing in this case.
Its software, that’s working fine in previous kernel versions and upon upgrade starts creating crashes in other processes.

IMHO demanding that other software (e.g docker) be upgraded in order to run on a newer kernel is not what Linux formerly guaranteed.

Eyal
> 
>> Oleg.
>>