Received: by 10.223.176.5 with SMTP id f5csp2048189wra; Wed, 31 Jan 2018 15:56:45 -0800 (PST) X-Google-Smtp-Source: AH8x225vNaMrRaa0b5s1zJLvwJ8orGfM8c+IADEchG/2zBjj/bzKmEdsU7xyq7LvpoeSsKJZxuUv X-Received: by 2002:a17:902:2843:: with SMTP id e61-v6mr28148612plb.260.1517443005360; Wed, 31 Jan 2018 15:56:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517443005; cv=none; d=google.com; s=arc-20160816; b=t1XtORtu/IMYRxtH3ERN+6IHS2ZGXuel8Wc4mI6dXZlnlDdqh/ecAZSFywu3NVlB8D AEu5fTDGieWaJcRAc8M9PhOJEauSSLqzNIL5goJY3ZTz3CFtHHJ/xxZozb4/HQ2G3qoS TY8v9WUkazW5oKHmhc09xctftR+B3ggVZouIZ0NQXfF4U2LahgQ6S3IPXQ/wx1KoXMKW YyI3JTltZzK/5mBsrN/ajh31Zs+FdncjeGJwTwDdaH7s/wWUGgiq8pUZunNyCJfzkG58 glcaKPp333wJcGN1LNX9X3jTuMiChFuqKdCgECOCH1zgLV7bzCaNUoqChII8dEb6Cl58 qczQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=zuCTEB8VDrY7Eu5egogxy24JdM/bqXUOd9HXpl8lB1I=; b=AmCkZmvkgovdjjyq2Nm59gKYC6wpD9tcMPkYeoUn6LQKDJhetjk1NXf6F4hxa5xd89 g/Ko3yTXr+B6wbE943zBVN9qhOLtJrOQDSq2x1IBB+smP0bUFoWAu00ATont2kHEmk+x oQoTFqyGPkzH4WqpCdjB7Azk2tsJfCMISXVEx2fwqzWHPahXU4U3Tz0sI703+2C/U6xJ e08L3fE5G+v26Xrhr9umHs0r//feIS4rjFlPtvQfv81+m3Ed7zS1V/ZuUZSoOiLcf/kX PoE8xbMU3YjXUR/cgqJC8uPXUQyxtsCP4BgXjsPIqHHpuQ/MMEgKoHusw9P6uF9CldJB ak1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@landley-net.20150623.gappssmtp.com header.s=20150623 header.b=AFTxScLn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m13si542580pgp.542.2018.01.31.15.56.30; Wed, 31 Jan 2018 15:56:45 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@landley-net.20150623.gappssmtp.com header.s=20150623 header.b=AFTxScLn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753977AbeAaXs0 (ORCPT + 99 others); Wed, 31 Jan 2018 18:48:26 -0500 Received: from mail-ua0-f196.google.com ([209.85.217.196]:46759 "EHLO mail-ua0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753481AbeAaXsY (ORCPT ); Wed, 31 Jan 2018 18:48:24 -0500 Received: by mail-ua0-f196.google.com with SMTP id j23so10650122uak.13 for ; Wed, 31 Jan 2018 15:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=landley-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zuCTEB8VDrY7Eu5egogxy24JdM/bqXUOd9HXpl8lB1I=; b=AFTxScLnph4M+cfAqNZdjHYFWkVP2fxzghm/6izf5pcDOjrgETkQusGvKgFpgngcU0 NH0hKU4jhhGdcUsFFtjm1bx8Negn8HfNMysRM+WmHUhseG6uOL+pXnXMo4vJxqYJdevO kHEq4gYZJlOb5Vb/KveUlRwRAr8VgUklKqLD5w1YvtR5Ibl+ioEEhTJ/xkJQPSdqUSko TaAcjJkutaIZop89wxcTu4MJ9VFv0MvZYqvpNDbRjm+R7e7hq8zKR7ox+f3kXPdkMyow 4iUc2rxJFwpMNHG+GrwORF6P5CJpPlEPaoBiy/nQDqTNYAtP9JYi5QnX4LI7aVu/bI6M I+9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zuCTEB8VDrY7Eu5egogxy24JdM/bqXUOd9HXpl8lB1I=; b=YnovYANxESR06lI/3kJ98354USbHqR8SqdoL2TNX2KOBQHoSoq2ruTt/gg+xn0dE1b ZCJ+Ly/SlVrFHKmiylWL97D/26PYj+O3Dd9dkNQy4iWysvKcuKnX7VDEZxPtVywMKGgf hRb97PPuTBVagHBh2+FT8KQKeF3SU9wjFNZkgwSZm3E23d7/4t2BqRpRsttKrgDYf3XG L40qhy54yrs9m2pQDkWbuGobqMweit+4YCRjCTCQFygvKxBPq15mhKkKFrfpcu468wmu XZBcx0NpBw5DMknFODc7sykycTwjYe4b1Nnf8DsE0YIBGBdrH9vQfx2iioeF723fu6Ea p5uw== X-Gm-Message-State: AKwxytdDRlHBkVVlfiTGQl6Scd21U0VFLCn4Uv+1DuoFOjVA3ix+/iJV 8iZQIifmr3N2DUDlhs+Qry09Fr09rQA= X-Received: by 10.176.22.111 with SMTP id l44mr28107133uae.189.1517442503094; Wed, 31 Jan 2018 15:48:23 -0800 (PST) Received: from [192.168.42.117] ([172.58.120.98]) by smtp.googlemail.com with ESMTPSA id y58sm9551906uay.27.2018.01.31.15.48.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jan 2018 15:48:22 -0800 (PST) Subject: Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs To: Mimi Zohar , initramfs Cc: Taras Kondratiuk , Victor Kamensky , linux-security-module , Al Viro , linux-kernel References: <1517348777.3469.5.camel@linux.vnet.ibm.com> <1814af5c-170d-39c0-58fd-02eb7216e008@landley.net> <1517436423.3469.237.camel@linux.vnet.ibm.com> From: Rob Landley Message-ID: Date: Wed, 31 Jan 2018 17:48:20 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1517436423.3469.237.camel@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/31/2018 04:07 PM, Mimi Zohar wrote: > On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that rootfs >> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does >> it?) > > I must be missing something.  Which systems don't specify "root=" on > the boot command line. Any system using initrd or initramfs? I have one at https://github.com/landley/mkroot that doesn't, for example. It's 600 lines of bash that builds simple Linux systems for a bunch of different architectures, each with a qemu wrapper to boot it to a shell prompt. And yes, it's using tmpfs for its initramfs, you can tell because "grep rootfs /proc/mounts" gives a size. That's also where I tested the patch I sent you. The root= option specifies the filesystem to mount OVER rootfs. I.E. it's the fallback root filesystem to mount when initramfs doesn't contain an executable /init that can become PID 1. If you DO have an /init in rootfs which the kernel manages to launch as PID 1, the kernel code never reaches the part that uses the root= argument. (Look for the call to prepare_namespace() in init/main.c, notice how it's only called if it can't _already_ find "/init".) That's why the test I added for initramfs vs initmpfs was "did they specify root=", because if they did it means they're telling the kernel what to mount over rootfs, so they're not staying in rootfs. That's what that argument MEANS. They're telling init/main.c what fallback filesystem to mount over rootfs _after_ failing to find /init in rootfs, therefore they're not keeping rootfs as their root filesystem for userspace. That said, a lot of people don't understand how this works, and they set root= to things like /dev/ram when using initrd because "we must set this knob to something, this is something, therefore we must set this knob to it". The fact setting root=/dev/random would have the exact same effect doesn't seem to bother them, they had Done It and It Worked, therefore it was the Right Thing To Do. QED. The patch last message was me going "alright, if people can't NOT twiddle the knob, even when doing it breaks things in an immediate and obvious way, and a big DO NOT TOUCH sign won't dissuade them, just give the knob an explicit 'off' setting that literally does the same thing as not touching it at all would". Your solution was to add a safety catch for the knob, which is edging into Rube Goldberg territory if you ask me. > If we want to include and restore xattrs, > there needs to be a way of using tmpfs. Yes, using tmpfs for initramfs is useful, that's why I submitted patches to hook it up back in 2013. (Personally I find "cat /dev/zero > /filename" _not_ hard locking your system instantly the most compelling feature. Although I believe what motivated my initmpfs patches way back when was somebody wanting to install an rpm into intramfs and the installer failing because ramfs hasn't got a size so "df" always returns zero.) > Mimi Rob