Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp706375imu; Tue, 27 Nov 2018 20:41:11 -0800 (PST) X-Google-Smtp-Source: AJdET5dW16gwxKFFgUMMEijU8gRqHEonouwVFwj3+31b6YWG5Pm3tkcwRoGkJlbX1I7E0++LUl3c X-Received: by 2002:a62:d148:: with SMTP id t8mr36753523pfl.52.1543380071574; Tue, 27 Nov 2018 20:41:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543380071; cv=none; d=google.com; s=arc-20160816; b=ploDL35IkXhNydJHvxqzXTLiB2SgmYhtxAEkQPClCo1/m5WCSvD1NQQctcSjC7jJbc WkThGb8CZwGi+Kbio8cKu4037kT/BNu7wEnJ5ik3RcXMbl9lGESm2gwlwnDXHeGg0Zrt Un1bTfMcflFXf+BVN8LCn1SBMzehHMevRLf5MiIE2oU5qiQBokTVoOudj3VGVgZXnkG2 CTCm5cwQzWLxwIexE0HLu/pysqf5ozraarv95WC3778SRl+/NN07y4i1fr4sib4L6Nsf g+P6CFV9yH10O3zXRuOw+/CHqG1pb3jio9gx1D61lgk5qszZUnbcwjctPKeSKgWQMHJ6 4kiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:references:message-id:date :thread-index:thread-topic:subject:cc:to:from; bh=FBPDgMrmWDnV4A23vs8wOF1uHV118Q11G+soJh3ZJK8=; b=QXKJPlXL/3uSDp0ZWHTqtWTUgOIiRtOozsmliV/w/PTAqbHxUW95onzx592oRjF+mn YMfGbhb2SHgustabPjQ5voNNP6LOXm3yzisQmZO3YuHzA9ZVCE+H2l0uXans6jSd4P3B 53pJlpRE7WE+ihUw8avrmXodjSbKZSU/xbGUYV7Vq5Ua7VOCEWpyLgabNs+hVyaXchm6 Nshf5w6Z1DSzucON7/d0WnDtZf+jnsb2iOhRRaP1BgePNK+/5SXh7l7GfHVwOh7nCKg3 uy0+crc8zrbBbF/QPGkhVdUTMzh2RkF3ekpSyaujJKVklSgIIM9823dyA2TIx2sBwEiE D7ag== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q9si5542294pgi.89.2018.11.27.20.40.56; Tue, 27 Nov 2018 20:41:11 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727457AbeK1Pi4 convert rfc822-to-8bit (ORCPT + 99 others); Wed, 28 Nov 2018 10:38:56 -0500 Received: from mx01.hxt-semitech.com ([223.203.96.7]:39092 "EHLO barracuda.hxt-semitech.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727413AbeK1Pi4 (ORCPT ); Wed, 28 Nov 2018 10:38:56 -0500 X-ASG-Debug-ID: 1543379900-093b7e197b1ceb0001-xx1T2L Received: from HXTBJIDCEMVIW02.hxtcorp.net ([10.128.0.15]) by barracuda.hxt-semitech.com with ESMTP id 2RwIQFazNHIELgjN (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 28 Nov 2018 12:38:20 +0800 (CST) X-Barracuda-Envelope-From: dongsheng.wang@hxt-semitech.com Received: from HXTBJIDCEMVIW02.hxtcorp.net (10.128.0.15) by HXTBJIDCEMVIW02.hxtcorp.net (10.128.0.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 28 Nov 2018 12:37:35 +0800 Received: from HXTBJIDCEMVIW02.hxtcorp.net ([fe80::3e:f4ff:7927:a6f6]) by HXTBJIDCEMVIW02.hxtcorp.net ([fe80::3e:f4ff:7927:a6f6%12]) with mapi id 15.00.1395.000; Wed, 28 Nov 2018 12:37:35 +0800 From: "Wang, Dongsheng" To: Kees Cook CC: David Howells , Thomas Gleixner , Ingo Molnar , Andrew Morton , Masahiro Yamada , Tony Luck , Will Deacon , Palmer Dabbelt , "Zheng, Joey" , LKML , "Yang, Shunyong" , "gregkh@linuxfoundation.org" , "stable@vger.kernel.org" Subject: Re: [PATCH 1/1] sched/headers: fix thread_info. is overwritten by STACK_END_MAGIC Thread-Topic: [PATCH 1/1] sched/headers: fix thread_info. is overwritten by STACK_END_MAGIC X-ASG-Orig-Subj: Re: [PATCH 1/1] sched/headers: fix thread_info. is overwritten by STACK_END_MAGIC Thread-Index: AQHUgwHXQvH51CSg9UWtTixRCjaq8A== Date: Wed, 28 Nov 2018 04:37:35 +0000 Message-ID: <19391812db6444f3bd260546acded9b7@HXTBJIDCEMVIW02.hxtcorp.net> References: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.6.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[10.128.0.15] X-Barracuda-Start-Time: 1543379900 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://192.168.50.101:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at hxt-semitech.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4999 1.0000 0.0000 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.62582 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Kees, On 2018/11/28 6:38, Kees Cook wrote: > On Thu, Nov 22, 2018 at 11:54 PM, Wang Dongsheng > wrote: >> When select ARCH_TASK_STRUCT_ON_STACK the first of thread_info variable >> is overwritten by STACK_END_MAGIC. In fact, the ARCH_TASK_STRUCT_ON_STACK >> is not a real task on stack, it's only init_task on init_stack. >> >> Commit 0500871f21b2 ("Construct init thread stack in the linker script >> rather than by union") added this macro and put task_strcut into >> thread_union. This brings us the following possibilities: >> TASK_ON_STACK THREAD_INFO_IN_TASK STACK >> ----- <-- thread_info & stack >> N N | | --- <-- task >> | | | | >> ----- --- >> >> ----- <-- stack >> N Y | | --- <-- task(Including thread_info) >> | | | | >> ----- --- >> >> ----- <-- stack & task & thread_info >> Y N | | >> | | >> ----- >> >> ----- <-- stack & task(Including thread_info) >> Y Y | | >> | | >> ----- >> The kernel has handled the first two cases correctly. >> >> For the third case: >> TASK_ON_STACK: Y. THREAD_INFO_IN_TASK: N. this case >> should never happen, because the task and thread_info will overlap. So >> when TASK_ON_STACK is selected, THREAD_INFO_IN_TASK must be selected too. >> >> For the fourth case: >> When task on stack, the end of stack should add a sizeof(task_struct) offset. >> >> This patch handled with the third and fourth case. >> >> Fixes: 0500871f21b2 ("Construct init thread stack in the linker ...") >> >> Signed-off-by: Wang Dongsheng >> Signed-off-by: Shunyong Yang >> --- >> arch/Kconfig | 1 + >> include/linux/sched/task_stack.h | 5 ++++- >> 2 files changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/arch/Kconfig b/arch/Kconfig >> index e1e540ffa979..0a2c73e73195 100644 >> --- a/arch/Kconfig >> +++ b/arch/Kconfig >> @@ -251,6 +251,7 @@ config ARCH_HAS_SET_MEMORY >> # Select if arch init_task must go in the __init_task_data section >> config ARCH_TASK_STRUCT_ON_STACK >> bool >> + depends on THREAD_INFO_IN_TASK || IA64 > The "IA64" part shouldn't be needed since IA64 already selects it. > > Since it's selected, it also can't have a depends, IIUC. Since the IA64 thread_info including task_struct, it doesn't need to select THREAD_INFO_IN_TASK. So we need to allow IA64 select ARCH_TASK_STRUCT_ON_STACK without THREAD_INFO. >> # Select if arch has its private alloc_task_struct() function >> config ARCH_TASK_STRUCT_ALLOCATOR >> diff --git a/include/linux/sched/task_stack.h b/include/linux/sched/task_stack.h >> index 6a841929073f..624c48defb9e 100644 >> --- a/include/linux/sched/task_stack.h >> +++ b/include/linux/sched/task_stack.h >> @@ -7,6 +7,7 @@ >> */ >> >> #include >> +#include >> #include >> >> #ifdef CONFIG_THREAD_INFO_IN_TASK >> @@ -25,7 +26,9 @@ static inline void *task_stack_page(const struct task_struct *task) >> >> static inline unsigned long *end_of_stack(const struct task_struct *task) >> { >> - return task->stack; >> + if (!IS_ENABLED(CONFIG_ARCH_TASK_STRUCT_ON_STACK) || task != &init_task) >> + return task->stack; >> + return (unsigned long *)(task + 1); >> } > This seems like a strange place for the change. It feels more like > init_task has been defined incorrectly. The init_task will put into init_stack when ARCH_TASK_STRUCT_ON_STACK is selected. include/asm-generic/vmlinux.lds.h: #define INIT_TASK_DATA(align) \ . = ALIGN(align); \ __start_init_task = .; \ init_thread_union = .; \ init_stack = .; \ KEEP(*(.data..init_task)) \ KEEP(*(.data..init_thread_info)) \ . = __start_init_task + THREAD_SIZE; \ __end_init_task = .; So we need end_of_stack to offset sizeof(task_struct). Cheers, Dongsheng