The Offset field is used to set the file offset of a program header.
In a normal object it should not be greater than the minimal offset
of sections included into segment.
This patch adds a check for that and adds tests.
Differential D78304
[yaml2obj] - Program headers: add an additional check for `Offset` grimar on Apr 16 2020, 8:30 AM. Authored by
Details The Offset field is used to set the file offset of a program header. This patch adds a check for that and adds tests.
Diff Detail Event Timeline
Comment Actions Not looked at the detail of this change yet, but I'm wondering why we need it? One way of looking at things is that a segment is just a range. It doesn't have any literal contents in the sense of things it strictly owns, unlike sections which need to have contents placed at specific locations, which cannot overlap other contents of the file. Consequently, we essentially need two offset fields for sections: 1) where the contents are placed (derived implicitly), and 2) what the sh_offset field should be (allowing it to be placed in places where contents otherwise couldn't be written). Can't the regular Offset field be used for this instead? Yes, that might mean that the offset is greater than the minimum section offset, but I think that's okay? Comment Actions That is what I was not sure is OK and why this patch appeared. We have a few test cases like: Sections: - Name: .dynamic Type: SHT_DYNAMIC Entries: - Tag: DT_NULL Value: 0 ProgramHeaders: - Type: PT_DYNAMIC Offset: 0xffff0000 Sections: - Section: .dynamic I read it as (knowing the internal logic): "take the list of 'Sections` and assign the proper memory size, file size and the offset. Does it make sense? Comment Actions I think the problem here is that we have two competing sources of information for how to layout a program header - the Sections list and the Offset key. Possibly me mental model is outdated, but I thought the layout of the program headers had no effect on that of the sections? In other words, I thought that a section offset was based purely on its alignment and the positions and sizes of any sections/fillers/headers before it? Assuming that my model is correct, a program header's offset and size are determined by the contents, if unspecified, but a forced Offset greater than the start offset of some section seems invalid, and should therefore generate an error?
In other words, don't try to derive a memory and file size and just emit an error in this case. It doesn't need to be allowed to create a broken ELF in this instance, because you can always specify the sizes explicitly. The alternative of course is to completely change yaml2obj's model to lead with program headers, i.e. sections listed in program headers should be placed based on the offset of the program header. I don't think this is necessarily a good change to make though. Comment Actions There is some misunderstanding it seems: It is correct.
This is what this patch does. It introduces an error when the program header Offset forced is greater than the minimal section offset. So I think the behavior you described is exactly what this patch does, or not ? Comment Actions The bit I don't understand is the need for the POffset field. In such instances, just don't list the sections and use explicit Offset + FileSize/MemSize. The sizes wouldn't make sense anyway since the program header would be at a weird location. Comment Actions OK, great! That what I did it initially in D78005 (in tests) and it sounds good to me. Then I'll remove the "POffset" field from this patch. So it will just introduce the offset validation check and adopt existent test cases.
Comment Actions
Comment Actions LGTM, with nit.
|
Should this ignore SHT_NOBITS?