From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x227wwdEKdBB9T2DatjN4RJn4a/M1szSv6UeUimePcOU5jTHVvWzjEebDffNunlOJsyC11gnQ ARC-Seal: i=1; a=rsa-sha256; t=1517170915; cv=none; d=google.com; s=arc-20160816; b=G7ZNmq0LHbq1k2x3yUdHH8V0yv/nV04sTMxTtMZbO7NH2zxeijYYfW19eBr5ITGO9K 1HjXz2ApIhfhDv4LE45/jtoug/Qu5rvmFQcKj7eLE+hn3P+Gx3aeHFhNvK30istTye9x 1Dnkp40JFHW6vmvRaKOuk9TgOgxDaGutnC4DcbHi6Epl+BQ5FxLtperIxQBJjRj0JQqQ AnoBBrp3iaTtQLhqNcGPdGui9523BmF5Al5c5LdTb40KALjxynq9kH9TUB4fDiGc2YiT OjjZA82tL/hXKzgx5BeiJNdaCSU8Ei4iPkwk50JC9eEXnGInoAd48KnCm/U55jtiFjal ECmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=subject:sender:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:cc:to:from:date:delivered-to :list-id:list-subscribe:list-unsubscribe:list-help:list-post :precedence:mailing-list:arc-authentication-results; bh=gajrZ73CAsclZB0a54dydl0Mve7wGEdj866IAVwIQos=; b=ZoA7YSxTtiJM505iKiS8xBMPqdbC9oHk1WyYNiQjQZV5xpG2ynMWSeOlpKL+XmtVjq Pl4qQsPhQOslCdv/wxW1MLlmjxhQ2TzgOnPACpJoOQtlNAlUdd6MYcKYdkhGTWiCGAHz 36E0muzWrAe3Y1p/EQW+IH8/Ng+ky2PMjFcqH8GV5bTvw9oXCtSUrohoIfL44wyrU5tE 3J5WeFy/p9OKmw5AXQPmtFlrc9UhhdL3aCR/b2CFxr6VyGeQXY3ZaThhRmEjUgdvEDMe rn47R3KWRBlh7+z0wPkvb/XEX9qQSsYDyzb7Nf0+BdeCUjOh3/o1IRj/1MiQMv8D3BCW 2ChQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11498-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11498-gregkh=linuxfoundation.org@lists.openwall.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11498-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11498-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: Date: Sun, 28 Jan 2018 20:21:28 +0000 From: Al Viro To: Linus Torvalds Cc: Andy Lutomirski , the arch/x86 maintainers , LKML , Kernel Hardening , Borislav Petkov Message-ID: <20180128202128.GI13338@ZenIV.linux.org.uk> References: <4dd5a4d0f6b694f17eaf64c80c36a2560993b9ea.1517164461.git.luto@kernel.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: Al Viro 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?1590869010215244401?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Sun, Jan 28, 2018 at 11:15:15AM -0800, Linus Torvalds wrote: > Is that "long long" part of the example on purpose? Because that's > likely the only really nasty part about any ptregs wrapper: some > arguments aren't _one_ register, they are two. And "long long" is the > simplest example, even though in practice the type is most often > "loff_t". > > You won't see this on 64-bit architectures, but it's visible on 32-bit ones. > > We may have to do wrappers for those, and error out for 'long long'. > We already do that for some cases, for compat system calls. See for > example > > COMPAT_SYSCALL_DEFINE5(preadv, compat_ulong_t, fd, > const struct compat_iovec __user *,vec, > compat_ulong_t, vlen, u32, pos_low, u32, pos_high) > { > loff_t pos = ((loff_t)pos_high << 32) | pos_low; > > return do_compat_preadv64(fd, vec, vlen, pos, 0); > } > > where we have the issue of a 64-bit value being split over two > registers even on 64-bit, due to it being a compat interface for 32 > bit. > > But if we pick up the values by hand from ptregs in a wrapper, we'll > have this issue even for native calls on 32-bit. ... 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". I tried to do something to reduce the amount of remaining wrappers several years ago. Trying to automate that gets very ugly very fast - there are architectures like mips where you get alignment requirements ($6/$7 can hold that, $5/$6 can't), creating padding arguments, etc. FWIW, that affects lookup_dcookie() (64,32,32) truncate64(), ftruncate64() (32,64) fadvise64_64(), sync_file_range() (32,64,64,32) readahead() (32,64,32) fadvise64() (32,64,32,32) fallocate(), sync_file_range2() (32,32,64,64) fanotify_mark() (32,32,64,32,32) pread64(), pwrite64() (32,32,32,64) Giving each of those a compat wrapper of its own is already annoying (looking at that again, we should at least unify pread64() and pwrite64() compat wrappers - grep for sys_pread64 and you'll see), but giving each an explicit wrapper for native ones? Ouch.