subject:"Re\: \[RFC\]\[PATCH 6\/9\] gen_initramfs

On 01/13/2015 09:23 PM, Mimi Zohar wrote:
> On Tue, 2015-01-13 at 15:42 -0600, Rob Landley wrote: 
>>> 4 bytes enough?
> 
>> Eh, as long as we're breaking compatibility anyway, we might as well
>> extend the file size. It's gzipped so the extra run of consecutive
>> zeroes isn't really an issue, and if tmpfs is going to support 64 bit
>> file sizes the thing that's populating them should to just to match.
>> (You can already have memory bigger than 4g. Some crazy person is going
>> to put a squashfs in tmpfs and loopback mount it, or have a giant video
>> there, or... Bootloaders being able to cope with this is not my problem. :)
> 
>> Probably having the new fields at the end (and gluing them to the
>> earlier ones) makes more sense than having variable sized fields? I
>> don't have a strong opinion either way.
> 
> The current file data size header field is a 8 character hexidecimal
> string, which is long enough to store 4g (0x).

The current header fields are all 32 bits, yes. To get a 64 bit field
we'd have to add a second 32 bit field and add it <<32 to the original
one, or else have the header fields be of varying sizes. That was the
"adding a new one to the end" thing mentioned above.

Then again if we add a new field right before the previous size then the
"treat it as 64 bits vs 2 32 bit ones" is an implementation detail
anyway. And for the moment we can just have it be padding that
compresses away and wait for an actual >4g file.

Unless you think nobody will ever need an archive member >4g in
initramfs, even though servers with ~256g are reasonably common today
already?

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

On Tue, 2015-01-13 at 15:42 -0600, Rob Landley wrote: 
> 
> On 01/13/2015 02:20 PM, Mimi Zohar wrote:
> > On Tue, 2015-01-13 at 12:48 -0600, Rob Landley wrote: 
> >> I note that there are two data formats of interest here:
> >>
> >> 1) the cpio file layout.
> >>
> >> 2) the list of files generated by gen_initramfs_list.sh and consumed by
> >> gen_init_cpio.
> >>
> >> The fact you're modifying gen_initramfs_list.sh seems to imply that
> >> you're changing the _second_ format as well as the first...? The second
> >> was never actually specified, but it does get used a lot by various
> >> build systems and breaking it would inconvenience people. (Plus I'd need
> >> to update the documentation, but I need to do that anyway.)
> > 
> > Patch "[PATCH 6/9] gen_initramfs_list.sh: include xattrs" is a one line
> > change that adds the "-x" option to include xattrs in the initramfs, if
> > they exist.
> 
> Unconditionally. Even if we've configured xattr support out of our
> kernel or tmpfs?
> 
> > This patch makes the new method (070703) the default format.
> 
> So nobody should ever try to build an embedded system (without xattrs)
> from something like Red Hat Enterprise (where they just magically show up)?

Good point.  I'll address this in the next post.

> >> Ss long as you're extending the format could you add a second 32 bits of
> >> time data that gets glued to the top half of a uint64_t, and then store
> >> the actual time value in microseconds (so time*100)? (I'd say
> >> "nanoseconds" but 63 bits of nanoseconds is 292 years, which is just
> >> short enough I'm uncomfortable with it. I'm just optimistic enough to
> >> think that might inconvenience somebody.)
> >>
> >> The other "huh" is the filesize, but 4 gigs per file seems unlikely to
> >> be more than initramfs needs any time soon? (It's possible that RPM
> >> might care in 15 years or so...)
> > 
> > 4 bytes enough?

> Eh, as long as we're breaking compatibility anyway, we might as well
> extend the file size. It's gzipped so the extra run of consecutive
> zeroes isn't really an issue, and if tmpfs is going to support 64 bit
> file sizes the thing that's populating them should to just to match.
> (You can already have memory bigger than 4g. Some crazy person is going
> to put a squashfs in tmpfs and loopback mount it, or have a giant video
> there, or... Bootloaders being able to cope with this is not my problem. :)

> Probably having the new fields at the end (and gluing them to the
> earlier ones) makes more sense than having variable sized fields? I
> don't have a strong opinion either way.

The current file data size header field is a 8 character hexidecimal
string, which is long enough to store 4g (0x).

> >> I have no idea what sys_setxattr() accepts, but
> >> presumably there's a man page for the system call...
> >>
> >>   http://man7.org/linux/man-pages/man2/setxattr.2.html
> >>
> >> Ok, that's probably enough data to implement it. (Not sure why that man
> >> page isn't in my ubuntu 14.04 install which has manpages-dev installed?
> >>
> >>   $ man setxattr
> >>   No manual entry for setxattr
> >>
> >>> Note that gen_init_cpio does not include "security.evm" as it is file
> >>> system dependent.
> >>
> >> I have no idea what that is. Should I not include it in the command line
> >> cpio? (Or have a flag?)
> > 
> > Right, don't include "security.evm".  Both the HMAC and signature format
> > include the inode number, which is filesystem specific.
> 
> So save extended attributes but filter out this one magic extended
> attribute that we _shouldn't_ save because we know, a priori, that this
> data is not portable.
> 
> I'm remembering why I didn't want to get this on me.
> 
> >> The last time I used extended attributes was on OS/2; my only
> >> non-academic interaction with selinux has been looking up how to switch
> >> it off.
> >>
> >> I still boggle that Fortune 500 bureaucracies include "must have a
> >> security system designed by the NSA based on the idea of complicating
> >> the system until there are no obvious holes, because after the Snowden
> >> leaks that's clearly a good idea" as part of their certification
> >> processes for reducing the risk of being unable to delegate blame.
> > 
> > I'm the linux-integrity subsystem maintainer, not an LSM maintainer (not
> > that there is anything wrong in being an LSM maintainer).  So, I'm not
> > quite sure why you keep saying things like this to me. BTW, there are
> > a number of LSMs these days, not only SELinux.
> 
> Yes, and I can't keep 'em straight. The android guys are adding SELinux:
> 
> https://android.googlesource.com/platform/external/toybox/+/d5c66a9fd36777f80ba05301dcfa6789b103e486
> 
> The Tizen guys are adding something called "smack":
> https://git.tizen.org/cgit/platform/upstream/toybox.git
> 
> Up until about 3 months ago I had successfully avoided all of this. Oh
> well, always something new to learn...
> 
> Do each of them have their own rules about what extended

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

