| Message ID | e65025af-5168-c999-bfc1-7ac614314836@huawei.com |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] AArch64: use movz/movk instead of literal pools in start.S | expand |
> eXecute-Only Memory (XOM) is a protection mechanism against some ROP > attacks. XOM sets the code as executable and unreadable, so the > access to any data, like literal pools, in the code section causes > the fault with XOM. The compiler can disable literal pools for C > source files, but not for assembly files, so I use movz/movk instead > of literal pools in start.S for XOM. Isn't the main goal of XOM to make it more difficult for the legitimate device owner to view running machine code? | Execute-only memory allows you to protect your intellectual property | by preventing executable code being read by users. For example, you | can place firmware in execute-only memory and load user code and | drivers separately. Placing the firmware in execute-only memory | prevents users from trivially reading the code. <http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471m/chr1368698326509.html> I don't think it's in the interests of the GNU projet to support such a thing.
On 07/09/17 12:43, Florian Weimer wrote: >> eXecute-Only Memory (XOM) is a protection mechanism against some ROP >> attacks. XOM sets the code as executable and unreadable, so the >> access to any data, like literal pools, in the code section causes >> the fault with XOM. The compiler can disable literal pools for C >> source files, but not for assembly files, so I use movz/movk instead >> of literal pools in start.S for XOM. > > Isn't the main goal of XOM to make it more difficult for the > legitimate device owner to view running machine code? > > | Execute-only memory allows you to protect your intellectual property > | by preventing executable code being read by users. For example, you > | can place firmware in execute-only memory and load user code and > | drivers separately. Placing the firmware in execute-only memory > | prevents users from trivially reading the code. > > <http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471m/chr1368698326509.html> > > I don't think it's in the interests of the GNU projet to support such > a thing. > even if that's the main use of xom, there might be other uses and removing data from text might have other uses than xom (reduce rop gadget possibility?) so i don't think this should be a problem (the gnu project already supports gazillion features that can do harm).
On Thu, Sep 7, 2017 at 12:33 AM, wangboshi <wangboshi@huawei.com> wrote: > eXecute-Only Memory (XOM) is a protection mechanism against some ROP > attacks. XOM sets the code as executable and unreadable, so the access to > any data, like literal pools, in the code section causes the fault with XOM. > The compiler can disable literal pools for C source files, but not for > assembly files, so I use movz/movk instead of literal pools in start.S for > XOM. > > I add MOVL macro with movz/movk instructions like movl pseudo-instruction in > armasm, and use the macro instead of literal pools. I have a few comments about the overall design: I don't know if this is a good idea, can the kernel override XOM anyways? That is if you do write(N, &main, 1024); That will write the main function out to the file? I have one comment about the implementation too. > > > 2017-09-07 Wang Boshi <wangboshi@huawei.com> > > * sysdeps/aarch64/start.S: Use MOVL instead of literal pools. > * sysdeps/aarch64/sysdep.h (MOVL): Add MOVL macro. > > diff --git a/sysdeps/aarch64/start.S b/sysdeps/aarch64/start.S > index df1c642..51e8e82 100644 > --- a/sysdeps/aarch64/start.S > +++ b/sysdeps/aarch64/start.S > @@ -71,9 +71,9 @@ _start: > ldr PTR_REG (4), [x4, #:got_lo12:__libc_csu_fini] > #else > /* Set up the other arguments in registers */ > - ldr PTR_REG (0), =main > - ldr PTR_REG (3), =__libc_csu_init > - ldr PTR_REG (4), =__libc_csu_fini > + MOVL(0, main) > + MOVL(3, __libc_csu_init) > + MOVL(4, __libc_csu_fini) > #endif > > /* __libc_start_main (main, argc, argv, init, fini, rtld_fini, > diff --git a/sysdeps/aarch64/sysdep.h b/sysdeps/aarch64/sysdep.h > index a749a70..0a11b57 100644 > --- a/sysdeps/aarch64/sysdep.h > +++ b/sysdeps/aarch64/sysdep.h > @@ -137,6 +137,20 @@ > ldr PTR_REG (T), [x##T, #:got_lo12:EXPR]; \ > OP PTR_REG (R), [x##T]; > > +/* Load an immediate into R. > + Note R is a register number and not a register name. */ > +#ifdef __LP64__ > +# define MOVL(n, name) \ > + movz PTR_REG(n), #:abs_g3:name; \ > + movk PTR_REG(n), #:abs_g2_nc:name; \ > + movk PTR_REG(n), #:abs_g1_nc:name; \ > + movk PTR_REG(n), #:abs_g0_nc:name; > +#else > +# define MOVL(n, name) \ > + movz PTR_REG(n), #:abs_g1:name; \ > + movk PTR_REG(n), #:abs_g0_nc:name; > +#endif Since PTR_REG is defined only based on __LP64__ already why don't you just do: #ifdef __LP64__ # define MOVL(n, name) \ movz x##n, #:abs_g3:name; \ movk x##n, #:abs_g2_nc:name; \ movk x##n, #:abs_g1_nc:name; \ movk x##n, #:abs_g0_nc:name; #else # define MOVL(n, name) \ movz w##n, #:abs_g1:name; \ movk w##n, #:abs_g0_nc:name; #endif Thanks, Andrew > + > /* Since C identifiers are not normally prefixed with an underscore > on this system, the asm identifier `syscall_error' intrudes on the > C name space. Make sure we use an innocuous name. */ > >
On 07/09/17 08:33, wangboshi wrote: > eXecute-Only Memory (XOM) is a protection mechanism against some ROP attacks. XOM sets the code as executable > and unreadable, so the access to any data, like literal pools, in the code section causes the fault with XOM. > The compiler can disable literal pools for C source files, but not for assembly files, so I use movz/movk > instead of literal pools in start.S for XOM. > > I add MOVL macro with movz/movk instructions like movl pseudo-instruction in armasm, and use the macro instead > of literal pools. > > > 2017-09-07 Wang Boshi <wangboshi@huawei.com> > > * sysdeps/aarch64/start.S: Use MOVL instead of literal pools. > * sysdeps/aarch64/sysdep.h (MOVL): Add MOVL macro. > thanks, the patch looks good to me (except for a nit below), do you have copyright assignment? do you have commit rights to the glibc repo? > diff --git a/sysdeps/aarch64/start.S b/sysdeps/aarch64/start.S > index df1c642..51e8e82 100644 > --- a/sysdeps/aarch64/start.S > +++ b/sysdeps/aarch64/start.S > @@ -71,9 +71,9 @@ _start: > ldr PTR_REG (4), [x4, #:got_lo12:__libc_csu_fini] > #else > /* Set up the other arguments in registers */ > - ldr PTR_REG (0), =main > - ldr PTR_REG (3), =__libc_csu_init > - ldr PTR_REG (4), =__libc_csu_fini > + MOVL(0, main) > + MOVL(3, __libc_csu_init) > + MOVL(4, __libc_csu_fini) > #endif > > /* __libc_start_main (main, argc, argv, init, fini, rtld_fini, > diff --git a/sysdeps/aarch64/sysdep.h b/sysdeps/aarch64/sysdep.h > index a749a70..0a11b57 100644 > --- a/sysdeps/aarch64/sysdep.h > +++ b/sysdeps/aarch64/sysdep.h > @@ -137,6 +137,20 @@ > ldr PTR_REG (T), [x##T, #:got_lo12:EXPR]; \ > OP PTR_REG (R), [x##T]; > > +/* Load an immediate into R. > + Note R is a register number and not a register name. */ either rename the macro argument to R or use N in the comment. > +#ifdef __LP64__ > +# define MOVL(n, name) \ > + movz PTR_REG(n), #:abs_g3:name; \ > + movk PTR_REG(n), #:abs_g2_nc:name; \ > + movk PTR_REG(n), #:abs_g1_nc:name; \ > + movk PTR_REG(n), #:abs_g0_nc:name; > +#else > +# define MOVL(n, name) \ > + movz PTR_REG(n), #:abs_g1:name; \ > + movk PTR_REG(n), #:abs_g0_nc:name; > +#endif > + > /* Since C identifiers are not normally prefixed with an underscore > on this system, the asm identifier `syscall_error' intrudes on the > C name space. Make sure we use an innocuous name. */ > >
On 11/09/17 10:09, Andrew Pinski wrote: > On Thu, Sep 7, 2017 at 12:33 AM, wangboshi <wangboshi@huawei.com> wrote: >> eXecute-Only Memory (XOM) is a protection mechanism against some ROP >> attacks. XOM sets the code as executable and unreadable, so the access to >> any data, like literal pools, in the code section causes the fault with XOM. >> The compiler can disable literal pools for C source files, but not for >> assembly files, so I use movz/movk instead of literal pools in start.S for >> XOM. >> >> I add MOVL macro with movz/movk instructions like movl pseudo-instruction in >> armasm, and use the macro instead of literal pools. > > I have a few comments about the overall design: > I don't know if this is a good idea, can the kernel override XOM anyways? > That is if you do write(N, &main, 1024); > That will write the main function out to the file? i think the change makes sense even without xom, maybe a better rationale is needed in the commit message. (i don't know what the kernel does with the write, with a non-readable page i'd expect the write to fail just like on PROT_NONE pages: EFAULT). >> +/* Load an immediate into R. >> + Note R is a register number and not a register name. */ >> +#ifdef __LP64__ >> +# define MOVL(n, name) \ >> + movz PTR_REG(n), #:abs_g3:name; \ >> + movk PTR_REG(n), #:abs_g2_nc:name; \ >> + movk PTR_REG(n), #:abs_g1_nc:name; \ >> + movk PTR_REG(n), #:abs_g0_nc:name; >> +#else >> +# define MOVL(n, name) \ >> + movz PTR_REG(n), #:abs_g1:name; \ >> + movk PTR_REG(n), #:abs_g0_nc:name; >> +#endif > > Since PTR_REG is defined only based on __LP64__ already why don't you just do: i think either is fine (the meaning of PTR_REG should be obvious since it is used all over the place) > #ifdef __LP64__ > # define MOVL(n, name) \ > movz x##n, #:abs_g3:name; \ > movk x##n, #:abs_g2_nc:name; \ > movk x##n, #:abs_g1_nc:name; \ > movk x##n, #:abs_g0_nc:name; > #else > # define MOVL(n, name) \ > movz w##n, #:abs_g1:name; \ > movk w##n, #:abs_g0_nc:name; > #endif
On 2017/9/11 17:09, Andrew Pinski wrote: > On Thu, Sep 7, 2017 at 12:33 AM, wangboshi <wangboshi@huawei.com> wrote: >> eXecute-Only Memory (XOM) is a protection mechanism against some ROP >> attacks. XOM sets the code as executable and unreadable, so the access to >> any data, like literal pools, in the code section causes the fault with XOM. >> The compiler can disable literal pools for C source files, but not for >> assembly files, so I use movz/movk instead of literal pools in start.S for >> XOM. >> >> I add MOVL macro with movz/movk instructions like movl pseudo-instruction in >> armasm, and use the macro instead of literal pools. > I have a few comments about the overall design: > I don't know if this is a good idea, can the kernel override XOM anyways? > That is if you do write(N, &main, 1024); > That will write the main function out to the file? Thank you for your comments. They alert me. Kernels for different architectures own different behaviors because XOM depends on different hardware features in different architectures. All of kernels don't check the buffer directly. In x64 with mpk, the hardware will stop read operation from the buffer because of XOM, but the write only returns a failure and the program still runs. The current kernel for AArch64 overrides XOM. The example works in AArch64, and doesn't work in X64. Your example shows the weakness, but I think that it's not easy to exploit that with some existing protection mechanisms, like W^X and ASLR, and itself of XOM. So XOM is still valuable. Of course, I will try to fix the problem. Thank you. > > I have one comment about the implementation too. > >> >> 2017-09-07 Wang Boshi <wangboshi@huawei.com> >> >> * sysdeps/aarch64/start.S: Use MOVL instead of literal pools. >> * sysdeps/aarch64/sysdep.h (MOVL): Add MOVL macro. >> >> diff --git a/sysdeps/aarch64/start.S b/sysdeps/aarch64/start.S >> index df1c642..51e8e82 100644 >> --- a/sysdeps/aarch64/start.S >> +++ b/sysdeps/aarch64/start.S >> @@ -71,9 +71,9 @@ _start: >> ldr PTR_REG (4), [x4, #:got_lo12:__libc_csu_fini] >> #else >> /* Set up the other arguments in registers */ >> - ldr PTR_REG (0), =main >> - ldr PTR_REG (3), =__libc_csu_init >> - ldr PTR_REG (4), =__libc_csu_fini >> + MOVL(0, main) >> + MOVL(3, __libc_csu_init) >> + MOVL(4, __libc_csu_fini) >> #endif >> >> /* __libc_start_main (main, argc, argv, init, fini, rtld_fini, >> diff --git a/sysdeps/aarch64/sysdep.h b/sysdeps/aarch64/sysdep.h >> index a749a70..0a11b57 100644 >> --- a/sysdeps/aarch64/sysdep.h >> +++ b/sysdeps/aarch64/sysdep.h >> @@ -137,6 +137,20 @@ >> ldr PTR_REG (T), [x##T, #:got_lo12:EXPR]; \ >> OP PTR_REG (R), [x##T]; >> >> +/* Load an immediate into R. >> + Note R is a register number and not a register name. */ >> +#ifdef __LP64__ >> +# define MOVL(n, name) \ >> + movz PTR_REG(n), #:abs_g3:name; \ >> + movk PTR_REG(n), #:abs_g2_nc:name; \ >> + movk PTR_REG(n), #:abs_g1_nc:name; \ >> + movk PTR_REG(n), #:abs_g0_nc:name; >> +#else >> +# define MOVL(n, name) \ >> + movz PTR_REG(n), #:abs_g1:name; \ >> + movk PTR_REG(n), #:abs_g0_nc:name; >> +#endif > Since PTR_REG is defined only based on __LP64__ already why don't you just do: > #ifdef __LP64__ > # define MOVL(n, name) \ > movz x##n, #:abs_g3:name; \ > movk x##n, #:abs_g2_nc:name; \ > movk x##n, #:abs_g1_nc:name; \ > movk x##n, #:abs_g0_nc:name; > #else > # define MOVL(n, name) \ > movz w##n, #:abs_g1:name; \ > movk w##n, #:abs_g0_nc:name; > #endif I think PTR_REG is more meaningful. Thanks. > > Thanks, > Andrew > >> + >> /* Since C identifiers are not normally prefixed with an underscore >> on this system, the asm identifier `syscall_error' intrudes on the >> C name space. Make sure we use an innocuous name. */ >> >>
On 14/09/17 04:21, Boshi Wang wrote: > On 2017/9/11 17:11, Szabolcs Nagy wrote: >> On 07/09/17 08:33, wangboshi wrote: >>> 2017-09-07 Wang Boshi <wangboshi@huawei.com> >>> >>> * sysdeps/aarch64/start.S: Use MOVL instead of literal pools. >>> * sysdeps/aarch64/sysdep.h (MOVL): Add MOVL macro. >>> >> thanks, the patch looks good to me (except for a nit below), >> do you have copyright assignment? >> do you have commit rights to the glibc repo? > > I have read requirements of copyright assignment. I don't have that. > > I don't have commit rights, too. > > So how can I contribute the change? Could you give me some suggestions? > i think your change is just below the legally-significant limit https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant so i can commit it for you. but getting your employer to sort it out with the fsf would be better, in case you run into further issues that need glibc fixes.
On 2017/9/14 16:35, Szabolcs Nagy wrote: > On 14/09/17 04:21, Boshi Wang wrote: >> On 2017/9/11 17:11, Szabolcs Nagy wrote: >>> On 07/09/17 08:33, wangboshi wrote: >>>> 2017-09-07 Wang Boshi <wangboshi@huawei.com> >>>> >>>> * sysdeps/aarch64/start.S: Use MOVL instead of literal pools. >>>> * sysdeps/aarch64/sysdep.h (MOVL): Add MOVL macro. >>>> >>> thanks, the patch looks good to me (except for a nit below), >>> do you have copyright assignment? >>> do you have commit rights to the glibc repo? >> I have read requirements of copyright assignment. I don't have that. >> >> I don't have commit rights, too. >> >> So how can I contribute the change? Could you give me some suggestions? >> > i think your change is just below the legally-significant limit > https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant > so i can commit it for you. > > but getting your employer to sort it out with the fsf would be better, > in case you run into further issues that need glibc fixes. > That's great. I have a few doubt. Could you add my name into the patch? The new patch is here below. diff --git a/sysdeps/aarch64/start.S b/sysdeps/aarch64/start.S index df1c642..51e8e82 100644 --- a/sysdeps/aarch64/start.S +++ b/sysdeps/aarch64/start.S @@ -71,9 +71,9 @@ _start: ldr PTR_REG (4), [x4, #:got_lo12:__libc_csu_fini] #else /* Set up the other arguments in registers */ - ldr PTR_REG (0), =main - ldr PTR_REG (3), =__libc_csu_init - ldr PTR_REG (4), =__libc_csu_fini + MOVL(0, main) + MOVL(3, __libc_csu_init) + MOVL(4, __libc_csu_fini) #endif /* __libc_start_main (main, argc, argv, init, fini, rtld_fini, diff --git a/sysdeps/aarch64/sysdep.h b/sysdeps/aarch64/sysdep.h index a749a70..152f5ba 100644 --- a/sysdeps/aarch64/sysdep.h +++ b/sysdeps/aarch64/sysdep.h @@ -137,6 +137,20 @@ ldr PTR_REG (T), [x##T, #:got_lo12:EXPR]; \ OP PTR_REG (R), [x##T]; +/* Load an immediate into R. + Note R is a register number and not a register name. */ +#ifdef __LP64__ +# define MOVL(R, NAME) \ + movz PTR_REG(R), #:abs_g3:NAME; \ + movk PTR_REG(R), #:abs_g2_nc:NAME; \ + movk PTR_REG(R), #:abs_g1_nc:NAME; \ + movk PTR_REG(R), #:abs_g0_nc:NAME; +#else +# define MOVL(R, NAME) \ + movz PTR_REG(R), #:abs_g1:NAME; \ + movk PTR_REG(R), #:abs_g0_nc:NAME; +#endif + /* Since C identifiers are not normally prefixed with an underscore on this system, the asm identifier `syscall_error' intrudes on the C name space. Make sure we use an innocuous name. */ Thank you, Nagy.
On 15/09/17 02:16, Boshi Wang wrote: > On 2017/9/14 16:35, Szabolcs Nagy wrote: >> On 14/09/17 04:21, Boshi Wang wrote: >>> On 2017/9/11 17:11, Szabolcs Nagy wrote: >>>> On 07/09/17 08:33, wangboshi wrote: >>>>> 2017-09-07 Wang Boshi <wangboshi@huawei.com> >>>>> >>>>> * sysdeps/aarch64/start.S: Use MOVL instead of literal pools. >>>>> * sysdeps/aarch64/sysdep.h (MOVL): Add MOVL macro. >>>>> >>>> thanks, the patch looks good to me (except for a nit below), >>>> do you have copyright assignment? >>>> do you have commit rights to the glibc repo? >>> I have read requirements of copyright assignment. I don't have that. >>> >>> I don't have commit rights, too. >>> >>> So how can I contribute the change? Could you give me some suggestions? >>> >> i think your change is just below the legally-significant limit >> https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant >> so i can commit it for you. >> >> but getting your employer to sort it out with the fsf would be better, >> in case you run into further issues that need glibc fixes. >> > That's great. I have a few doubt. Could you add my name into the patch? > The new patch is here below. > committed.
diff --git a/sysdeps/aarch64/start.S b/sysdeps/aarch64/start.S index df1c642..51e8e82 100644 --- a/sysdeps/aarch64/start.S +++ b/sysdeps/aarch64/start.S @@ -71,9 +71,9 @@ _start: ldr PTR_REG (4), [x4, #:got_lo12:__libc_csu_fini] #else /* Set up the other arguments in registers */ - ldr PTR_REG (0), =main - ldr PTR_REG (3), =__libc_csu_init - ldr PTR_REG (4), =__libc_csu_fini + MOVL(0, main) + MOVL(3, __libc_csu_init) + MOVL(4, __libc_csu_fini) #endif /* __libc_start_main (main, argc, argv, init, fini, rtld_fini, diff --git a/sysdeps/aarch64/sysdep.h b/sysdeps/aarch64/sysdep.h index a749a70..0a11b57 100644 --- a/sysdeps/aarch64/sysdep.h +++ b/sysdeps/aarch64/sysdep.h @@ -137,6 +137,20 @@ ldr PTR_REG (T), [x##T, #:got_lo12:EXPR]; \ OP PTR_REG (R), [x##T]; +/* Load an immediate into R. + Note R is a register number and not a register name. */ +#ifdef __LP64__ +# define MOVL(n, name) \ + movz PTR_REG(n), #:abs_g3:name; \ + movk PTR_REG(n), #:abs_g2_nc:name; \ + movk PTR_REG(n), #:abs_g1_nc:name; \ + movk PTR_REG(n), #:abs_g0_nc:name; +#else +# define MOVL(n, name) \ + movz PTR_REG(n), #:abs_g1:name; \ + movk PTR_REG(n), #:abs_g0_nc:name; +#endif + /* Since C identifiers are not normally prefixed with an underscore on this system, the asm identifier `syscall_error' intrudes on the C name space. Make sure we use an innocuous name. */
eXecute-Only Memory (XOM) is a protection mechanism against some ROP attacks. XOM sets the code as executable and unreadable, so the access to any data, like literal pools, in the code section causes the fault with XOM. The compiler can disable literal pools for C source files, but not for assembly files, so I use movz/movk instead of literal pools in start.S for XOM. I add MOVL macro with movz/movk instructions like movl pseudo-instruction in armasm, and use the macro instead of literal pools. 2017-09-07 Wang Boshi <wangboshi@huawei.com> * sysdeps/aarch64/start.S: Use MOVL instead of literal pools. * sysdeps/aarch64/sysdep.h (MOVL): Add MOVL macro.