From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 10 May 2017 00:35:34 -0700 From: Christoph Hellwig Message-ID: <20170510073534.GA19359@infradead.org> References: <20170509064522.anusoikaalvlux3w@gmail.com> <20170509085659.GA32555@infradead.org> <20170509130250.GA11381@infradead.org> <20170509160322.GA15902@infradead.org> <20170510021118.GA390@ZenIV.linux.org.uk> <20170510024524.GB390@ZenIV.linux.org.uk> <20170510031254.GC390@ZenIV.linux.org.uk> <20170510065301.GC4115@infradead.org> <20170510072746.GF390@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170510072746.GF390@ZenIV.linux.org.uk> Subject: Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode To: Al Viro Cc: Christoph Hellwig , Andy Lutomirski , Ingo Molnar , Greg KH , Thomas Garnier , Martin Schwidefsky , Heiko Carstens , Dave Hansen , Arnd Bergmann , Thomas Gleixner , David Howells , =?iso-8859-1?Q?Ren=E9?= Nyffenegger , Andrew Morton , "Paul E . McKenney" , "Eric W . Biederman" , Oleg Nesterov , Pavel Tikhomirov , Ingo Molnar , "H . Peter Anvin" , Paolo Bonzini , Rik van Riel , Kees Cook , Josh Poimboeuf , Borislav Petkov , Brian Gerst , "Kirill A . Shutemov" , Christian Borntraeger , Russell King , Will Deacon , Catalin Marinas , Mark Rutland , James Morse , linux-s390 , LKML , Linux API , the arch/x86 maintainers , "linux-arm-kernel@lists.infradead.org" , Kernel Hardening , Linus Torvalds , Peter Zijlstra List-ID: On Wed, May 10, 2017 at 08:27:47AM +0100, Al Viro wrote: > And you *still* do the same. Christoph, this is ridiculous - the worst > part of the area is not a couple of functions in fs/read_write.c, it's > a fucking lot of ->read() and ->write() instances in shitty driver code, > pardon the redundance. And _that_ is still done under set_fs(KERNEL_DS). For now yes. But it provides a sane API on top, and then we can start moving the drivers that matter to the iter variants and drop support for the rest soon. Most in-kernel I/O is done to files, and the rest to a very limited set of devices. (not accounting for sockets through their own APIs, thats another story) > That's what I'm objecting to. Centralized kernel_readv() et.al. - sure, > and fs/read_write.c is the right place for those. No arguments here. > Conversion to those - absolutely; drivers have no fucking business touching > set_fs() at all. But your primitives are trouble waiting to happen. > Let them take kvec arrays. And let them, in case when there's no > ->read_iter()/->write_iter(), do set_fs(). Statically, without this > if (iter->type & ITER_KVEC) ... stuff. Oh weĺl. I can do that first, but I think eventually we'll have to get back to what I've done now. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode Date: Wed, 10 May 2017 00:35:34 -0700 Message-ID: <20170510073534.GA19359@infradead.org> References: <20170509064522.anusoikaalvlux3w@gmail.com> <20170509085659.GA32555@infradead.org> <20170509130250.GA11381@infradead.org> <20170509160322.GA15902@infradead.org> <20170510021118.GA390@ZenIV.linux.org.uk> <20170510024524.GB390@ZenIV.linux.org.uk> <20170510031254.GC390@ZenIV.linux.org.uk> <20170510065301.GC4115@infradead.org> <20170510072746.GF390@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20170510072746.GF390@ZenIV.linux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Al Viro Cc: Mark Rutland , Kernel Hardening , Greg KH , Heiko Carstens , LKML , David Howells , Dave Hansen , "H . Peter Anvin" , Ingo Molnar , Pavel Tikhomirov , Peter Zijlstra , linux-s390 , the arch/x86 maintainers , Russell King , Will Deacon , Christoph Hellwig , Christian Borntraeger , =?iso-8859-1?Q?Ren=E9?= Nyffenegger , Catalin Marinas , "Paul E . McKenney" , Rik van Riel , Kees Cook List-Id: linux-api@vger.kernel.org T24gV2VkLCBNYXkgMTAsIDIwMTcgYXQgMDg6Mjc6NDdBTSArMDEwMCwgQWwgVmlybyB3cm90ZToK PiBBbmQgeW91ICpzdGlsbCogZG8gdGhlIHNhbWUuICBDaHJpc3RvcGgsIHRoaXMgaXMgcmlkaWN1 bG91cyAtIHRoZSB3b3JzdAo+IHBhcnQgb2YgdGhlIGFyZWEgaXMgbm90IGEgY291cGxlIG9mIGZ1 bmN0aW9ucyBpbiBmcy9yZWFkX3dyaXRlLmMsIGl0J3MKPiBhIGZ1Y2tpbmcgbG90IG9mIC0+cmVh ZCgpIGFuZCAtPndyaXRlKCkgaW5zdGFuY2VzIGluIHNoaXR0eSBkcml2ZXIgY29kZSwKPiBwYXJk b24gdGhlIHJlZHVuZGFuY2UuICBBbmQgX3RoYXRfIGlzIHN0aWxsIGRvbmUgdW5kZXIgc2V0X2Zz KEtFUk5FTF9EUykuCgpGb3Igbm93IHllcy4gIEJ1dCBpdCBwcm92aWRlcyBhIHNhbmUgQVBJIG9u IHRvcCwgYW5kIHRoZW4gd2UgY2FuCnN0YXJ0IG1vdmluZyB0aGUgZHJpdmVycyB0aGF0IG1hdHRl ciB0byB0aGUgaXRlciB2YXJpYW50cyBhbmQgZHJvcApzdXBwb3J0IGZvciB0aGUgcmVzdCBzb29u LiAgTW9zdCBpbi1rZXJuZWwgSS9PIGlzIGRvbmUgdG8gZmlsZXMsIGFuZAp0aGUgcmVzdCB0byBh IHZlcnkgbGltaXRlZCBzZXQgb2YgZGV2aWNlcy4gKG5vdCBhY2NvdW50aW5nIGZvciBzb2NrZXRz CnRocm91Z2ggdGhlaXIgb3duIEFQSXMsIHRoYXRzIGFub3RoZXIgc3RvcnkpCgo+IFRoYXQncyB3 aGF0IEknbSBvYmplY3RpbmcgdG8uICBDZW50cmFsaXplZCBrZXJuZWxfcmVhZHYoKSBldC5hbC4g LSBzdXJlLAo+IGFuZCBmcy9yZWFkX3dyaXRlLmMgaXMgdGhlIHJpZ2h0IHBsYWNlIGZvciB0aG9z ZS4gIE5vIGFyZ3VtZW50cyBoZXJlLgo+IENvbnZlcnNpb24gdG8gdGhvc2UgLSBhYnNvbHV0ZWx5 OyBkcml2ZXJzIGhhdmUgbm8gZnVja2luZyBidXNpbmVzcyB0b3VjaGluZwo+IHNldF9mcygpIGF0 IGFsbC4gIEJ1dCB5b3VyIHByaW1pdGl2ZXMgYXJlIHRyb3VibGUgd2FpdGluZyB0byBoYXBwZW4u Cj4gTGV0IHRoZW0gdGFrZSBrdmVjIGFycmF5cy4gIEFuZCBsZXQgdGhlbSwgaW4gY2FzZSB3aGVu IHRoZXJlJ3Mgbm8KPiAtPnJlYWRfaXRlcigpLy0+d3JpdGVfaXRlcigpLCBkbyBzZXRfZnMoKS4g IFN0YXRpY2FsbHksIHdpdGhvdXQgdGhpcwo+IGlmIChpdGVyLT50eXBlICYgSVRFUl9LVkVDKSAu Li4gc3R1ZmYuCgpPaCB3ZcS6bC4gIEkgY2FuIGRvIHRoYXQgZmlyc3QsIGJ1dCBJIHRoaW5rIGV2 ZW50dWFsbHkgd2UnbGwgaGF2ZSB0bwpnZXQgYmFjayB0byB3aGF0IEkndmUgZG9uZSBub3cuCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0t a2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcK aHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2Vy bmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: hch@infradead.org (Christoph Hellwig) Date: Wed, 10 May 2017 00:35:34 -0700 Subject: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode In-Reply-To: <20170510072746.GF390@ZenIV.linux.org.uk> References: <20170509064522.anusoikaalvlux3w@gmail.com> <20170509085659.GA32555@infradead.org> <20170509130250.GA11381@infradead.org> <20170509160322.GA15902@infradead.org> <20170510021118.GA390@ZenIV.linux.org.uk> <20170510024524.GB390@ZenIV.linux.org.uk> <20170510031254.GC390@ZenIV.linux.org.uk> <20170510065301.GC4115@infradead.org> <20170510072746.GF390@ZenIV.linux.org.uk> Message-ID: <20170510073534.GA19359@infradead.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, May 10, 2017 at 08:27:47AM +0100, Al Viro wrote: > And you *still* do the same. Christoph, this is ridiculous - the worst > part of the area is not a couple of functions in fs/read_write.c, it's > a fucking lot of ->read() and ->write() instances in shitty driver code, > pardon the redundance. And _that_ is still done under set_fs(KERNEL_DS). For now yes. But it provides a sane API on top, and then we can start moving the drivers that matter to the iter variants and drop support for the rest soon. Most in-kernel I/O is done to files, and the rest to a very limited set of devices. (not accounting for sockets through their own APIs, thats another story) > That's what I'm objecting to. Centralized kernel_readv() et.al. - sure, > and fs/read_write.c is the right place for those. No arguments here. > Conversion to those - absolutely; drivers have no fucking business touching > set_fs() at all. But your primitives are trouble waiting to happen. > Let them take kvec arrays. And let them, in case when there's no > ->read_iter()/->write_iter(), do set_fs(). Statically, without this > if (iter->type & ITER_KVEC) ... stuff. Oh we?l. I can do that first, but I think eventually we'll have to get back to what I've done now.