[RFC] Create Mach-O - Stage 1 Proposal

[peasead]

RFC Preview

Resolves #1096

• Have you signed the contributor license agreement? Yes
• Have you followed the contributor guidelines? Yes
• For proposing substantial changes or additions to the schema, have you reviewed the RFC process? Yes
• If submitting code/script changes, have you verified all tests pass locally using make test? NA at this stage
• If submitting schema/fields updates, have you generated new artifacts by running make and committed those changes? NA at this stage
• Is your pull request against master? Unless there is a good reason otherwise, we prefer pull requests against master and will backport as needed. Yes
• Have you added an entry to the CHANGELOG.next.md? NA at this stage

[peasead]

Thanks for the update @dcode

[ebeahan]

Since we're losing some context from the original PR #1097, was there ever a final resolution for this discussion? #1097 (comment)

[ebeahan]

The macho.segments fields in the sample field definitions are using:

• macho.segments.fileoff
• macho.segments.filesize
• macho.segments.flags
• macho.segments.name
• macho.segements.offset
• macho.segments.sections
• macho.segements.size
• macho.segments.vmaddr
• macho.segments.vmsize

Looks like there's some alignment, but some fields are mismatched. I prefer the more verbose naming here in the table.

[dcode]

Agree, the more verbose naming is better. We'll get that cleaned up.

[devonakerr]

LGTM - sorry for the delayed approval.

[ebeahan]

Thanks, @devonakerr, for reviewing.

The one item I still have is the fields list doesn't match the definitions. Once that's addressed, I believe we'll be in good shape to advance this one.

cc @peasead @dcode

[peasead]

Thanks, @devonakerr, for reviewing.

The one item I still have is the fields list doesn't match the definitions. Once that's addressed, I believe we'll be in good shape to advance this one.

cc @peasead @dcode

@ebeahan I think we're cleaned up now.

[ebeahan]

I'd prefer to leave the top-level ECS fields all as objects.

What about defining macho.architectures as nested and having each architecture's fields defined underneath? Borrowing from what @andrewstucki proposed in elastic/beats#24195.

- name: macho
   title: Mach-O file information.
   type: group
   description: These fields contain macOS Mach Object (Mach-O) metadata.
   fields:
     - name: architectures
        description: Object files contained inside this file by architecture
        type: nested
        fields:
          - name: cpu
             description: CPU architecture target for the file.
             type: keyword
             example: 64-bit

          - name: byte_order
             description: Byte order for the file.
             type: keyword
             example: little-endian

          - name: type
             description: Mach-O file type.
             type: keyword

[peasead]

So, you're suggesting changing:

• macho.cpu.{architecture,byte_order,type,...} to macho.architecture.{cpu,byte_order,type,...}?
• macho.* being a group instead of nested and macho.architecture.cpu{cpu,byte_order,type,...} being nested?

[ebeahan]

Yes, mostly. One difference - I'm proposing macho.architecture being the nested field that all the other fields would fall under for each architecture type.

[dcode]

The goal is that the "interface" to ELF, MachO, and PE have a similar feel. This will make building analytics and understanding of the data model. I discussed with @andrewstucki a while back about means to do that. The problem is that MachO fat binaries are literally two fully, self-sufficient executables in one big MachO wrapper. This means that any field that we decide to nest as architecture specific will have to contain all the architecture-dependent data. The result of this discussion is that it probably made the most sense to make file.macho as a nested type, which drastically simplifies the data.

We should meet to discuss.

[peasead]

Closing until ready to revisit this.