From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x22764xzIfOfvQz6s4POTpzYtyfABCQkX9auGT/adsTkKWgen0WyiSNlA2O8/ft63RHNNQnMy ARC-Seal: i=1; a=rsa-sha256; t=1517172164; cv=none; d=google.com; s=arc-20160816; b=yZ1+VO5ZLi2tc2bHcJ5NXoJQYAhT/QSEUVEvFvc0YuR5bx7Dghc9Trw0Awh4Rwc1X7 23n9f/5DFp14wCkPJ2hkpz22snD+Ju0Fm1yXeOV06C7+MHQ/ZxZHDv3mXB/Mtz5ujGrg 2GXKeDkg3K/fkrmbCOSpisrGoedHLDLrr4SPZPPraVGtOjqujAuXjDa8OVZpWdXYxF8N EfQcZC6pm1xk6Y/S6ZyY9+qWdKEVeOsjO/bH0jObqoHjK2SAgDT2EvFJ1tzNotknjhPP v7obhwJN3vuLZSZNg+lj9EtzL84QCjlHJz4YDHbo5rNCcr3M+aarIjh7C9eifCjoSely D8CA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=subject:cc:to:message-id:date:from:references:in-reply-to:sender :mime-version:dkim-signature:delivered-to:list-id:list-subscribe :list-unsubscribe:list-help:list-post:precedence:mailing-list :arc-authentication-results; bh=DkruRkOKmsBXxSeRax2FnWNU+DaRAHGAfoWm1BOug1g=; b=NHBFpeXBElIlpDViulD2vWcIVScA2chRowTYFHd9/V/yNPb+bS+mMhIfTnvT0xu+R+ 6OfNvM0vkzy3pDmD6EjpyankCzOVo1Rn4UDHa4vCZpuVH/LW0nrobRJPE1vn8hwsk+EW EC1nv2tsTw8O/RNC7Q8FBUD/mQa8BBjmY/3TQK/4rleFxkct4vWbFVWtJYDytwGDnMRq g4Zrg99heuc28/HJopfsW4QgpZC1eHP/eX8tw/hTwx8cXsozz1jHu8hbjqQeV5bLgcHI zjS9GuOuz5J3etv0kE/ri89l13X53lb5M2MgE/duJTmzZRJSoM7+w8nPV4gqZNIqBxFJ 3l1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=vLaHvkkh; spf=pass (google.com: domain of kernel-hardening-return-11499-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11499-gregkh=linuxfoundation.org@lists.openwall.com Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=vLaHvkkh; spf=pass (google.com: domain of kernel-hardening-return-11499-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11499-gregkh=linuxfoundation.org@lists.openwall.com Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: MIME-Version: 1.0 Sender: linus971@gmail.com In-Reply-To: <20180128202128.GI13338@ZenIV.linux.org.uk> References: <4dd5a4d0f6b694f17eaf64c80c36a2560993b9ea.1517164461.git.luto@kernel.org> <20180128202128.GI13338@ZenIV.linux.org.uk> From: Linus Torvalds Date: Sun, 28 Jan 2018 12:42:24 -0800 X-Google-Sender-Auth: 9VqHkaVqk6KuPk-CYQFIZXKLkAk Message-ID: To: Al Viro Cc: Andy Lutomirski , "the arch/x86 maintainers" , LKML , Kernel Hardening , Borislav Petkov Content-Type: text/plain; charset="UTF-8" Subject: [kernel-hardening] Re: [PATCH 3/3] syscalls: Add a bit of documentation to __SYSCALL_DEFINE X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590862555674165882?= X-GMAIL-MSGID: =?utf-8?q?1590870319647764481?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Sun, Jan 28, 2018 at 12:21 PM, Al Viro wrote: > > ... and have more of that logics arch-dependent than one might expect; > it's *not* just "split each 64bit argument into a pair of 32bit ones, > combine in the body". Right. The paired registers tend to have special arch-specific rules, making this particularly painful. I suspect that the best solution (and here "best" doesn't mean "pretty", but doable) is to rely on some of the limits we have: In particular, we don't want to convert all architectures to the ptregs approach _anyway_, so we need to have a model where the architecture sets up some config option. End result: we don't have to handle the generic case, we just have to have a way for an architecture to set up for this. And for a _first_ implementation, we can simply just limit things to x86-64 (and then maybe arm64) which don't even have this issue. Longer-term, the other thing that helps us is that we have already limited our calling convention to a maximum of six registers (NOTE! Not six _arguments_). So even when we want to handle the 32-bit case, the combinatorial space is at least fairly limited, and we can make the compiler notice them (ie the ptregs accessor case can simply be made to error out if you try to access a 64-bit type from one single register). End result: we will need the per-architecture macros that access arguments from the 'struct ptregs', so we'll have some macro for "argument1(ptregs)". The 64-bit argument for 32-bit case would end up having to have a few more of those architecture-specific oddities. So not just "argument1(ptregs)", but "argument2_32_64(ptregs)" or something that says "get me argument 2, when the first argument is 32-bit and I want a 64-bit one". So _if_ a 32-bit architecture wants this, such an architecture would probably have to implement 10-20 of those odd special cases. They'll be ugly and nasty and have little sanity to them, but they'd be simple one-liners. So hacky. But not necessarily even needed (I really don't think the kind of people who care about paranoid security are going to run 32-bit kernels), and if people want to, not _complicated_, just annoying. Linus