Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1664789pxk; Tue, 1 Sep 2020 04:51:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyytTnZch/BTlCYO8PJ+2gr21rEQfsgyF69a6NMvfGBhkRfoRGcbbq77yC3NT3K9uwS3CPU X-Received: by 2002:a50:de04:: with SMTP id z4mr1443433edk.10.1598961119185; Tue, 01 Sep 2020 04:51:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598961119; cv=none; d=google.com; s=arc-20160816; b=YTRdxfj15kK+AT0yoO1fs38Ik6ohFK//YhVwow+5dZYdKPGP3fEMZXPkiXK30kjxHi 0q/8hD/7/pWceeUCtg5eUDHG/HEMWv6VeZx8q61wcXSjkCU+rwaZnhUtW30nUwv8Zl/V F4kt4nL7JrIDnlCEhuDY8bz2G7KmKkKmnKJzvHNLxAuvetm7hUz40W8RB0xq2fiOSJBj LlFnDzpF8hudHM0g0vQEmvxQ0ovwiTqBgeQc+Li7sKsDH/AKU7TaHxXEuUvwsJx8ikk7 RFd5nWTAGwl5KxziyxMyN0tEJlD4nzSQC3CaQKFkOiIG/p18VOBHTjRmiu3xWD1fCGDr Fbvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=KGrBoAj6E6NT5X95i686WxEyeQaqeSkYYi04Xj68Y+E=; b=DrvD9wVAQlfzGtx+2oj6GJxwPuD0GBe4H3iPJ9k22Q4d1E29hK9KrcBL/MQhkrklHx CNyZkXFxfUACr4/nTLVxHj3NrlW1O4ByJAdpaTZMXwI/0/T+ve5VuhZIwWYmPLT9hjx6 AzeMmyV0etuWPzFYpja3Pu+ai+ADd9XXNMkXWvdrMdTIMDj2UEi2sLOy/p/t0an1uiUz MbzbcIZnkA+zoHLk4CnR2y/ZlPb/XvokQDL2vn4B8VFVUwvnltqnjS5UpGeyHjTwHmJu 8T+e9/sNUC507wIgKnvFIxVL3B0MsQGdkquYGHsPXZxytaKjr4hZ4vsXF39tC5wvRRb6 8dYA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id zh8si495112ejb.475.2020.09.01.04.51.34; Tue, 01 Sep 2020 04:51:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727792AbgIALtw (ORCPT + 99 others); Tue, 1 Sep 2020 07:49:52 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:54224 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727051AbgIALl4 (ORCPT ); Tue, 1 Sep 2020 07:41:56 -0400 Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id D2EBBA84ABBB3ABEA869; Tue, 1 Sep 2020 19:41:03 +0800 (CST) Received: from [127.0.0.1] (10.174.178.16) by DGGEMS412-HUB.china.huawei.com (10.3.19.212) with Microsoft SMTP Server id 14.3.487.0; Tue, 1 Sep 2020 19:40:56 +0800 Subject: Re: [Question] About SECCOMP issue for ILP32 To: Yury Norov CC: , Catalin Marinas , Arnd Bergmann , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-api@vger.kernel.org" , Adam Borowski , "Alexander Graf" , Alexey Klimov , Andreas Schwab , Andrew Pinski , Bamvor Zhangjian , Chris Metcalf , "Christoph Muellner" , Dave Martin , "David S . Miller" , "Florian Weimer" , Geert Uytterhoeven , "Heiko Carstens" , James Hogan , James Morse , Joseph Myers , Lin Yongting , Manuel Montezelo , Mark Brown , "Martin Schwidefsky" , Maxim Kuvyrkov , Nathan_Lynch , "Philipp Tomsich" , Prasun Kapoor , Ramana Radhakrishnan , Steve Ellcey , Szabolcs Nagy References: <30b491ad-a7e1-f7b5-26b8-2cfffc81a080@huawei.com> From: Xiongfeng Wang Message-ID: <695fc573-25ce-b2e5-e61c-140d9ee241e2@huawei.com> Date: Tue, 1 Sep 2020 19:40:54 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.16] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/9/1 2:15, Yury Norov wrote: > On Mon, Aug 31, 2020 at 5:48 AM Xiongfeng Wang > wrote: >> >> Hi Yury, >> > > Hi Xiongfeng, > > [restore CC list] > > Haven't seen this before. What kernel / glibc / ltp do you use? The kernel version is 4.19. I applied the ILP32 patches from https://github.com/norov/linux.git. The glibc version is 2.28 and I applyed the ILP32 patches. The ltp testsuite is from https://github.com/linux-test-project/ltp. I build it with '-mabi=ilp32'. > >> We were testing the ILP32 feature and came accross a problem. Very apperaciate >> it if you could give us some help ! >> >> We compile the LTP testsuite with '-mabi=ilp32' and run it on a machine with >> kernel and glibc applied with ILP32 patches. But we failed on one testcase, >> prctl04. It print the following error info. >> 'prctl04.c:199: FAIL: SECCOMP_MODE_STRICT doesn't permit read(2) write(2) and >> _exit(2)' >> >> The testcase is like below, syscall 'prctl' followed by a syscall 'write'. >> prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT); >> SAFE_WRITE(1, fd, "a", 1); >> >> When we execute syscall 'write', we receive a SIGKILL. It's not as expected. >> We track the kernel and found out it is because we failed the syscall_whitelist >> check in '__secure_computing_strict'. Because flag 'TIF_32BIT_AARCH64' is set, >> we falls into the 'in_compat_syscall()' branch. We compare the parameter >> 'this_syscall' with return value of 'get_compat_model_syscalls()' >> The syscall number of '__NR_write' for ilp32 application is 64, but it is 4 for >> 'model_syscalls_32' returned from 'get_compat_model_syscalls()' >> So '__secure_computing_strict' retuned with 'do_exit(SIGKILL)'. We have a >> modification like below, but I am not sure if it correct or not. >> >> --- a/kernel/seccomp.c >> +++ b/kernel/seccomp.c >> @@ -618,7 +618,7 @@ static void __secure_computing_strict(int this_syscall) >> { >> const int *syscall_whitelist = mode1_syscalls; >> #ifdef CONFIG_COMPAT >> - if (in_compat_syscall()) >> + if (is_a32_compat_task()) >> syscall_whitelist = get_compat_mode1_syscalls(); > > It calls the arch function from generic code. It may break build for > other arches. > This also looks dangerous because it treats ILP32 execution as non-compat. > > The right approach would be implementing arch-specific > get_compat_mode1_syscalls() > in arch/arm64/include/asm/seccomp.h that returns an appropriate table. > Refer MIPS > code for this: arch/mips/include/asm/seccomp.h Thanks for your advice. Thanks a lot. I have written another version according to your advice. --- a/arch/arm64/include/asm/seccomp.h +++ b/arch/arm64/include/asm/seccomp.h @@ -20,6 +20,36 @@ #define __NR_seccomp_sigreturn_32 __NR_compat_rt_sigreturn #endif /* CONFIG_COMPAT */ +#ifdef CONFIG_COMPAT +#ifndef __COMPAT_SYSCALL_NR + +static inline const int *get_compat_mode1_syscalls(void) +{ +#ifdef CONFIG_AARCH32_EL0 + static const int mode1_syscalls_a32[] = { + __NR_compat_read, __NR_compat_write, + __NR_compat_read, __NR_compat_sigreturn, + 0, /* null terminated */ + }; +#endif + static const int mode1_syscalls_ilp32[] = { + __NR_read, __NR_write, + __NR_exit, __NR_rt_sigreturn, + 0, /* null terminated */ + }; + + if (is_ilp32_compat_task()) + return mode1_syscalls_ilp32; +#ifdef CONFIG_AARCH32_EL0 + return mode1_syscalls_a32; +#endif +} + +#define get_compat_mode1_syscalls get_compat_mode1_syscalls + +#endif +#endif + #include #endif /* _ASM_SECCOMP_H */ Thanks, Xiongfeng > > Thanks, > Yury > >> #endif >> do { >> >> >> Thanks, >> Xiongfeng >> > > . >