Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2295017pxb; Tue, 12 Oct 2021 03:38:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxsbNhdwd9bLWAdZ845ZTVd69U0IBbKQRruS3QsuY5wjepUvi2zIXvPvQtLBBUAOBT1xjNp X-Received: by 2002:a50:d844:: with SMTP id v4mr51295127edj.378.1634035097315; Tue, 12 Oct 2021 03:38:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634035097; cv=none; d=google.com; s=arc-20160816; b=wchIQKVO+lK8zBDWWlyZ28qgB583qFy9IoiAjRSOAurUJc6WY90sdtDZ7rMz/b8neF wR+FI+glZlua0Mi/87wztY4Xfq7xOD1H8LykMJiAmBUIN33nX2C00wx1QnPuN7d2I6Qy tfWiix03AUdv14AJjrxsE146tOM553k9EGqvfifUQzR9SqVTLX2x5QmSDk5f9xjmB343 QhQs5qxoPSlz8uS78N4GjvhPaU5mO+bvp/FfW8G3lBj1U0dja+tLUcRmJcRnVN2EyDcV RxCZ7fpsrCmo1gZCHomgi807KcKupNMOglmppekHoCg8jlGxPpruGcAjMWhD3FSbHXnd tDuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Zd7HH8xjPS277anp7AVHGXl11wuo7iH5UTX9lFK8Jik=; b=nnvhQy3smbpAU7o0vRMsQDyOqJWYfjhM1nwDRZ3jLyFdvMSE6s9X7dB794tzPdJHvh WizEMpg9q3V739wobq6+jMuEJCOx3SJCYB49NZYQu1uFJTzTlaIRGO4AckKo5EhkiYHF 2D6P2a8MJs59eFAIyeIF6DGHQ8PLa4ZyldltAMyTod+jsYWBx2CQmQ6P97RJVXse2KS4 OY+0hpWINHZqNEhDT/yPQ5nWaX6MGf2JR/RqmPIzPP/56qhYP9P7+etGhryDokXGpY7F 5fTW+l52bqY68ziqEeTZ37q+mOFxFlsfoVXr4FswXngksKs6pwz18tqLR3wDynvD0XYD PsNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=qs9HCnZU; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id nb16si22533637ejc.643.2021.10.12.03.37.53; Tue, 12 Oct 2021 03:38:17 -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; dkim=pass header.i=@google.com header.s=20210112 header.b=qs9HCnZU; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235900AbhJLKiE (ORCPT + 99 others); Tue, 12 Oct 2021 06:38:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235153AbhJLKiD (ORCPT ); Tue, 12 Oct 2021 06:38:03 -0400 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2160C061570 for ; Tue, 12 Oct 2021 03:36:01 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id y26so86625618lfa.11 for ; Tue, 12 Oct 2021 03:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Zd7HH8xjPS277anp7AVHGXl11wuo7iH5UTX9lFK8Jik=; b=qs9HCnZUsi4FMmOGxCOknKYuFP0jCo5vAxH5I56RZV1lzzgoIwLaZppRmTYYMRSm7h JyBwda8JgRwvdZJtKeN22PpOdblzTn1ZK6FVsnZDpGzKu7NFjht+xIi4fElnVHecQYwD /ERjXllLTrtEPVhCOIo3Qr19/zP5edzNIFRowQIK51/1o9RypQdOYmBY/9d9o54RXwOJ 8HKbGoLuxwL4zlhX1NxgbO9NT5EviEP6RZiWLluHS9yv1yww84C9qWmYdlPrgFmF87fJ YJRo3is8ue4TF2ZfYVCzISC6e+gaNZ0g6nfKhSHXHsDqZrxND7QxBbSVQDs88mcDx4Ko vgIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Zd7HH8xjPS277anp7AVHGXl11wuo7iH5UTX9lFK8Jik=; b=daZ+D0xt37pxjw32AB076P0srNtJtfYKqN9fysrPpR8IzNU2CHLeIjA+EQw3onuVmd 9g1iVhfE2x5jIxX5fgsrFcjkZyck12/24GjDX/vE7bN8JpGUzUtnMQL3HYoj/dsKoyLP fTsBYwyIpF5c+iF105qr2zqAMOi/jLmyHT7crxzL8TMdwk78sARJrtuhqNyDTFQuj176 tOsk/VT3SrGEs13kYo7lMQbwTJcQVq+1NZnFzFuyoH6ipe0qwSCZ5mT4RJEK7bxGS75F 1hd+4txU72J1U3rYCqkKmvnYCeDHzTMRNNENmW2X96Qv14yq27iqjRQPmipXoYA9dhHY /JhQ== X-Gm-Message-State: AOAM530ytRyifYa3j80kHdqiEmE+/mjSVmfm6Ptjmkq7nnaB7WIGUamz Z5DWqreonh+e3EPrNlZjU6EC29DY0rMUzH8Kur4yFIEy9Sqy8w== X-Received: by 2002:a2e:bc16:: with SMTP id b22mr30286158ljf.500.1634034959954; Tue, 12 Oct 2021 03:35:59 -0700 (PDT) MIME-Version: 1.0 References: <20211012083521.973587-1-woodylin@google.com> <87zgrek1gl.mognet@arm.com> In-Reply-To: <87zgrek1gl.mognet@arm.com> From: Woody Lin Date: Tue, 12 Oct 2021 18:35:48 +0800 Message-ID: Subject: Re: [PATCH] sched/scs: Reset the shadow stack when idle_task_exit To: Valentin Schneider Cc: Ingo Molnar , Ben Segall , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Mel Gorman , Daniel Bristot de Oliveira , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 12, 2021 at 6:00 PM Valentin Schneider wrote: > > On 12/10/21 16:35, Woody Lin wrote: > > There was a 'init_idle' that resets scs sp to base, but is removed by > > f1a0a376ca0c. Without the resetting, the hot-plugging implemented by > > cpu_psci_cpu_boot will use the previous scs sp as new base when starting > > up a CPU core, so the usage on scs page is being stacked up until > > overflow. > > > > This only happens on idle task since __cpu_up is using idle task as the > > main thread to start up a CPU core, so the overflow can be fixed by > > resetting scs sp to base in 'idle_task_exit'. > > > > Looking at init_idle() for similar issues, it looks like we might also want > to re-issue kasan_unpoison_task_stack() on the idle task upon hotplug. > > > Fixes: f1a0a376ca0c ("sched/core: Initialize the idle task with preemption disabled") > > Signed-off-by: Woody Lin > > --- > > kernel/sched/core.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > > index 1bba4128a3e6..f21714ea3db8 100644 > > --- a/kernel/sched/core.c > > +++ b/kernel/sched/core.c > > @@ -8795,6 +8795,7 @@ void idle_task_exit(void) > > finish_arch_post_lock_switch(); > > } > > > > + scs_task_reset(current); > > /* finish_cpu(), as ran on the BP, will clean up the active_mm state */ > > So AIUI for SCS that works just fine - one thing I'm unclear on is how the > following pops are going to work given the SP reset happens in the middle > of a call stack, but AFAICT that was already the case before I messed about > with init_idle(), so that must already be handled. Hi Valentin, Thanks for the question. The 'scs_task_reset' here resets only the '.thread_info.scs_sp' of the task, so the register (on arm64 it's x18) is still pointing to the same location for popping and storing call frames. The register will be updated to '.thread_info.scs_sp' in '__secondary_switched', which starts a new core and there is no popping after the updating, so it won't introduce an underflow. > > I'm not familiar enough with KASAN to say whether that > kasan_unpoison_task_stack() should rather happen upon hotplugging the CPU > back (rather than on hot-unplug). If that is the case, then maybe somewhere > around cpu_startup_entry() might work (and then you could bunch these two > "needs to be re-run at init for the idle task" functions into a common > helper). unpoison looks more like an one-time thing to me; the idle tasks will reuse the same stack pages until system resets, so I think we don't need to re-unpoison that during hotplugging as long as it's unpoisoned in 'init_idle'. > > > } > > > > -- > > 2.33.0.882.g93a45727a2-goog