From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965112AbbLRUHT (ORCPT ); Fri, 18 Dec 2015 15:07:19 -0500 Received: from mga01.intel.com ([192.55.52.88]:59803 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932736AbbLRUHR (ORCPT ); Fri, 18 Dec 2015 15:07:17 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,447,1444719600"; d="scan'208";a="710612242" Subject: Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? To: Andy Lutomirski References: <56736BD1.5080700@linux.intel.com> <5673750B.606@linux.intel.com> <567453AF.5060808@linux.intel.com> Cc: "H. Peter Anvin" , Oleg Nesterov , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Brian Gerst , "linux-kernel@vger.kernel.org" , Linus Torvalds , Christoph Hellwig From: Dave Hansen Message-ID: <56746774.8000707@linux.intel.com> Date: Fri, 18 Dec 2015 12:07:16 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/18/2015 11:21 AM, Andy Lutomirski wrote: > On Fri, Dec 18, 2015 at 10:42 AM, Dave Hansen > wrote: >> On 12/18/2015 08:04 AM, Andy Lutomirski wrote: >>> 1b. If the app malfunctions such that RSP points to pmem, the kernel >>> MUST NOT clobber the pmem space. I think that this basically mandates >>> that PKRU needs to have some safe state (i.e. definitely not the init >>> state) on signal delivery: the kernel is going to write a signal frame >>> at the address identified by RSP, and that address is in pmem, so >>> those writes need to fail. >> >> The kernel is writing the signal frame using normal old copy_to_user(). >> Those are writing through mappings with _PAGE_USER set and should be >> subject to the PKRU state of the thread before the signal started to be >> delivered. >> >> We don't do the fpu__clear() until after this copy, so I think pkeys >> enforcement is being done properly for this today. > > True, but I think only in a very limited sense. Your average signal > handler is reasonably like to execute "push $rbp" as its very first > instruction, at which point we're immediately screwed with the current > arrangement. I completely agree that there's a window for corruption. But, I think it's a small one. Basically, RSP would have to pointing at a place which was allowed by protection keys for all of the sigframe setup. Then, _just_ happened to be at a place which was denied by protection keys when it enters the signal handler back in userspace. It's possible, but it's a small window.