[OpenWrt-Devel] [PATCH 00/11] Proposal for dm-verity support

[Thomas Petazzoni]

Hello Hauke,

On Mon, 25 Mar 2019 18:31:19 +0100
Hauke Mehrtens <hauke at 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 at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel