From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) (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 EA10D53812 for ; Mon, 22 Jan 2024 18:35:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=167.114.26.122 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705948546; cv=none; b=B/Hbob7781HHxo8KB7s5d/sZKr6RGGjvV5u/0wCTyAQXtHDnGWYamq5NIXdbmi0LeG2lvsZJPNEepAgcMdVA8w1xIT7zyfKJIUQ7B+BxvENtqWOS7TV+8kbAuhnx/LAtM34VFbvALYa/L/tFeNhAmNcAU+gunqo4I642bOK7oPQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705948546; c=relaxed/simple; bh=X4oiGtQDe6Pom+07coqzxMStwwOl6rmxWTszP465WXw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QwsO6IcmP7PjhHmfuhtyccbiswY30Qt3la7Qy2QCZrYEln2W8DMwYzIRn2+a1YpWJivRzArIoCKqXPUY4JBOS+bGe2Js9pi7LiSLA83jq88pIRMsGbP3eoqkalPLImv75rgs6Luf75ZePSmtLKe+sNuww5IfaLFfpWEa1ACfNbo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com; spf=pass smtp.mailfrom=efficios.com; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b=qMCmsA20; arc=none smtp.client-ip=167.114.26.122 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=efficios.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="qMCmsA20" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1705948542; bh=X4oiGtQDe6Pom+07coqzxMStwwOl6rmxWTszP465WXw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qMCmsA208S8p1KrKg6EzKEwWItsKQWq9ZUStNcaiBge9iAvo6axs0oc9XG8u7PK6D LbbAYAmCmqvwWpvEuIaHyebfUb6g8wnJfP2Qujjgwz5Ak+EeJocW+ClNYyAG+9zVV6 vU0u0HZPE+wwccycrQV+bgjxSnmFnR+YvhvGGC/4NhvuqKtvP5zpafiBnXiLfAs9sn CWaePidFWfWHL+q+sM+hBPhA84VmvQBREnW7m4rsHzGreD8e4xbGNAaoomggakSdm6 5HaVCCFTQ6MtikFKJvtjMJLcVd4HVptMhz/YKGua5XcxkHseJCTKlpn34Gt0/0sgGw 1/UYLoFQ3xEuA== Received: from [172.16.0.134] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4TJf6k373fzTbb; Mon, 22 Jan 2024 13:35:42 -0500 (EST) Message-ID: Date: Mon, 22 Jan 2024 13:35:43 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [for-linus][PATCH 1/3] eventfs: Have the inodes all for files and directories all be the same Content-Language: en-US To: Steven Rostedt Cc: Geert Uytterhoeven , Kees Cook , Linus Torvalds , linux-kernel@vger.kernel.org, Masami Hiramatsu , Mark Rutland , Andrew Morton , Christian Brauner , Al Viro , Ajay Kaher References: <20240117143548.595884070@goodmis.org> <20240117143810.531966508@goodmis.org> <20240122100630.6a400dd3@gandalf.local.home> <20240122125004.7bbf0b70@gandalf.local.home> From: Mathieu Desnoyers In-Reply-To: <20240122125004.7bbf0b70@gandalf.local.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2024-01-22 12:50, Steven Rostedt wrote: > On Mon, 22 Jan 2024 12:14:36 -0500 > Mathieu Desnoyers wrote: [...] >> On my 6.1.0 kernel: >> >> find /sys/kernel/tracing | wc -l >> 15598 >> >> (mainly due to TRACE_EVENT ABI files) >> >> Hashing risks: >> >> - Exposing kernel addresses if the hashing algorithm is broken, > > Well this was my biggest concern, but if I truncate at least a nibble, with > the unique salt to the algorithm for each file, how easily does that expose > kernel addresses. > > The ei itself, is created from kmalloc() so you would at best get a heap > address. But with the missing nibble (if I mask it with ((1 << 28) - 1), > and much more taken away for 64 bit systems), and the added unique salt, is > it possible for this to expose anything that could be used in an attack? I don't know, which is why I am concerned about it. But I don't think we should spend time trying to understand all possible attack scenarios associated with hashing of kernel addresses when there are much simpler options available. > >> - Collisions if users are unlucky (which could trigger those >> 'find' errors). >> >> Those 15598 inode values fit within a single page (bitmap of >> 1922 bytes). >> >> So I would recommend simply adding a bitmap per tracefs filesystem >> instance to keep track of inode number allocation. > > And how do I recover this bit after the inode is freed, but then referenced > again? You would keep the allocated inode number value within your data structure associated with the inode. If you never free inodes, then you can just use a static increment as Linus suggested. But AFAIU there are cases where you free inodes, hence my suggestion of bitmap. When the inode is freed, you know which inode number is associated from the field in your data structure, so you can clear this bit in the bitmap. On the next inode allocation, you find-first-zero-bit in the bitmap, and set it to one to reserve it. > >> >> Creation/removal of files/directories in tracefs should not be >> a fast-path anyway, so who cares about the speed of a find first >> bit within a single page ? >> > > When an inode is no longer referenced, it is freed. When it is referenced > again, I want it to be recreated with the same inode number it had > previously. How would having a bitmask help with that? I need a way to map > an ei structure with a unique number without adding another 4 bytes to the > structure itself. As discussed in a separate exchange with Linus, why do you care so much about not adding a 4 bytes field to the structure ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com