On 5/10/19 6:49 AM, Mimi Zohar wrote: > On Fri, 2019-05-10 at 08:56 +0200, Roberto Sassu wrote: >> On 5/9/2019 8:34 PM, Rob Landley wrote: >>> On 5/9/19 6:24 AM, Roberto Sassu wrote: > >>>> The difference with another proposal >>>> (https://lore.kernel.org/patchwork/cover/888071/) is that xattrs can be >>>> included in an image without changing the image format, as opposed to >>>> defining a new one. As seen from the discussion, if a new format has to be >>>> defined, it should fix the issues of the existing format, which requires >>>> more time. >>> >>> So you've explicitly chosen _not_ to address Y2038 while you're there. >> >> Can you be more specific? > > Right, this patch set avoids incrementing the CPIO magic number and > the resulting changes required (eg. increasing the timestamp field > size), by including a file with the security xattrs in the CPIO. In > either case, including the security xattrs in the initramfs header or > as a separate file, the initramfs, itself, needs to be signed. The /init binary in the initramfs runs as root and launches all other processes on the system. Presumably it can write any xattrs it wants to, and doesn't need any extra permissions granted to it to do so. But as soon as you start putting xattrs on _other_ files within the initramfs that are _not_ necessarily running as PID 1, _that's_ when the need to sign the initramfs comes in? Presumably the signing occurs on the gzipped file. How does that affect the cpio parsing _after_ it's decompressed? Why would that be part of _this_ patch? Rob
