From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH v2 2/2] rusage: allow 64-bit times ru_utime/ru_stime Date: Sun, 24 Jun 2018 20:26:08 -0500 Message-ID: <87y3f31wsv.fsf@xmission.com> References: <20180420120605.1612248-1-arnd@arndb.de> <20180420120605.1612248-2-arnd@arndb.de> <20180621154915.GA31947@gmail.com> <20180621161121.GB7222@gmail.com> <20180622021636.GA11266@gmail.com> <87a7rm3eb5.fsf@xmission.com> <20180624071258.GB29407@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20180624071258.GB29407@gmail.com> (Ingo Molnar's message of "Sun, 24 Jun 2018 09:12:58 +0200") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: y2038-bounces@lists.linaro.org Sender: "Y2038" To: Ingo Molnar Cc: linux-arch , Paul Eggert , Andrew Morton , Arnd Bergmann , y2038 Mailman List , Linux API , the arch/x86 maintainers , Linux Kernel Mailing List , Dominik Brodowski , Deepa Dinamani , Ivan Kokshaysky , Al Viro , linux-alpha@vger.kernel.org, Matt Turner , Thomas Gleixner , Richard Henderson List-Id: linux-arch.vger.kernel.org SW5nbyBNb2xuYXIgPG1pbmdvQGtlcm5lbC5vcmc+IHdyaXRlczoKCj4gKiBFcmljIFcuIEJpZWRl cm1hbiA8ZWJpZWRlcm1AeG1pc3Npb24uY29tPiB3cm90ZToKPgo+PiBUaGUgdHJvdWJsZSB3aXRo IGF0dHJpYnV0ZXMgaXMgdGhhdCBtZWFucyB5b3UgY2FuJ3QgZmlsdGVyIHlvdXIgc3lzdGVtCj4+ IGNhbGwgYXJndW1lbnRzIHdpdGggc2VjY29tcC4gWy4uLl0KPgo+IFRoZXJlJ3Mgbm90aGluZyBr ZWVwaW5nIHNlY2NvbXAgZnJvbSBzZWN1cmVseSBmZXRjaGluZyB0aG9zZSBhcmd1bWVudHMgYW5k IAo+IGV4dGVuZGluZyBmaWx0ZXJpbmcgdG8gdGhlbSBhcyB3ZWxsIC4uLgo+Cj4gQWxsb3dpbmcg dGhhdCB3b3VsZCBtYWtlIHNlbnNlIGZvciBhIGxvdCBvZiBvdGhlciBzeXN0ZW0gY2FsbHMgYXMK PiB3ZWxsLgoKUG9zc2libHkuICBUaGUgY2hhbGxlbmdlIGlzIHRoYXQgaWYgdGhlIGZldGNoIGZv ciB0aGUga2VybmVsIHRvIHVzZQp0aG9zZSBhcmd1bWVudHMgaXMgZGlmZmVyZW50IGZyb20gdGhl IGZldGNoIG9mIHNlY2NvbXAgdG8gdGVzdCB0aG9zZQphcmd1bWVudHMgeW91IGhhdmUgYSB0aW1l IG9mIHRlc3QgdnMgdGltZSBvZiB1c2UgcmFjZS4KCkdpdmVuIHRoZSBsb2NhdGlvbiBvZiB0aGUg c2VjY29tcCBob29rIGF0IHRoZSBrZXJuZWwgdXNlciBzcGFjZSBib3JkZXIKdGhlcmUgaXMgbm8g ZWFzeSB3YXkgZm9yIHNlY2NvbXAgdG8gc2hhcmUgdGhlIGZldGNoIHdpdGggdGhlIHN5c3RlbQpj YWxsIGl0c2VsZi4KClNvIEkgZG9uJ3Qgc2VlIGhvdyBzZWNjb21wIGNvdWxkIHBlcmZvcm0gdGhl IGZldGNoIHNlY3VyZWx5LgoKRXJpYwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpZMjAzOCBtYWlsaW5nIGxpc3QKWTIwMzhAbGlzdHMubGluYXJvLm9yZwpo dHRwczovL2xpc3RzLmxpbmFyby5vcmcvbWFpbG1hbi9saXN0aW5mby95MjAzOAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out02.mta.xmission.com ([166.70.13.232]:47877 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751979AbeFYB0d (ORCPT ); Sun, 24 Jun 2018 21:26:33 -0400 From: ebiederm@xmission.com (Eric W. Biederman) References: <20180420120605.1612248-1-arnd@arndb.de> <20180420120605.1612248-2-arnd@arndb.de> <20180621154915.GA31947@gmail.com> <20180621161121.GB7222@gmail.com> <20180622021636.GA11266@gmail.com> <87a7rm3eb5.fsf@xmission.com> <20180624071258.GB29407@gmail.com> Date: Sun, 24 Jun 2018 20:26:08 -0500 In-Reply-To: <20180624071258.GB29407@gmail.com> (Ingo Molnar's message of "Sun, 24 Jun 2018 09:12:58 +0200") Message-ID: <87y3f31wsv.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [PATCH v2 2/2] rusage: allow 64-bit times ru_utime/ru_stime Sender: linux-arch-owner@vger.kernel.org List-ID: To: Ingo Molnar Cc: Arnd Bergmann , y2038 Mailman List , Linux Kernel Mailing List , the arch/x86 maintainers , Linux API , linux-arch , Paul Eggert , Richard Henderson , Ivan Kokshaysky , Matt Turner , Al Viro , Dominik Brodowski , Thomas Gleixner , Andrew Morton , linux-alpha@vger.kernel.org, Deepa Dinamani Message-ID: <20180625012608.CPfbLM37lgoBoo54GSaHocVM6DSqPXB3mkNDKE9Iz2I@z> Ingo Molnar writes: > * Eric W. Biederman wrote: > >> The trouble with attributes is that means you can't filter your system >> call arguments with seccomp. [...] > > There's nothing keeping seccomp from securely fetching those arguments and > extending filtering to them as well ... > > Allowing that would make sense for a lot of other system calls as > well. Possibly. The challenge is that if the fetch for the kernel to use those arguments is different from the fetch of seccomp to test those arguments you have a time of test vs time of use race. Given the location of the seccomp hook at the kernel user space border there is no easy way for seccomp to share the fetch with the system call itself. So I don't see how seccomp could perform the fetch securely. Eric