From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39492 invoked by alias); 12 Sep 2017 08:54:46 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 39482 invoked by uid 89); 12 Sep 2017 08:54:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.5 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=behaviors, H*r:0800 X-HELO: szxga05-in.huawei.com Subject: Re: [RFC][PATCH] AArch64: use movz/movk instead of literal pools in start.S To: Andrew Pinski References: CC: , Szabolcs Nagy From: Boshi Wang Message-ID: <68118bc5-fd76-1fd1-b6cf-e9d2c82e8537@huawei.com> Date: Tue, 12 Sep 2017 08:54:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59B7A0B2.00C5,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6d7fb7cd7b1085b78b793ad790ef19f0 X-SW-Source: 2017-09/txt/msg00476.txt.bz2 On 2017/9/11 17:09, Andrew Pinski wrote: > On Thu, Sep 7, 2017 at 12:33 AM, 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. > 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 >> >> * 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. */ >> >>