Re: [PATCH] lkdtm: support llvm-objcopy

[Nick Desaulniers]

On Wed, May 15, 2019 at 9:43 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>
> On Tue, May 14, 2019 at 01:24:37PM -0700, Nick Desaulniers wrote:
> > On Tue, May 14, 2019 at 11:11 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
> > >
> > > On Mon, May 13, 2019 at 04:50:05PM -0700, Nick Desaulniers wrote:
> > > > On Mon, May 13, 2019 at 4:29 PM Nathan Chancellor
> > > > <natechancellor@xxxxxxxxx> wrote:
> > > > >
> > > > > On Mon, May 13, 2019 at 03:21:09PM -0700, 'Nick Desaulniers' via Clang Built Linux wrote:
> > > > > > With CONFIG_LKDTM=y and make OBJCOPY=llvm-objcopy, llvm-objcopy errors:
> > > > > > llvm-objcopy: error: --set-section-flags=.text conflicts with
> > > > > > --rename-section=.text=.rodata
> > > > > >
> > > > > > Rather than support setting flags then renaming sections vs renaming
> > > > > > then setting flags, it's simpler to just change both at the same time
> > > > > > via --rename-section.
> >
> > I'm not sure I want to call it a bug in the initial implementation.  I've filed:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=24554 for
> > clarification.  Jordan, I hope you can participate in any discussion
> > there?
>
> Based on the hint from Alan Modra, it seems PROGBITS/NOBITS can be
> controlled with the presence/absence of the "load" section flag. This
> appears to work for both BFD and LLVM:
>
> $ objcopy --rename-section .text=.rodata,alloc,readonly,load rodata.o rodata_objcopy.o
> $ readelf -WS rodata_objcopy.o | grep \.rodata
>  [ 1] .rodata    PROGBITS     0000000000000000 000040 000002 00   A  0   0 16
>
> $ llvm-objcopy --rename-section .text=.rodata,alloc,readonly,load rodata.o rodata_objcopy.o
> $ readelf -WS rodata_objcopy.o | grep \.rodata
>  [ 1] .rodata    PROGBITS     0000000000000000 000040 000002 00   A  0   0 16
>
> So, that's an easy change that could be folded into the original version
> of this patch (no need for my two-phase work-around).

Ah, yes that's better.  I'll fold that into a v2 and resend shortly.
I'm going to carry your Ack from earlier, please let me know offlist
if that's not appropriate.
-- 
Thanks,
~Nick Desaulniers