On 01/13/2015 02:20 PM, Mimi Zohar wrote:
> On Tue, 2015-01-13 at 12:48 -0600, Rob Landley wrote: 
>> I note that there are two data formats of interest here:
>>
>> 1) the cpio file layout.
>>
>> 2) the list of files generated by gen_initramfs_list.sh and consumed by
>> gen_init_cpio.
>>
>> The fact you're modifying gen_initramfs_list.sh seems to imply that
>> you're changing the _second_ format as well as the first...? The second
>> was never actually specified, but it does get used a lot by various
>> build systems and breaking it would inconvenience people. (Plus I'd need
>> to update the documentation, but I need to do that anyway.)
> 
> Patch "[PATCH 6/9] gen_initramfs_list.sh: include xattrs" is a one line
> change that adds the "-x" option to include xattrs in the initramfs, if
> they exist.

Unconditionally. Even if we've configured xattr support out of our
kernel or tmpfs?

> This patch makes the new method (070703) the default format.

So nobody should ever try to build an embedded system (without xattrs)
from something like Red Hat Enterprise (where they just magically show up)?

>> Ss long as you're extending the format could you add a second 32 bits of
>> time data that gets glued to the top half of a uint64_t, and then store
>> the actual time value in microseconds (so time*100)? (I'd say
>> "nanoseconds" but 63 bits of nanoseconds is 292 years, which is just
>> short enough I'm uncomfortable with it. I'm just optimistic enough to
>> think that might inconvenience somebody.)
>>
>> The other "huh" is the filesize, but 4 gigs per file seems unlikely to
>> be more than initramfs needs any time soon? (It's possible that RPM
>> might care in 15 years or so...)
> 
> 4 bytes enough?

Eh, as long as we're breaking compatibility anyway, we might as well
extend the file size. It's gzipped so the extra run of consecutive
zeroes isn't really an issue, and if tmpfs is going to support 64 bit
file sizes the thing that's populating them should to just to match.
(You can already have memory bigger than 4g. Some crazy person is going
to put a squashfs in tmpfs and loopback mount it, or have a giant video
there, or... Bootloaders being able to cope with this is not my problem. :)

Probably having the new fields at the end (and gluing them to the
earlier ones) makes more sense than having variable sized fields? I
don't have a strong opinion either way.

>> I have no idea what sys_setxattr() accepts, but
>> presumably there's a man page for the system call...
>>
>>   http://man7.org/linux/man-pages/man2/setxattr.2.html
>>
>> Ok, that's probably enough data to implement it. (Not sure why that man
>> page isn't in my ubuntu 14.04 install which has manpages-dev installed?
>>
>>   $ man setxattr
>>   No manual entry for setxattr
>>
>>> Note that gen_init_cpio does not include "security.evm" as it is file
>>> system dependent.
>>
>> I have no idea what that is. Should I not include it in the command line
>> cpio? (Or have a flag?)
> 
> Right, don't include "security.evm".  Both the HMAC and signature format
> include the inode number, which is filesystem specific.

So save extended attributes but filter out this one magic extended
attribute that we _shouldn't_ save because we know, a priori, that this
data is not portable.

I'm remembering why I didn't want to get this on me.

>> The last time I used extended attributes was on OS/2; my only
>> non-academic interaction with selinux has been looking up how to switch
>> it off.
>>
>> I still boggle that Fortune 500 bureaucracies include "must have a
>> security system designed by the NSA based on the idea of complicating
>> the system until there are no obvious holes, because after the Snowden
>> leaks that's clearly a good idea" as part of their certification
>> processes for reducing the risk of being unable to delegate blame.
> 
> I'm the linux-integrity subsystem maintainer, not an LSM maintainer (not
> that there is anything wrong in being an LSM maintainer).  So, I'm not
> quite sure why you keep saying things like this to me. BTW, there are
> a number of LSMs these days, not only SELinux.

Yes, and I can't keep 'em straight. The android guys are adding SELinux:

https://android.googlesource.com/platform/external/toybox/+/d5c66a9fd36777f80ba05301dcfa6789b103e486

The Tizen guys are adding something called "smack":
https://git.tizen.org/cgit/platform/upstream/toybox.git

Up until about 3 months ago I had successfully avoided all of this. Oh
well, always something new to learn...

Do each of them have their own rules about what extended attribute data
is not portable and should be filtered out? Or is this one magic entry
it? (I'd RTFM but http://man7.org/linux/man-pages/man5/attr.5.html does
not contain the string "evm".)

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

On Tue, 2015-01-13 at 12:48 -0600, Rob Landley wrote: 
> On 01/08/2015 04:08 PM, Mimi Zohar wrote:
> > On Thu, 2015-01-08 at 12:19 -0600, Rob Landley wrote:
> >>
> >> But I am curious about how you propose to encode xattrs into the cpio
> >> format. (Which Al Viro chose because it's _simple_. There isn't really
> >> a
> >> controlling spec since Posix decided to deprecated it in 2001 and
> >> yank
> >> it from SUSv3 onwards. LSB extended several header fields to 8 hex
> >> digits instead of 6, but they still have 32 bit timestamps which seems
> >> a
> >> bit short-sighted. If you're going to define a new rev with a new
> >> magic
> >> number, there are a couple other things you might wanna fix...)
> > 
> > Sounds like a good opportunity to make the other changes as well.  We
> > can include the other changes in this patch set.  Is this (initramfs)
> > the right mailing list for this discussion?
> 
> I'd forgotten there was such a list until the email came in. :)
> 
> > Do other people need to be included?
> 
> In theory including the Austin Group (the posix committee mailing list)
> might be useful, but in practice they hear about stuff well after the
> fact, and they washed their hands of cpio over a decade ago (shortly
> after Linux started heavily using it in rpm, and a bit before initramfs).
> 
> I note that there are two data formats of interest here:
> 
> 1) the cpio file layout.
> 
> 2) the list of files generated by gen_initramfs_list.sh and consumed by
> gen_init_cpio.
> 
> The fact you're modifying gen_initramfs_list.sh seems to imply that
> you're changing the _second_ format as well as the first...? The second
> was never actually specified, but it does get used a lot by various
> build systems and breaking it would inconvenience people. (Plus I'd need
> to update the documentation, but I need to do that anyway.)

Patch "[PATCH 6/9] gen_initramfs_list.sh: include xattrs" is a one line
change that adds the "-x" option to include xattrs in the initramfs, if
they exist. This patch makes the new method (070703) the default format.

