[PATCH 0/5] x86: CVE-2017-5715, aka Spectre
Jakub Jelinek
jakub@redhat.com
Mon Jan 8 16:32:00 GMT 2018
On Mon, Jan 08, 2018 at 08:17:27AM -0800, H.J. Lu wrote:
> On Mon, Jan 8, 2018 at 7:06 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Mon, Jan 08, 2018 at 07:00:11AM -0800, H.J. Lu wrote:
> >> See:
> >>
> >> https://sourceware.org/ml/binutils/2017-11/msg00369.html
> >
> > Program Headers:
> > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> > LOAD 0x000000 0x00000000 0x00000000 0x00200 0x00200 R 0x200000
> > LOAD 0x000fd0 0x00200fd0 0x00200fd0 0x0002b 0x0002b R E 0x200000
> > LOAD 0x001000 0x00201000 0x00201000 0x00058 0x00058 R 0x200000
> > LOAD 0x200f80 0x00400f80 0x00400f80 0x000a0 0x000a0 RW 0x200000
> > DYNAMIC 0x200f80 0x00400f80 0x00400f80 0x00080 0x00080 RW 0x4
> > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10
> > GNU_RELRO 0x200f80 0x00400f80 0x00400f80 0x00080 0x00080 R 0x1
> >
> > Uh, 3 read-only LOADs instead of 2? Shouldn't then all the read-only
> > non-executable sections be emitted together, so that you have a R, then R E,
> > then RW PT_LOADs?
>
> It is done on purpose since the second RO segment will be merged with the RELRO
> segment at load time:
That doesn't look like an advantage over not introducing it.
> Elf file type is EXEC (Executable file)
> Entry point 0x401ea0
> There are 11 program headers, starting at offset 52
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> PHDR 0x000034 0x00400034 0x00400034 0x00160 0x00160 R 0x4
> INTERP 0x000194 0x00400194 0x00400194 0x0001a 0x0001a R 0x1
> [Requesting program interpreter: /libx32/ld-linux-x32.so.2]
> LOAD 0x000000 0x00400000 0x00400000 0x0037c 0x0037c R 0x1000
> LOAD 0x000e68 0x00401e68 0x00401e68 0x00195 0x00195 R E 0x1000
> LOAD 0x001000 0x00402000 0x00402000 0x00124 0x00124 R 0x1000
> LOAD 0x001ef0 0x00402ef0 0x00402ef0 0x00134 0x00138 RW 0x1000
> DYNAMIC 0x001ef8 0x00402ef8 0x00402ef8 0x000f8 0x000f8 RW 0x4
> NOTE 0x0001b0 0x004001b0 0x004001b0 0x00044 0x00044 R 0x4
> GNU_EH_FRAME 0x001008 0x00402008 0x00402008 0x00034 0x00034 R 0x4
> GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10
> GNU_RELRO 0x001ef0 0x00402ef0 0x00402ef0 0x00110 0x00110 R 0x1
PHDR 0x000034 0x00400034 0x00400034 0x00160 0x00160 R 0x4
INTERP 0x000194 0x00400194 0x00400194 0x0001a 0x0001a R 0x1
[Requesting program interpreter: /libx32/ld-linux-x32.so.2]
LOAD 0x000000 0x00400000 0x00400000 0x004a0 0x004a0 R 0x1000
LOAD 0x000e68 0x00401e68 0x00401e68 0x00195 0x00195 R E 0x1000
LOAD 0x001ef0 0x00402ef0 0x00402ef0 0x00134 0x00138 RW 0x1000
DYNAMIC 0x001ef8 0x00402ef8 0x00402ef8 0x000f8 0x000f8 RW 0x4
NOTE 0x0001b0 0x004001b0 0x004001b0 0x00044 0x00044 R 0x4
GNU_EH_FRAME 0x001008 0x00402008 0x00402008 0x00034 0x00034 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10
GNU_RELRO 0x001ef0 0x00402ef0 0x00402ef0 0x00110 0x00110 R 0x1
you could even more the second PT_LOAD earlier to make the gaps on disk
smaller.
Jakub
More information about the Gcc-patches
mailing list