Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965427AbeAJEiG (ORCPT + 1 other); Tue, 9 Jan 2018 23:38:06 -0500 Received: from mga06.intel.com ([134.134.136.31]:53783 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965412AbeAJEiF (ORCPT ); Tue, 9 Jan 2018 23:38:05 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,338,1511856000"; d="scan'208";a="8483014" Date: Tue, 9 Jan 2018 20:37:51 -0800 From: Andi Kleen To: Andy Lutomirski Cc: Andi Kleen , tglx@linutronix.de, x86@kernel.org, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, dwmw@amazon.co.uk, pjt@google.com, luto@kernel.org, peterz@infradead.org, thomas.lendacky@amd.com, tim.c.chen@linux.intel.com, gregkh@linux-foundation.org, dave.hansen@intel.com, jikos@kernel.org Subject: Re: [PATCH v1 6/8] x86/entry/clearregs: Add number of arguments to syscall tables Message-ID: <20180110043751.GK6718@tassilo.jf.intel.com> References: <20180110010328.22163-1-andi@firstfloor.org> <20180110010328.22163-7-andi@firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Tue, Jan 09, 2018 at 05:26:43PM -0800, Andy Lutomirski wrote: > > > > On Jan 9, 2018, at 5:03 PM, Andi Kleen wrote: > > > > From: Andi Kleen > > > > In order to sanitize the system call arguments properly > > we need to know the number of syscall arguments for each > > syscall. Add a new column to the 32bit and 64bit syscall > > tables to list the number of arguments. > > > > Surely we can do this in the SYSCALL_DEFINE macros. Or at least statically check it. Possibly. The assembler would be much uglier as inline assembler though. And adding the number shouldn't be a big burden when adding a system call. I don't know how to check statically. > > Also, what attack are we protecting against anyway? There's no specific attack here. But the idea is to make it harder to inject values into the kernel to abuse with speculation. -Andi