From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-187.mta0.migadu.com (out-187.mta0.migadu.com [91.218.175.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF8F610F4 for ; Thu, 11 Apr 2024 00:26:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.187 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712795190; cv=none; b=ZVWSKaXqFrUdSloBoGnN6HETwHmASjR0t77VaH1PIrQUmdhHpAjyrh+8b2m8VbJPt7XvSTxoMff3xNX6ynSi5F9YWi92D2/kXKGLRooEPQ9/fDTbRWXAf0rtQvZBYPAqLQlnt5UuJM+qHvQzrowOMihNMN7laU8TZ+fErT5LobI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712795190; c=relaxed/simple; bh=iOxJT8OfTlI2kJRkaXpBe16OPqSDgaEyZ9Me/w385Wc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dhYsP0eyJzWlqwOWladitnF2XS/YINdTnhzp4pbo6DXo4DPNHKmgz0Ub/xxK9nGcGG/4XnRDwx+L/m4/8qwxSmKLkA00q/o8W56ViFbmn/+g1aW1vU/5rLmNa2iVekj/b5xqjtX4DbyZOLTONF2N4U8txN/Ez256SX/B1+AUMko= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=ZPkn0pwI; arc=none smtp.client-ip=91.218.175.187 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="ZPkn0pwI" Message-ID: <31904afe-1d8a-4169-a3bd-d6d1c86cac5f@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1712795186; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gB2Wp3EMMPBhX4wRoJ9ubR900ORB8tJWdO8CVq4jwWQ=; b=ZPkn0pwIJRwaHIbkfEkVSdU9ecajbn7zceHnEAJi/o70wwJfHYmj3NZOCeYFMxYXFAXR0C Mb9wM84w4gd8qYC/C4KAzd+Vo8BhaVCZm5Bzs0ueih2vvXuPUsPI8hKxnOnEzZJmb0Y8dt YrFK1drcLrl96FZP67JFf7ejx+FK/0s= Date: Wed, 10 Apr 2024 17:26:18 -0700 Precedence: bulk X-Mailing-List: cgroups@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [RFC PATCH bpf-next 0/3] bpf: freeze a task cgroup from bpf Content-Language: en-GB To: =?UTF-8?Q?Michal_Koutn=C3=BD?= , Djalal Harouni Cc: Tejun Heo , Zefan Li , Johannes Weiner , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Mykola Lysenko , Shuah Khan , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, bpf@vger.kernel.org, linux-kselftest@vger.kernel.org References: <20240327-ccb56fc7a6e80136db80876c@djalal> <20240327225334.58474-1-tixxdz@gmail.com> <705d7180-aced-46ba-80a6-84ac4e2b96b9@gmail.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yonghong Song In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 4/9/24 8:32 AM, Michal Koutný wrote: > Hi. > > On Tue, Apr 02, 2024 at 07:20:45PM +0100, Djalal Harouni wrote: >> Thanks yes, I would expect freeze to behave like signal, and if one >> wants to block immediately there is the LSM override return. The >> selftest attached tries to do exactly that. > Are you refering to this part: > > int BPF_PROG(lsm_freeze_cgroup, int cmd, union bpf_attr *attr, unsigned int size) > ... > ret = bpf_task_freeze_cgroup(task, 1); > if (!ret) { > ret = -EPERM; > /* reset for next call */ > ? > > >> Could be security signals, reading sensitive files or related to any >> operation management, for X reasons this user session should be freezed >> or killed. > What can be done with a frozen cgroup after anything of that happens? > Anything besides killing anyway? > > Killing of an offending process could be caught by its supervisor (like > container runtime or systemd) and propagated accordingly to the whole > cgroup. > >> The kill is an effective defense against fork-bombs as an example. > There are several ways how to prevent fork-bombs in kernel already, it > looks like a contrived example. > >> Today some container/pod operations are performed at bpf level, having >> the freeze and kill available is straightforward to perform this. > It seems to me like an extra step when the same operation can be done from > (the managing) userspace already. > >> For generalizing this, haven't thought about it that much. First use >> case is to try to get freeze and possibly kill support, and use a common >> interface as requested. > BTW, I notice that there is bpf_sys_bpf() helper that allows calling an > arbitrary syscall. Wouldn't that be sufficient for everything? This is not true. Currently, only 'bpf' and 'close' syscalls are supported. static const struct bpf_func_proto * syscall_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog) { switch (func_id) { case BPF_FUNC_sys_bpf: return !bpf_token_capable(prog->aux->token, CAP_PERFMON) ? NULL : &bpf_sys_bpf_proto; case BPF_FUNC_btf_find_by_name_kind: return &bpf_btf_find_by_name_kind_proto; case BPF_FUNC_sys_close: return &bpf_sys_close_proto; case BPF_FUNC_kallsyms_lookup_name: return &bpf_kallsyms_lookup_name_proto; default: return tracing_prog_func_proto(func_id, prog); } } More syscalls can be added (through kfunc) if there is a use case for that. > > (Based on how I still understand the problem: either you must respond > immediately and then the direct return from LSM is appropriate or timing > is not sensitive but you want act on whole cgroup.) > > Thanks, > Michal