Received-SPF: pass (google.com: domain of linux-kernel+bounces-159295-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: jeffxu@chromium.org
To: aruna.ramakrishna@oracle.com
Cc: andrew.brownsword@oracle.com,
	dave.hansen@linux.intel.com,
	linux-kernel@vger.kernel.org,
	matthias.neugschwandtner@oracle.com,
	tglx@linutronix.de,
	jeffxu@chromium.org,
	jeffxu@google.com,
	jannh@google.com,
	sroettger@google.com,
	x86@kernel.org
Subject: Re: [RFC PATCH v2 1/1] x86/pkeys: update PKRU to enable pkey 0 before XSAVE
Date: Thu, 25 Apr 2024 22:03:32 +0000
Message-ID: <20240425220332.3277193-1-jeffxu@chromium.org>
In-Reply-To: <Zf1TX3QXjWQsVp2R@gmail.com>
References: <Zf1TX3QXjWQsVp2R@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Jeff Xu <jeffxu@chromium.org>

Resend(previous email sent to the wrong thread)

>The semantics you've implemented for sigaltstacks are not the only possible 
>ones. In principle, a signal handler with its own stack might want to have 
>its own key(s) enabled. In a way a Linux signal handler is a mini-thread 
>created on the fly, with its own stack and its own attributes. Some thought 
>& analysis should go into which way to go here, and the best path should be 
>chosen. Fixing the SIGSEGV you observed should be a happy side effect of 
>other worthwile improvements.
>
This is exactly right. we wants to use altstack with its own pkey. The pkey
won't be writeable during thread's normal operation, only by signaling
handling itself.

Thanks
-Jeff

>Thanks,
>
>	Ingo
>