From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 EC170182D2 for ; Mon, 6 Jan 2025 14:38:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.9.28.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736174322; cv=none; b=bUPwxCLz+WllGab4mcVFYxg++oFBNRsO8pZa8kw/iAsZskLq0OZHiA27fdqMgJ8i84k9ZIf7rcSg6DnDKVJWWhk6SrorvR4bRXhpsMf51tPyy2Q9+EEnUSnYhE//g2mssIlWRgAWRLzbc2DIP3b7Z2nmWAwNnceZjVKJ5KNcd7c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736174322; c=relaxed/simple; bh=W6ulDcl99xv0bR5pnHdliLM7NjE/Hz/0h9E24A0C5Bs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Y124F3BNfhbfJUAYD51HFHV5A57Mt1awtbvMTGuWeUjxEFDmydgIZwjMwPjPd0PVbVZ1WUaTiVJWBkBFBTtVnBnNJupHrPr97nJLKef0EsSuFdoxlf3fXMPNfi11ZKR0J6KoV+vDGsfdcqJmx7EVNMIvmakR9HQ9+ov4zHFoKVk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b=fnEoRGqM; arc=none smtp.client-ip=18.9.28.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mit.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b="fnEoRGqM" Received: from cwcc.thunk.org (pool-173-48-117-149.bstnma.fios.verizon.net [173.48.117.149]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 506EcULQ014121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jan 2025 09:38:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1736174312; bh=RjAQGLsaOBzCK+h1fjSzW+zu5f8r4TpT3Nv4uUy1DVo=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=fnEoRGqMC4HEDtzQpNieI7aBsjoUcTa0ORINOJx8mgtp0vIUcoHZIztetlnwdf7IQ 8uKNpCEr6ZYqo6H1DDuBoClOctLP14pa1f+1FTBURiD0/7Q68HxwPwRkfuHMk7Rrp/ 8/Y1ORL2AEkVy0pvFvLCZBHzBkuNLevfXQC/c1FXeDsBvADLe1L+8GLk9CTW64GLrX DDI6L54HBfK9G4J4rUaKd7aMXbk5Cfsw3h1AOwm6Y21jGR5ws93isqiGg95VwpIgi8 f7nkmXEhYsal4NBI0v7pTOo2a9k44fb9Wv5rj/2e0heAJgCFlUMPEts0NYrHg9xgpk RM32x0KSa9LVA== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 9B77C15C0164; Mon, 06 Jan 2025 09:38:30 -0500 (EST) Date: Mon, 6 Jan 2025 09:38:30 -0500 From: "Theodore Ts'o" To: =?iso-8859-1?Q?Andr=E9?= Coelho Cc: linux-kernel@vger.kernel.org Subject: Re: shared libs Message-ID: <20250106143830.GD1284777@mit.edu> References: <9c6593e7-4527-463b-8a9a-96f5523060b6@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9c6593e7-4527-463b-8a9a-96f5523060b6@gmail.com> On Sat, Jan 04, 2025 at 09:59:06PM +0000, André Coelho wrote: > > instead of getting shared libraries on HD, use a remote host, to get them > > all we need is .text,.data, and .bss , and stack /heap preferred addresses > (if we are talking about elf format) This can be done today making the shared library available using NFS. Of course, there are downsides about making shared libraries via a remote host, regardless of the details of how this is done: * You have to trust the remote host to send you a legitimate shared library; if the instructions in the shared library are modified by a remote attacker, they can control what is run on the local host, resulting in a potential trojan horse attack. * There is a potential performance impact if it is slower to access the remote host as compared to a local storage device (whether it is a HDD or a SSD). There are ways of mitigating some of these; for example, you could use an integrity protected network connection (which is supported by NFS, for example), or if you use a networked block device to mount a file system, you could use fsverity to make sure that a man-in-the-middle attacker can't modify the shared library blocks in transit. If the fsverity merkle tree is protected using public key signature (this is done to protect ChromeOS's root file system, so support of this is available today), this can also provide the necessary integrity protection. Cheers, - Ted