From: Kees Cook <keescook@chromium.org> To: Mike Snitzer <snitzer@redhat.com> Cc: Richard Weinberger <richard.weinberger@gmail.com>, helen.koike@collabora.com, device-mapper development <dm-devel@redhat.com>, Alasdair G Kergon <agk@redhat.com>, LKML <linux-kernel@vger.kernel.org>, Enric Balletbo i Serra <enric.balletbo@collabora.com>, Will Drewry <wad@chromium.org>, "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>, linux-lvm@redhat.com, kernel@collabora.com Subject: Re: [PATCH 0/2] boot to a mapped device Date: Thu, 27 Sep 2018 09:36:23 -0700 [thread overview] Message-ID: <CAGXu5j+Y5e_oTZVCAHa48XgVcvEKGnVW_74oXZOUyLnfYPAjAg@mail.gmail.com> (raw) In-Reply-To: <20180927142328.GA4074@redhat.com> On Thu, Sep 27, 2018 at 7:23 AM, Mike Snitzer <snitzer@redhat.com> wrote: > On Wed, Sep 26 2018 at 3:16am -0400, > Richard Weinberger <richard.weinberger@gmail.com> wrote: > >> Helen, >> >> On Wed, Sep 26, 2018 at 7:01 AM Helen Koike <helen.koike@collabora.com> wrote: >> > >> > This series is reviving an old patchwork. >> > Booting from a mapped device requires an initramfs. This series is >> > allows for device-mapper targets to be configured at boot time for >> > use early in the boot process (as the root device or otherwise). >> >> What is the reason for this patch series? >> Setting up non-trivial root filesystems/storage always requires an >> initramfs, there is nothing >> wrong about this. > > Exactly. If phones or whatever would benefit from this patchset then > say as much. I think some of the context for the series was lost in commit logs, but yes, both Android and Chrome OS do not use initramfs. The only thing that was needed to do this was being able to configure dm devices on the kernel command line, so the overhead of a full initramfs was seen as a boot time liability, a boot image size liability (e.g. Chrome OS has a limited amount of storage available for the boot image that is covered by the static root of trust signature), and a complexity risk: everything that is needed for boot could be specified on the kernel command line, so better to avoid the whole initramfs dance. So, instead, this plumbs the dm commands directly instead of bringing up a full userspace and performing ioctls. > I will not accept this patchset at this time. > >> > Example, the following could be added in the boot parameters. >> > dm="lroot,,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" root=/dev/dm-0 >> >> Hmmm, the new dm= parameter is anything but easy to get right. > > No, it isn't.. exposes way too much potential for users hanging > themselves. IIRC, the changes in syntax were suggested back when I was trying to drive this series: https://www.redhat.com/archives/dm-devel/2016-February/msg00199.html And it matches the "concise" format in dmsetup: https://sourceware.org/git/?p=lvm2.git;a=commit;h=827be01758ec5adb7b9d5ea75b658092adc65534 What do you feel are next steps? Thanks! -Kees -- Kees Cook Pixel Security
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org> To: Mike Snitzer <snitzer@redhat.com> Cc: Will Drewry <wad@chromium.org>, "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>, Richard Weinberger <richard.weinberger@gmail.com>, device-mapper development <dm-devel@redhat.com>, LKML <linux-kernel@vger.kernel.org>, helen.koike@collabora.com, linux-lvm@redhat.com, Enric Balletbo i Serra <enric.balletbo@collabora.com>, kernel@collabora.com, Alasdair G Kergon <agk@redhat.com> Subject: Re: [linux-lvm] [PATCH 0/2] boot to a mapped device Date: Thu, 27 Sep 2018 09:36:23 -0700 [thread overview] Message-ID: <CAGXu5j+Y5e_oTZVCAHa48XgVcvEKGnVW_74oXZOUyLnfYPAjAg@mail.gmail.com> (raw) In-Reply-To: <20180927142328.GA4074@redhat.com> On Thu, Sep 27, 2018 at 7:23 AM, Mike Snitzer <snitzer@redhat.com> wrote: > On Wed, Sep 26 2018 at 3:16am -0400, > Richard Weinberger <richard.weinberger@gmail.com> wrote: > >> Helen, >> >> On Wed, Sep 26, 2018 at 7:01 AM Helen Koike <helen.koike@collabora.com> wrote: >> > >> > This series is reviving an old patchwork. >> > Booting from a mapped device requires an initramfs. This series is >> > allows for device-mapper targets to be configured at boot time for >> > use early in the boot process (as the root device or otherwise). >> >> What is the reason for this patch series? >> Setting up non-trivial root filesystems/storage always requires an >> initramfs, there is nothing >> wrong about this. > > Exactly. If phones or whatever would benefit from this patchset then > say as much. I think some of the context for the series was lost in commit logs, but yes, both Android and Chrome OS do not use initramfs. The only thing that was needed to do this was being able to configure dm devices on the kernel command line, so the overhead of a full initramfs was seen as a boot time liability, a boot image size liability (e.g. Chrome OS has a limited amount of storage available for the boot image that is covered by the static root of trust signature), and a complexity risk: everything that is needed for boot could be specified on the kernel command line, so better to avoid the whole initramfs dance. So, instead, this plumbs the dm commands directly instead of bringing up a full userspace and performing ioctls. > I will not accept this patchset at this time. > >> > Example, the following could be added in the boot parameters. >> > dm="lroot,,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" root=/dev/dm-0 >> >> Hmmm, the new dm= parameter is anything but easy to get right. > > No, it isn't.. exposes way too much potential for users hanging > themselves. IIRC, the changes in syntax were suggested back when I was trying to drive this series: https://www.redhat.com/archives/dm-devel/2016-February/msg00199.html And it matches the "concise" format in dmsetup: https://sourceware.org/git/?p=lvm2.git;a=commit;h=827be01758ec5adb7b9d5ea75b658092adc65534 What do you feel are next steps? Thanks! -Kees -- Kees Cook Pixel Security
next prev parent reply other threads:[~2018-09-27 16:36 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-26 4:45 [PATCH 0/2] boot to a mapped device Helen Koike 2018-09-26 5:00 ` [linux-lvm] " Helen Koike 2018-09-26 5:00 ` Helen Koike 2018-09-26 4:45 ` [PATCH 1/2] dm ioctl: add a device mapper ioctl function Helen Koike 2018-09-26 5:00 ` [linux-lvm] " Helen Koike 2018-09-26 5:00 ` Helen Koike 2018-09-26 4:45 ` [PATCH 2/2] init: add support to directly boot to a mapped device Helen Koike 2018-09-26 5:00 ` [linux-lvm] " Helen Koike 2018-09-26 5:00 ` Helen Koike 2018-09-26 16:09 ` Randy Dunlap 2018-09-26 16:09 ` [linux-lvm] " Randy Dunlap 2018-09-26 5:02 ` [PATCH 0/2] " Helen Koike 2018-09-26 5:02 ` [linux-lvm] " Helen Koike 2018-09-26 7:16 ` Richard Weinberger 2018-09-26 7:16 ` [linux-lvm] " Richard Weinberger 2018-09-27 14:23 ` Mike Snitzer 2018-09-27 14:23 ` [linux-lvm] " Mike Snitzer 2018-09-27 16:36 ` Kees Cook [this message] 2018-09-27 16:36 ` Kees Cook 2018-09-27 18:31 ` Mike Snitzer 2018-09-27 18:31 ` [linux-lvm] " Mike Snitzer 2018-10-19 16:27 ` Helen Koike 2018-10-19 16:27 ` [linux-lvm] " Helen Koike
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAGXu5j+Y5e_oTZVCAHa48XgVcvEKGnVW_74oXZOUyLnfYPAjAg@mail.gmail.com \ --to=keescook@chromium.org \ --cc=agk@redhat.com \ --cc=dm-devel@redhat.com \ --cc=enric.balletbo@collabora.com \ --cc=helen.koike@collabora.com \ --cc=kernel@collabora.com \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-lvm@redhat.com \ --cc=richard.weinberger@gmail.com \ --cc=snitzer@redhat.com \ --cc=wad@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.