> Ss long as you're extending the format could you add a second 32 bits of
> time data that gets glued to the top half of a uint64_t, and then store
> the actual time value in microseconds (so time*100)? (I'd say
> "nanoseconds" but 63 bits of nanoseconds is 292 years, which is just
> short enough I'm uncomfortable with it. I'm just optimistic enough to
> think that might inconvenience somebody.)
> 
> The other "huh" is the filesize, but 4 gigs per file seems unlikely to
> be more than initramfs needs any time soon? (It's possible that RPM
> might care in 15 years or so...)

4 bytes enough?

> >> I ask because I maintain a new from-scratch cpio implementation
> >> (http://landley.net/hg/toybox/file/1571/toys/posix/cpio.c), so I'd
> >> presumably have to add your format extensions to this. Is there any
> >> sort
> >> of documentation on them?
> >>
> >> The toybox config Android is using has this cpio implementation
> >> enabled
> >> (see
> >> https://android.googlesource.com/platform/external/toybox/+/9250c95a8c47/Android.mk)
> >> so I'd rather like to get this sort of detail right...
> > 
> > The xattr section, which follows the file name, is of the format:
> >  {} for
> > each xattr, terminated with a NULL byte and padded to a 4 byte boundary.
> 
> where  is...  8 bytes of ascii hex digits like the header values?
> (Every cpio string is padded to a boundary. Sigh, lemme go read your
> patch...)
> 
> Ok, 2/9, actual file format parsing. New magic string at the start
> "070703" for the new version. (Good, that was my first question: easy
> way to distinguish this from the previous format).
> 
> - for (i = 0, s += 6; i < 12; i++, s += 8) {
> + for (i = 0; i < (!newcx ? 12 : 13); i++, s += 8) {
> 
> You've tested this and the missing s+= 6 didn't cause problems? (Or did
> it move somewhere else...? Is that what the 1/9 did grabbing just the
> magic instead of the rest of the header data...?)

Right, the first patch separates reading the magic string from reading
the rest of the header.

> > The header contains an additional field, before the checksum, containing
> > the xattr section length, including the NULL byte, but without the
> > padding.
> 
> Ah, the old "4 bytes of padding to align to 4 bytes" silliness. (Even
> though you can't trust the null to _be_ there and have to set it
> yourself after the read.) I'm starting to remember this...
> 
> Ok, different header magic, one new 8 hex digit field at the end of the
> header (before crc) containing "xattr_bufflen". The start of this buffer
> is an 8 digit hex "num_xattrs", which you iterate through and call
> strlen() on despite never having assured that the data you read in
> actually _does_ contain a null at the end (of the entire buffer). Then
> past that supposed null is another 8 digit hex "xattr_value_size", and
> that many bytes following you then send to sys_setxattr().
> 
> Except for the part

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

On 01/08/2015 04:08 PM, Mimi Zohar wrote:
> On Thu, 2015-01-08 at 12:19 -0600, Rob Landley wrote:
>>
>> But I am curious about how you propose to encode xattrs into the cpio
>> format. (Which Al Viro chose because it's _simple_. There isn't really
>> a
>> controlling spec since Posix decided to deprecated it in 2001 and
>> yank
>> it from SUSv3 onwards. LSB extended several header fields to 8 hex
>> digits instead of 6, but they still have 32 bit timestamps which seems
>> a
>> bit short-sighted. If you're going to define a new rev with a new
>> magic
>> number, there are a couple other things you might wanna fix...)
> 
> Sounds like a good opportunity to make the other changes as well.  We
> can include the other changes in this patch set.  Is this (initramfs)
> the right mailing list for this discussion?

I'd forgotten there was such a list until the email came in. :)

> Do other people need to be included?

In theory including the Austin Group (the posix committee mailing list)
might be useful, but in practice they hear about stuff well after the
fact, and they washed their hands of cpio over a decade ago (shortly
after Linux started heavily using it in rpm, and a bit before initramfs).

I note that there are two data formats of interest here:

1) the cpio file layout.

2) the list of files generated by gen_initramfs_list.sh and consumed by
gen_init_cpio.

The fact you're modifying gen_initramfs_list.sh seems to imply that
you're changing the _second_ format as well as the first...? The second
was never actually specified, but it does get used a lot by various
build systems and breaking it would inconvenience people. (Plus I'd need
to update the documentation, but I need to do that anyway.)

Ss long as you're extending the format could you add a second 32 bits of
time data that gets glued to the top half of a uint64_t, and then store
the actual time value in microseconds (so time*100)? (I'd say
"nanoseconds" but 63 bits of nanoseconds is 292 years, which is just
short enough I'm uncomfortable with it. I'm just optimistic enough to
think that might inconvenience somebody.)

The other "huh" is the filesize, but 4 gigs per file seems unlikely to
be more than initramfs needs any time soon? (It's possible that RPM
might care in 15 years or so...)

>> I ask because I maintain a new from-scratch cpio implementation
>> (http://landley.net/hg/toybox/file/1571/toys/posix/cpio.c), so I'd
>> presumably have to add your format extensions to this. Is there any
>> sort
>> of documentation on them?
>>
>> The toybox config Android is using has this cpio implementation
>> enabled
>> (see
>> https://android.googlesource.com/platform/external/toybox/+/9250c95a8c47/Android.mk)
>> so I'd rather like to get this sort of detail right...
> 
> The xattr section, which follows the file name, is of the format:
>  {} for
> each xattr, terminated with a NULL byte and padded to a 4 byte boundary.

where  is...  8 bytes of ascii hex digits like the header values?
(Every cpio string is padded to a boundary. Sigh, lemme go read your
patch...)

Ok, 2/9, actual file format parsing. New magic string at the start
"070703" for the new version. (Good, that was my first question: easy
way to distinguish this from the previous format).

-   for (i = 0, s += 6; i < 12; i++, s += 8) {
+   for (i = 0; i < (!newcx ? 12 : 13); i++, s += 8) {

You've tested this and the missing s+= 6 didn't cause problems? (Or did
it move somewhere else...? Is that what the 1/9 did grabbing just the
magic instead of the rest of the header data...?)

> The header contains an additional field, before the checksum, containing
> the xattr section length, including the NULL byte, but without the
> padding.

Ah, the old "4 bytes of padding to align to 4 bytes" silliness. (Even
though you can't trust the null to _be_ there and have to set it
yourself after the read.) I'm starting to remember this...

Ok, different header magic, one new 8 hex digit field at the end of the
header (before crc) containing "xattr_bufflen". The start of this buffer
is an 8 digit hex "num_xattrs", which you iterate through and call
strlen() on despite never having assured that the data you read in
actually _does_ contain a null at the end (of the entire buffer). Then
past that supposed null is another 8 digit hex "xattr_value_size", and
that many bytes following you then send to sys_setxattr().

Except for the part about you trusting your input data way too much,
seems reasonable? I have no idea what sys_setxattr() accepts, but
presumably there's a man page for the system call...

  http://man7.org/linux/man-pages/man2/setxattr.2.html

Ok, that's probably enough data to implement it. (Not sure why that man
page isn't in my ubuntu 14.04 install which has manpages-dev installed?

  $ man setxattr
  No manual entry for setxattr

> Note that gen_init_cpio does not include "security.evm" as it is file
> system dependent.

I have no idea what that is. Should I not include it in the

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

On Tue, 2015-01-13 at 15:42 -0600, Rob Landley wrote:

On 01/13/2015 02:20 PM, Mimi Zohar wrote:
On Tue, 2015-01-13 at 12:48 -0600, Rob Landley wrote:
I note that there are two data formats of interest here:

1) the cpio file layout.

2) the list of files generated by gen_initramfs_list.sh and consumed by
gen_init_cpio.

The fact you're modifying gen_initramfs_list.sh seems to imply that
you're changing the _second_ format as well as the first...? The second
was never actually specified, but it does get used a lot by various
build systems and breaking it would inconvenience people. (Plus I'd need
to update the documentation, but I need to do that anyway.)

Patch [PATCH 6/9] gen_initramfs_list.sh: include xattrs is a one line
change that adds the -x option to include xattrs in the initramfs, if
they exist.

Unconditionally. Even if we've configured xattr support out of our
kernel or tmpfs?

This patch makes the new method (070703) the default format.

So nobody should ever try to build an embedded system (without xattrs)
from something like Red Hat Enterprise (where they just magically show up)?

Good point. I'll address this in the next post.

Ss long as you're extending the format could you add a second 32 bits of
time data that gets glued to the top half of a uint64_t, and then store
the actual time value in microseconds (so time*100)? (I'd say
nanoseconds but 63 bits of nanoseconds is 292 years, which is just
short enough I'm uncomfortable with it. I'm just optimistic enough to
think that might inconvenience somebody.)

The other huh is the filesize, but 4 gigs per file seems unlikely to
be more than initramfs needs any time soon? (It's possible that RPM
might care in 15 years or so...)

4 bytes enough?

Eh, as long as we're breaking compatibility anyway, we might as well
extend the file size. It's gzipped so the extra run of consecutive
zeroes isn't really an issue, and if tmpfs is going to support 64 bit
file sizes the thing that's populating them should to just to match.
(You can already have memory bigger than 4g. Some crazy person is going
to put a squashfs in tmpfs and loopback mount it, or have a giant video
there, or... Bootloaders being able to cope with this is not my problem. :)

Probably having the new fields at the end (and gluing them to the
earlier ones) makes more sense than having variable sized fields? I
don't have a strong opinion either way.

The current file data size header field is a 8 character hexidecimal
string, which is long enough to store 4g (0x).

I have no idea what sys_setxattr() accepts, but
presumably there's a man page for the system call...

http://man7.org/linux/man-pages/man2/setxattr.2.html

Ok, that's probably enough data to implement it. (Not sure why that man
page isn't in my ubuntu 14.04 install which has manpages-dev installed?

$ man setxattr
No manual entry for setxattr

Note that gen_init_cpio does not include security.evm as it is file
system dependent.

I have no idea what that is. Should I not include it in the command line
cpio? (Or have a flag?)

Right, don't include security.evm. Both the HMAC and signature format
include the inode number, which is filesystem specific.

So save extended attributes but filter out this one magic extended
attribute that we _shouldn't_ save because we know, a priori, that this
data is not portable.

I'm remembering why I didn't want to get this on me.

The last time I used extended attributes was on OS/2; my only
non-academic interaction with selinux has been looking up how to switch
it off.

I still boggle that Fortune 500 bureaucracies include must have a
security system designed by the NSA based on the idea of complicating
the system until there are no obvious holes, because after the Snowden
leaks that's clearly a good idea as part of their certification
processes for reducing the risk of being unable to delegate blame.

I'm the linux-integrity subsystem maintainer, not an LSM maintainer (not
that there is anything wrong in being an LSM maintainer). So, I'm not
quite sure why you keep saying things like this to me. BTW, there are
a number of LSMs these days, not only SELinux.

Yes, and I can't keep 'em straight. The android guys are adding SELinux:

https://android.googlesource.com/platform/external/toybox/+/d5c66a9fd36777f80ba05301dcfa6789b103e486

The Tizen guys are adding something called smack:
https://git.tizen.org/cgit/platform/upstream/toybox.git

Up until about 3 months ago I had successfully avoided all of this. Oh
well, always something new to learn...

Do each of them have their own rules about what extended attribute data
is not portable and should be filtered out? Or is this one magic entry
it? (I'd RTFM but http://man7.org/linux/man-pages/man5/attr.5.html does
not contain the string evm.)

Rob

I would assume only

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs



On 01/13/2015 09:23 PM, Mimi Zohar wrote:
 On Tue, 2015-01-13 at 15:42 -0600, Rob Landley wrote: 
 4 bytes enough?
 
 Eh, as long as we're breaking compatibility anyway, we might as well
 extend the file size. It's gzipped so the extra run of consecutive
 zeroes isn't really an issue, and if tmpfs is going to support 64 bit
 file sizes the thing that's populating them should to just to match.
 (You can already have memory bigger than 4g. Some crazy person is going
 to put a squashfs in tmpfs and loopback mount it, or have a giant video
 there, or... Bootloaders being able to cope with this is not my problem. :)
 
 Probably having the new fields at the end (and gluing them to the
 earlier ones) makes more sense than having variable sized fields? I
 don't have a strong opinion either way.
 
 The current file data size header field is a 8 character hexidecimal
 string, which is long enough to store 4g (0x).

The current header fields are all 32 bits, yes. To get a 64 bit field
we'd have to add a second 32 bit field and add it 32 to the original
one, or else have the header fields be of varying sizes. That was the
adding a new one to the end thing mentioned above.

Then again if we add a new field right before the previous size then the
treat it as 64 bits vs 2 32 bit ones is an implementation detail
anyway. And for the moment we can just have it be padding that
compresses away and wait for an actual 4g file.

Unless you think nobody will ever need an archive member 4g in
initramfs, even though servers with ~256g are reasonably common today
already?

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

On 01/08/2015 04:08 PM, Mimi Zohar wrote:
 On Thu, 2015-01-08 at 12:19 -0600, Rob Landley wrote:

 But I am curious about how you propose to encode xattrs into the cpio
 format. (Which Al Viro chose because it's _simple_. There isn't really
 a
 controlling spec since Posix decided to deprecated it in 2001 and
 yank
 it from SUSv3 onwards. LSB extended several header fields to 8 hex
 digits instead of 6, but they still have 32 bit timestamps which seems
 a
 bit short-sighted. If you're going to define a new rev with a new
 magic
 number, there are a couple other things you might wanna fix...)
 
 Sounds like a good opportunity to make the other changes as well.  We
 can include the other changes in this patch set.  Is this (initramfs)
 the right mailing list for this discussion?

I'd forgotten there was such a list until the email came in. :)

 Do other people need to be included?

In theory including the Austin Group (the posix committee mailing list)
might be useful, but in practice they hear about stuff well after the
fact, and they washed their hands of cpio over a decade ago (shortly
after Linux started heavily using it in rpm, and a bit before initramfs).

I note that there are two data formats of interest here:

1) the cpio file layout.

2) the list of files generated by gen_initramfs_list.sh and consumed by
gen_init_cpio.

The fact you're modifying gen_initramfs_list.sh seems to imply that
you're changing the _second_ format as well as the first...? The second
was never actually specified, but it does get used a lot by various
build systems and breaking it would inconvenience people. (Plus I'd need
to update the documentation, but I need to do that anyway.)

Ss long as you're extending the format could you add a second 32 bits of
time data that gets glued to the top half of a uint64_t, and then store
the actual time value in microseconds (so time*100)? (I'd say
nanoseconds but 63 bits of nanoseconds is 292 years, which is just
short enough I'm uncomfortable with it. I'm just optimistic enough to
think that might inconvenience somebody.)

The other huh is the filesize, but 4 gigs per file seems unlikely to
be more than initramfs needs any time soon? (It's possible that RPM
might care in 15 years or so...)

 I ask because I maintain a new from-scratch cpio implementation
 (http://landley.net/hg/toybox/file/1571/toys/posix/cpio.c), so I'd
 presumably have to add your format extensions to this. Is there any
 sort
 of documentation on them?

 The toybox config Android is using has this cpio implementation
 enabled
 (see
 https://android.googlesource.com/platform/external/toybox/+/9250c95a8c47/Android.mk)
 so I'd rather like to get this sort of detail right...
 
 The xattr section, which follows the file name, is of the format:
 number of xattrs { xattr name xattr data size xattr data } for
 each xattr, terminated with a NULL byte and padded to a 4 byte boundary.

where value is...  8 bytes of ascii hex digits like the header values?
(Every cpio string is padded to a boundary. Sigh, lemme go read your
patch...)

Ok, 2/9, actual file format parsing. New magic string at the start
070703 for the new version. (Good, that was my first question: easy
way to distinguish this from the previous format).

-   for (i = 0, s += 6; i  12; i++, s += 8) {
+   for (i = 0; i  (!newcx ? 12 : 13); i++, s += 8) {

You've tested this and the missing s+= 6 didn't cause problems? (Or did
it move somewhere else...? Is that what the 1/9 did grabbing just the
magic instead of the rest of the header data...?)

 The header contains an additional field, before the checksum, containing
 the xattr section length, including the NULL byte, but without the
 padding.

Ah, the old 4 bytes of padding to align to 4 bytes silliness. (Even
though you can't trust the null to _be_ there and have to set it
yourself after the read.) I'm starting to remember this...

Ok, different header magic, one new 8 hex digit field at the end of the
header (before crc) containing xattr_bufflen. The start of this buffer
is an 8 digit hex num_xattrs, which you iterate through and call
strlen() on despite never having assured that the data you read in
actually _does_ contain a null at the end (of the entire buffer). Then
past that supposed null is another 8 digit hex xattr_value_size, and
that many bytes following you then send to sys_setxattr().

Except for the part about you trusting your input data way too much,
seems reasonable? I have no idea what sys_setxattr() accepts, but
presumably there's a man page for the system call...

  http://man7.org/linux/man-pages/man2/setxattr.2.html

Ok, that's probably enough data to implement it. (Not sure why that man
page isn't in my ubuntu 14.04 install which has manpages-dev installed?

  $ man setxattr
  No manual entry for setxattr

 Note that gen_init_cpio does not include security.evm as it is file
 system dependent.

I have no idea what that is. Should I not include it in the command line
cpio? (Or

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

On Tue, 2015-01-13 at 12:48 -0600, Rob Landley wrote: 
 On 01/08/2015 04:08 PM, Mimi Zohar wrote:
  On Thu, 2015-01-08 at 12:19 -0600, Rob Landley wrote:
 
  But I am curious about how you propose to encode xattrs into the cpio
  format. (Which Al Viro chose because it's _simple_. There isn't really
  a
  controlling spec since Posix decided to deprecated it in 2001 and
  yank
  it from SUSv3 onwards. LSB extended several header fields to 8 hex
  digits instead of 6, but they still have 32 bit timestamps which seems
  a
  bit short-sighted. If you're going to define a new rev with a new
  magic
  number, there are a couple other things you might wanna fix...)
  
  Sounds like a good opportunity to make the other changes as well.  We
  can include the other changes in this patch set.  Is this (initramfs)
  the right mailing list for this discussion?
 
 I'd forgotten there was such a list until the email came in. :)
 
  Do other people need to be included?
 
 In theory including the Austin Group (the posix committee mailing list)
 might be useful, but in practice they hear about stuff well after the
 fact, and they washed their hands of cpio over a decade ago (shortly
 after Linux started heavily using it in rpm, and a bit before initramfs).
 
 I note that there are two data formats of interest here:
 
 1) the cpio file layout.
 
 2) the list of files generated by gen_initramfs_list.sh and consumed by
 gen_init_cpio.
 
 The fact you're modifying gen_initramfs_list.sh seems to imply that
 you're changing the _second_ format as well as the first...? The second
 was never actually specified, but it does get used a lot by various
 build systems and breaking it would inconvenience people. (Plus I'd need
 to update the documentation, but I need to do that anyway.)

Patch [PATCH 6/9] gen_initramfs_list.sh: include xattrs is a one line
change that adds the -x option to include xattrs in the initramfs, if
they exist. This patch makes the new method (070703) the default format.

 Ss long as you're extending the format could you add a second 32 bits of
 time data that gets glued to the top half of a uint64_t, and then store
 the actual time value in microseconds (so time*100)? (I'd say
 nanoseconds but 63 bits of nanoseconds is 292 years, which is just
 short enough I'm uncomfortable with it. I'm just optimistic enough to
 think that might inconvenience somebody.)
 
 The other huh is the filesize, but 4 gigs per file seems unlikely to
 be more than initramfs needs any time soon? (It's possible that RPM
 might care in 15 years or so...)

4 bytes enough?

  I ask because I maintain a new from-scratch cpio implementation
  (http://landley.net/hg/toybox/file/1571/toys/posix/cpio.c), so I'd
  presumably have to add your format extensions to this. Is there any
  sort
  of documentation on them?
 
  The toybox config Android is using has this cpio implementation
  enabled
  (see
  https://android.googlesource.com/platform/external/toybox/+/9250c95a8c47/Android.mk)
  so I'd rather like to get this sort of detail right...
  
  The xattr section, which follows the file name, is of the format:
  number of xattrs { xattr name xattr data size xattr data } for
  each xattr, terminated with a NULL byte and padded to a 4 byte boundary.
 
 where value is...  8 bytes of ascii hex digits like the header values?
 (Every cpio string is padded to a boundary. Sigh, lemme go read your
 patch...)
 
 Ok, 2/9, actual file format parsing. New magic string at the start
 070703 for the new version. (Good, that was my first question: easy
 way to distinguish this from the previous format).
 
 - for (i = 0, s += 6; i  12; i++, s += 8) {
 + for (i = 0; i  (!newcx ? 12 : 13); i++, s += 8) {
 
 You've tested this and the missing s+= 6 didn't cause problems? (Or did
 it move somewhere else...? Is that what the 1/9 did grabbing just the
 magic instead of the rest of the header data...?)

Right, the first patch separates reading the magic string from reading
the rest of the header.

  The header contains an additional field, before the checksum, containing
  the xattr section length, including the NULL byte, but without the
  padding.
 
 Ah, the old 4 bytes of padding to align to 4 bytes silliness. (Even
 though you can't trust the null to _be_ there and have to set it
 yourself after the read.) I'm starting to remember this...
 
 Ok, different header magic, one new 8 hex digit field at the end of the
 header (before crc) containing xattr_bufflen. The start of this buffer
 is an 8 digit hex num_xattrs, which you iterate through and call
 strlen() on despite never having assured that the data you read in
 actually _does_ contain a null at the end (of the entire buffer). Then
 past that supposed null is another 8 digit hex xattr_value_size, and
 that many bytes following you then send to sys_setxattr().
 
 Except for the part about you trusting your input data way too much,
 seems reasonable? 

Ok

 I have no idea what sys_setxattr()

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

On 01/13/2015 02:20 PM, Mimi Zohar wrote:
On Tue, 2015-01-13 at 12:48 -0600, Rob Landley wrote:
I note that there are two data formats of interest here:

1) the cpio file layout.

2) the list of files generated by gen_initramfs_list.sh and consumed by
gen_init_cpio.

Patch [PATCH 6/9] gen_initramfs_list.sh: include xattrs is a one line
change that adds the -x option to include xattrs in the initramfs, if
they exist.

Unconditionally. Even if we've configured xattr support out of our
kernel or tmpfs?

This patch makes the new method (070703) the default format.

So nobody should ever try to build an embedded system (without xattrs)
from something like Red Hat Enterprise (where they just magically show up)?

The other huh is the filesize, but 4 gigs per file seems unlikely to
be more than initramfs needs any time soon? (It's possible that RPM
might care in 15 years or so...)

4 bytes enough?

Probably having the new fields at the end (and gluing them to the
earlier ones) makes more sense than having variable sized fields? I
don't have a strong opinion either way.

I have no idea what sys_setxattr() accepts, but
presumably there's a man page for the system call...

http://man7.org/linux/man-pages/man2/setxattr.2.html

Ok, that's probably enough data to implement it. (Not sure why that man
page isn't in my ubuntu 14.04 install which has manpages-dev installed?

$ man setxattr
No manual entry for setxattr

Note that gen_init_cpio does not include security.evm as it is file
system dependent.

I have no idea what that is. Should I not include it in the command line
cpio? (Or have a flag?)

Right, don't include security.evm. Both the HMAC and signature format
include the inode number, which is filesystem specific.

So save extended attributes but filter out this one magic extended
attribute that we _shouldn't_ save because we know, a priori, that this
data is not portable.

I'm remembering why I didn't want to get this on me.

The last time I used extended attributes was on OS/2; my only
non-academic interaction with selinux has been looking up how to switch
it off.

Yes, and I can't keep 'em straight. The android guys are adding SELinux:

https://android.googlesource.com/platform/external/toybox/+/d5c66a9fd36777f80ba05301dcfa6789b103e486

The Tizen guys are adding something called smack:
https://git.tizen.org/cgit/platform/upstream/toybox.git

Up until about 3 months ago I had successfully avoided all of this. Oh
well, always something new to learn...

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

On Thu, 2015-01-08 at 12:19 -0600, Rob Landley wrote:
> 
> But I am curious about how you propose to encode xattrs into the cpio
> format. (Which Al Viro chose because it's _simple_. There isn't really
> a
> controlling spec since Posix decided to deprecated it in 2001 and
> yank
> it from SUSv3 onwards. LSB extended several header fields to 8 hex
> digits instead of 6, but they still have 32 bit timestamps which seems
> a
> bit short-sighted. If you're going to define a new rev with a new
> magic
> number, there are a couple other things you might wanna fix...)

Sounds like a good opportunity to make the other changes as well.  We
can include the other changes in this patch set.  Is this (initramfs)
the right mailing list for this discussion?  Do other people need to be
included?

> I ask because I maintain a new from-scratch cpio implementation
> (http://landley.net/hg/toybox/file/1571/toys/posix/cpio.c), so I'd
> presumably have to add your format extensions to this. Is there any
> sort
> of documentation on them?
> 
> The toybox config Android is using has this cpio implementation
> enabled
> (see
> https://android.googlesource.com/platform/external/toybox/+/9250c95a8c47/Android.mk)
> so I'd rather like to get this sort of detail right...

The xattr section, which follows the file name, is of the format:
 {} for
each xattr, terminated with a NULL byte and padded to a 4 byte boundary.

The header contains an additional field, before the checksum, containing
the xattr section length, including the NULL byte, but without the
padding.

Note that gen_init_cpio does not include "security.evm" as it is file
system dependent.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

2015-01-08 Thread Rob Landley

On 01/08/2015 09:13 AM, Mimi Zohar wrote:
> On Thu, 2015-01-08 at 09:01 -0500, Josh Boyer wrote: 
>> On Wed, Jan 7, 2015 at 3:52 PM, Mimi Zohar  wrote:
>> That's pretty awkward.  I think it highlights the major downside of
>> this approach in that from a standard distro point of view this
>> functionality isn't likely to be used.  Do you foresee this feature as
>> something that should be widely used, or something that would be used
>> more in custom, locked-down machines?
> 
> Before distros can start enabling these features, software packages need
> to come with file signatures.  Fin Gunter posted (and shortly will
> re-post) patches to include file signatures in RPM patches.

My personal lack of caring about Red Hat's bureaucratic "signing
binaries in triplicate" is probably large enough to be seen from space
(obviously no vendor code has ever contained an exploit that could be
used to run arbitrary code in ring 0, and this totally won't be used for
vendor lock-in, but I remain unconvinced because I'm funny that way)...

But I am curious about how you propose to encode xattrs into the cpio
format. (Which Al Viro chose because it's _simple_. There isn't really a
controlling spec since Posix decided to deprecated it in 2001 and  yank
it from SUSv3 onwards. LSB extended several header fields to 8 hex
digits instead of 6, but they still have 32 bit timestamps which seems a
bit short-sighted. If you're going to define a new rev with a new magic
number, there are a couple other things you might wanna fix...)

I ask because I maintain a new from-scratch cpio implementation
(http://landley.net/hg/toybox/file/1571/toys/posix/cpio.c), so I'd
presumably have to add your format extensions to this. Is there any sort
of documentation on them?

The toybox config Android is using has this cpio implementation enabled
(see
https://android.googlesource.com/platform/external/toybox/+/9250c95a8c47/Android.mk)
so I'd rather like to get this sort of detail right...

> Including file signatures in RPM packages (and similarly in other
> software package formats) is the direction we, the linux community, IMHO
> should be moving.  How long this will take is entirely up to the
> distros.

Glued down to a trusted platform module such that obviously nobody can
possibly exploit such a system, from
https://www.youtube.com/watch?v=4loZGYqaZ7I to
https://trmm.net/Thunderstrike_31c3

I see this as way, way more about vendor lock-in than security.

>> I can understand not wanting to redefine the newc format in userspace
>> cpio, but if you want this to be easier to use then perhaps working
>> with dracut upstream to make it support this out of the box would be a
>> good idea.
> 
> Anyone using dracut/systemd is currently not using tmpfs, as specifying
> "root=" on the boot command line reverts to using ramfs.  Rob Landley
> suggested userspace apps use "ROOT=" instead.
> (http://sourceforge.net/p/linux-ima/mailman/message/33189705/)

I'm working on a documentation update, but the old docs I wrote have
gone a bit stale in a number of places so I'm not done yet...

> This patch set was posted as an RFC.  Assuming this solution for
> including xattrs in the rootfs is acceptable, I'll post the
> dracut/systemd changes.

(I'm not particularly interested in systemd either, but good luck with
that...)

> Mimi

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

On Thu, 2015-01-08 at 09:01 -0500, Josh Boyer wrote: 
> On Wed, Jan 7, 2015 at 3:52 PM, Mimi Zohar  wrote:
> > This patch modifies the gen_initramfs_list.sh script to include xattrs
> > in the initramfs.
> >
> > Dracut creates the initramfs using the cpio tool on the system, not
> > the kernel's gen_init_cpio script. The following commands, for example,
> > would create an initramfs containing xattrs.
> >
> > dracut -H -f /boot/initramfs-3.XX.0+.img 3.XX.0+ -M --keep \
> > --noprelink --nostrip
> > gen_initramfs_list.sh /var/tmp/initramfs.XX/ > \
> > /var/tmp/initramfs_list.XX
> >
> > [Sign files here, if not already signed, using evmctl.]
> >
> > gen_init_cpio -x /var/tmp/initramfs_list.XX >  \
> > /boot/initramfs-3.XX.0+test.img
> 
> That's pretty awkward.  I think it highlights the major downside of
> this approach in that from a standard distro point of view this
> functionality isn't likely to be used.  Do you foresee this feature as
> something that should be widely used, or something that would be used
> more in custom, locked-down machines?

Before distros can start enabling these features, software packages need
to come with file signatures.  Fin Gunter posted (and shortly will
re-post) patches to include file signatures in RPM patches.

Including file signatures in RPM packages (and similarly in other
software package formats) is the direction we, the linux community, IMHO
should be moving.  How long this will take is entirely up to the
distros.

> I can understand not wanting to redefine the newc format in userspace
> cpio, but if you want this to be easier to use then perhaps working
> with dracut upstream to make it support this out of the box would be a
> good idea.

Anyone using dracut/systemd is currently not using tmpfs, as specifying
"root=" on the boot command line reverts to using ramfs.  Rob Landley
suggested userspace apps use "ROOT=" instead.
(http://sourceforge.net/p/linux-ima/mailman/message/33189705/)

This patch set was posted as an RFC.  Assuming this solution for
including xattrs in the rootfs is acceptable, I'll post the
dracut/systemd changes.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

2015-01-08 Thread Josh Boyer

On Wed, Jan 7, 2015 at 3:52 PM, Mimi Zohar  wrote:
> This patch modifies the gen_initramfs_list.sh script to include xattrs
> in the initramfs.
>
> Dracut creates the initramfs using the cpio tool on the system, not
> the kernel's gen_init_cpio script. The following commands, for example,
> would create an initramfs containing xattrs.
>
> dracut -H -f /boot/initramfs-3.XX.0+.img 3.XX.0+ -M --keep \
> --noprelink --nostrip
> gen_initramfs_list.sh /var/tmp/initramfs.XX/ > \
> /var/tmp/initramfs_list.XX
>
> [Sign files here, if not already signed, using evmctl.]
>
> gen_init_cpio -x /var/tmp/initramfs_list.XX >  \
> /boot/initramfs-3.XX.0+test.img

That's pretty awkward.  I think it highlights the major downside of
this approach in that from a standard distro point of view this
functionality isn't likely to be used.  Do you foresee this feature as
something that should be widely used, or something that would be used
more in custom, locked-down machines?

I can understand not wanting to redefine the newc format in userspace
cpio, but if you want this to be easier to use then perhaps working
with dracut upstream to make it support this out of the box would be a
good idea.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

On Thu, 2015-01-08 at 12:19 -0600, Rob Landley wrote:
 
 But I am curious about how you propose to encode xattrs into the cpio
 format. (Which Al Viro chose because it's _simple_. There isn't really
 a
 controlling spec since Posix decided to deprecated it in 2001 and
 yank
 it from SUSv3 onwards. LSB extended several header fields to 8 hex
 digits instead of 6, but they still have 32 bit timestamps which seems
 a
 bit short-sighted. If you're going to define a new rev with a new
 magic
 number, there are a couple other things you might wanna fix...)

Sounds like a good opportunity to make the other changes as well.  We
can include the other changes in this patch set.  Is this (initramfs)
the right mailing list for this discussion?  Do other people need to be
included?

 I ask because I maintain a new from-scratch cpio implementation
 (http://landley.net/hg/toybox/file/1571/toys/posix/cpio.c), so I'd
 presumably have to add your format extensions to this. Is there any
 sort
 of documentation on them?
 
 The toybox config Android is using has this cpio implementation
 enabled
 (see
 https://android.googlesource.com/platform/external/toybox/+/9250c95a8c47/Android.mk)
 so I'd rather like to get this sort of detail right...

The xattr section, which follows the file name, is of the format:
number of xattrs { xattr name xattr data size xattr data } for
each xattr, terminated with a NULL byte and padded to a 4 byte boundary.

The header contains an additional field, before the checksum, containing
the xattr section length, including the NULL byte, but without the
padding.

Note that gen_init_cpio does not include security.evm as it is file
system dependent.

Mimi

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

2015-01-08 Thread Josh Boyer

On Wed, Jan 7, 2015 at 3:52 PM, Mimi Zohar zo...@linux.vnet.ibm.com wrote:
 This patch modifies the gen_initramfs_list.sh script to include xattrs
 in the initramfs.

 Dracut creates the initramfs using the cpio tool on the system, not
 the kernel's gen_init_cpio script. The following commands, for example,
 would create an initramfs containing xattrs.

 dracut -H -f /boot/initramfs-3.XX.0+.img 3.XX.0+ -M --keep \
 --noprelink --nostrip
 gen_initramfs_list.sh /var/tmp/initramfs.XX/  \
 /var/tmp/initramfs_list.XX

 [Sign files here, if not already signed, using evmctl.]

 gen_init_cpio -x /var/tmp/initramfs_list.XX   \
 /boot/initramfs-3.XX.0+test.img

That's pretty awkward.  I think it highlights the major downside of
this approach in that from a standard distro point of view this
functionality isn't likely to be used.  Do you foresee this feature as
something that should be widely used, or something that would be used
more in custom, locked-down machines?

I can understand not wanting to redefine the newc format in userspace
cpio, but if you want this to be easier to use then perhaps working
with dracut upstream to make it support this out of the box would be a
good idea.

josh
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs

2015-01-08 Thread Rob Landley

On 01/08/2015 09:13 AM, Mimi Zohar wrote:
 On Thu, 2015-01-08 at 09:01 -0500, Josh Boyer wrote: 
 On Wed, Jan 7, 2015 at 3:52 PM, Mimi Zohar zo...@linux.vnet.ibm.com wrote:
 That's pretty awkward.  I think it highlights the major downside of
 this approach in that from a standard distro point of view this
 functionality isn't likely to be used.  Do you foresee this feature as
 something that should be widely used, or something that would be used
 more in custom, locked-down machines?
 
 Before distros can start enabling these features, software packages need
 to come with file signatures.  Fin Gunter posted (and shortly will
 re-post) patches to include file signatures in RPM patches.

My personal lack of caring about Red Hat's bureaucratic signing
binaries in triplicate is probably large enough to be seen from space
(obviously no vendor code has ever contained an exploit that could be
used to run arbitrary code in ring 0, and this totally won't be used for
vendor lock-in, but I remain unconvinced because I'm funny that way)...

But I am curious about how you propose to encode xattrs into the cpio
format. (Which Al Viro chose because it's _simple_. There isn't really a
controlling spec since Posix decided to deprecated it in 2001 and  yank
it from SUSv3 onwards. LSB extended several header fields to 8 hex
digits instead of 6, but they still have 32 bit timestamps which seems a
bit short-sighted. If you're going to define a new rev with a new magic
number, there are a couple other things you might wanna fix...)

I ask because I maintain a new from-scratch cpio implementation
(http://landley.net/hg/toybox/file/1571/toys/posix/cpio.c), so I'd
presumably have to add your format extensions to this. Is there any sort
of documentation on them?

The toybox config Android is using has this cpio implementation enabled
(see
https://android.googlesource.com/platform/external/toybox/+/9250c95a8c47/Android.mk)
so I'd rather like to get this sort of detail right...

 Including file signatures in RPM packages (and similarly in other
 software package formats) is the direction we, the linux community, IMHO
 should be moving.  How long this will take is entirely up to the
 distros.

Glued down to a trusted platform module such that obviously nobody can
possibly exploit such a system, from
https://www.youtube.com/watch?v=4loZGYqaZ7I to
https://trmm.net/Thunderstrike_31c3

I see this as way, way more about vendor lock-in than security.

 I can understand not wanting to redefine the newc format in userspace
 cpio, but if you want this to be easier to use then perhaps working
 with dracut upstream to make it support this out of the box would be a
 good idea.
 
 Anyone using dracut/systemd is currently not using tmpfs, as specifying
 root= on the boot command line reverts to using ramfs.  Rob Landley
 suggested userspace apps use ROOT= instead.
 (http://sourceforge.net/p/linux-ima/mailman/message/33189705/)

I'm working on a documentation update, but the old docs I wrote have
gone a bit stale in a number of places so I'm not done yet...

 This patch set was posted as an RFC.  Assuming this solution for
 including xattrs in the rootfs is acceptable, I'll post the
 dracut/systemd changes.

(I'm not particularly interested in systemd either, but good luck with
that...)

 Mimi

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 6/9] gen_initramfs_list.sh: include xattrs