Hello Hauke, On Mon, 25 Mar 2019 18:31:19 +0100 Hauke Mehrtens <ha...@hauke-m.de> wrote:
> > This "hash tree" is a bunch of metadata that needs to be stored on > > non-volatile storage. It can be appended to the filesystem data, or > > stored on a separate block device/partition. We have chosen to support > > only the case where it is appended to the filesystem data. > > This sounds interesting, from a community perspective I do not like > secure boot, because it makes it harder to hack the devices, but I know > that many vendors are interested in this. Indeed. That being said, dm-verity per-se is not sufficient to achieve security: the root hash needs to come from a trusted source, i.e typically a signed kernel image. But I agree overall dm-verity is part of a plan to lock down devices. > > - The seventh patch adds the code itself that generates the dm-verity > > capable squashfs image, and a script that produces the U-Boot > > script with the various parameters needed to setup the DM device at > > boot time. > > How do you handle the overlay filesystem? An attacker could place there > some new binaries which would just replace the original ones. At the moment, I have a hacky patch on fstools that simply disables mounting an overlay filesystem entirely, i.e the system is completely read-only. I am not sure yet how to turn this into a clean solution that can be accepted upstream: fstools is currently doing all its overlay logic in a very automated way, with not much configuration to adjust its behavior. I was thinking of adding a kernel argument like openwrt.overlayfs={none,ram,default} to be able to force a certain behavior with the overlay, but I'm open to suggestions. > > - The eighth patch adds two kernel patches that allow setting up a DM > > device at boot time. In the upstream kernel, setting up a DM device > > requires userspace tools and therefore an initramfs, which is > > unpractical. Those two patches have been submitted numerous times > > by folks from Google and Redhat, but have remained out of tree so > > far. > > We know this problem in that area. ;-) As I replied to your review on patch 08/11, the 5.1 kernel will have support for setting up DM devices on the kernel command line, it has been merged upstream. > There are some kernel patches (?) which detect how big the squashfs > filesystem is and then create an extra partition there. You should > probably make this detection aware of dm-verify. It's actually user-space code in fstools that does this, at least for the MMC case. It looks at the squashfs filesystem size, and then creates a loop device that starts right after the squashfs filesystem, and uses it as a f2fs filesystem to store the overlay information. As explained above, I've worked-around this stuff for now with a hacky patch in fstools to completely disable setting up an overlayfs. Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel