Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp4372067ybg; Mon, 8 Jun 2020 06:20:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxJRAAAfUM+IxrRss30ZBeyoUIG6rDW6KxEZ9u+oZjBK+ZzRzt3eKZqBBPNkfc6sefvVXuL X-Received: by 2002:a17:906:7f05:: with SMTP id d5mr20340387ejr.70.1591622447164; Mon, 08 Jun 2020 06:20:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591622447; cv=none; d=google.com; s=arc-20160816; b=BGtXTKvSAnPq43a3e7jXiteWXP3qlbKIoWc8RUl6eTF5jGv8B0yrmmRAez0CqsazMK tBjVDfpER7nkbRue/+rxnFH8r73xwtTNjomkAJY7xqAAcRNtP50K4vxx9Qf/IhRSr/5O NPJeFcDpulW+RPHW5kSrpM9Ba1pvgMZIyBT32Gu4m0VdSLaBQmXezIHcestepSHdf+/k TfUH+B4nP6YqP2a37pkKLGwb4PiUIMicQECsTto7H0nxOpEi47clw+61fpUdCtwi4rqA 7HUyU5+5YAFO6iBXhaT5Pjmhl4VhY5UShXDuFeAUojO9lDGI4BFrcCFMuQHBub/dxlTS AHyA== 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=503Ahay1u+plON++0+OIUJaQfOL7Uep8FxxZG9tbf5k=; b=h+zisHF+2o90RxEVdpcl/LbhUWG9R3XimF6mOlftu6G2+0QzD8544dD68wHA9gNgTU c+S/c0xKYfTnuhVRonui77K6WpuUTdzLfrf7OV5bf/8hkgyOYFe2SAYkX/xAfwQU/s7/ Fvcz4IyKpFAfogNb88dOZl3EOiQQrFIi3u3tJh18slJNyfkp19V8ikQJ9q8FE3+E3aj0 OVAwdIXOmTP+M9N8ZcQlX9DbmzrWA0IILCMJmKmILRW6fpGjvHCZL/qqXxF7n7MM2mq/ 0Lqd2z86JnDxWzbFBsMFS0BVHOe/Eso69GGbCh2/mXnibU2P2ODtqm1RzF5+IvQnWgeA qNJA== 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 gq19si7397663ejb.682.2020.06.08.06.20.23; Mon, 08 Jun 2020 06:20:47 -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 S1729543AbgFHNRI (ORCPT + 99 others); Mon, 8 Jun 2020 09:17:08 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:5869 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728938AbgFHNRH (ORCPT ); Mon, 8 Jun 2020 09:17:07 -0400 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 48AF61A9D3AE874509E3; Mon, 8 Jun 2020 21:17:02 +0800 (CST) Received: from [127.0.0.1] (10.166.213.10) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.487.0; Mon, 8 Jun 2020 21:16:55 +0800 Subject: Re: [RESEND PATCH] sys_personality: Add optional arch hook arch_check_personality To: Catalin Marinas CC: , , , , , , , , , , Will Deacon References: <20200608024925.42510-1-bobo.shaobowang@huawei.com> <20200608094640.GA13596@gaia> From: "Wangshaobo (bobo)" Message-ID: Date: Mon, 8 Jun 2020 21:16:53 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <20200608094640.GA13596@gaia> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.166.213.10] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ?? 2020/6/8 17:46, Catalin Marinas ะด??: > On Mon, Jun 08, 2020 at 10:49:25AM +0800, Wang ShaoBo wrote: >> Currently arm64 personality syscall uses wrapper __arm64_sys_personality >> to redirect to __arm64_sys_arm64_personality, it's easily confused, >> Whereas using an normal hook arch_check_personality() can reject >> additional settings like this for special case of different architectures. >> >> This makes code clean and easier for subsequent modification. > Do you plan to add more stuff here? Curious what triggered this patch. > >> diff --git a/arch/arm64/kernel/sys.c b/arch/arm64/kernel/sys.c >> index d5ffaaab31a7..5c01816d7a77 100644 >> --- a/arch/arm64/kernel/sys.c >> +++ b/arch/arm64/kernel/sys.c >> @@ -28,12 +28,13 @@ SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, len, >> return ksys_mmap_pgoff(addr, len, prot, flags, fd, off >> PAGE_SHIFT); >> } >> >> -SYSCALL_DEFINE1(arm64_personality, unsigned int, personality) >> +int arch_check_personality(unsigned int personality) >> { >> if (personality(personality) == PER_LINUX32 && >> !system_supports_32bit_el0()) >> return -EINVAL; >> - return ksys_personality(personality); >> + >> + return 0; >> } > We use the ksys_* pattern in other places as well, so this wouldn't be > something new. > >> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h >> index 1815065d52f3..3dbbad498027 100644 >> --- a/include/linux/syscalls.h >> +++ b/include/linux/syscalls.h >> @@ -1393,16 +1393,6 @@ static inline long ksys_truncate(const char __user *pathname, loff_t length) >> return do_sys_truncate(pathname, length); >> } >> >> -static inline unsigned int ksys_personality(unsigned int personality) >> -{ >> - unsigned int old = current->personality; >> - >> - if (personality != 0xffffffff) >> - set_personality(personality); >> - >> - return old; >> -} >> - >> /* for __ARCH_WANT_SYS_IPC */ >> long ksys_semtimedop(int semid, struct sembuf __user *tsops, >> unsigned int nsops, >> diff --git a/kernel/exec_domain.c b/kernel/exec_domain.c >> index 33f07c5f2515..f3682f4bf205 100644 >> --- a/kernel/exec_domain.c >> +++ b/kernel/exec_domain.c >> @@ -35,9 +35,21 @@ static int __init proc_execdomains_init(void) >> module_init(proc_execdomains_init); >> #endif >> >> +int __weak arch_check_personality(unsigned int personality) >> +{ >> + return 0; >> +} >> + >> SYSCALL_DEFINE1(personality, unsigned int, personality) >> { >> - unsigned int old = current->personality; >> + int err; >> + unsigned int old; >> + >> + err = arch_check_personality(personality); >> + if (err) >> + return err; >> + >> + old = current->personality; > I'm surprised that the generic sys_personality() doesn't call > ksys_personality() directly but rather duplicates the code. > > Anyway, without knowing what else you plan to do with > arch_check_personality(), I don't think it's worth changing. Calling > ksys_personality() directly from sys_personality() would be a good > clean-up though. Hi catalin, I have sent a version just calling ksys_personality() directly from sys_personality() before: https://lore.kernel.org/patchwork/patch/1158872/ thanks, Wang ShaoBo >