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

[Hauke Mehrtens]

Hi Thomas,

On 3/25/19 7:07 PM, Thomas Petazzoni wrote:
> 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.

Using some boot arguments sounds like a good solution, but I am not an
expert on the file system handling. The default has to be the current
behavior, because we do not have control over all boot loaders, I assume
that people who need this special behavior have control over their boot
loader.

Do you know if it is possible to support dm-verify also for the overlay
file system?

>>>  - 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.

It would be nice if you could backport the upstream version to kernel
4.14 and 4.19, you do not have to care about the old kernels, when we
move to the next LTS kernel we can just remove the patches.

>> 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
> 

Hauke


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel