From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0575BC433E1 for ; Thu, 14 May 2020 10:01:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DF319206B6 for ; Thu, 14 May 2020 10:01:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726102AbgENKBv (ORCPT ); Thu, 14 May 2020 06:01:51 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([146.101.78.151]:31779 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726084AbgENKBv (ORCPT ); Thu, 14 May 2020 06:01:51 -0400 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-179-I2TpioJnO02MgCgI8UoE-Q-1; Thu, 14 May 2020 11:01:46 +0100 X-MC-Unique: I2TpioJnO02MgCgI8UoE-Q-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 14 May 2020 11:01:45 +0100 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Thu, 14 May 2020 11:01:45 +0100 From: David Laight To: 'Daniel Borkmann' , Al Viro CC: Christoph Hellwig , Linus Torvalds , the arch/x86 maintainers , Alexei Starovoitov , Masami Hiramatsu , Andrew Morton , "linux-parisc@vger.kernel.org" , linux-um , Netdev , "bpf@vger.kernel.org" , Linux-MM , Linux Kernel Mailing List , "bgregg@netflix.com" Subject: RE: [PATCH 11/18] maccess: remove strncpy_from_unsafe Thread-Topic: [PATCH 11/18] maccess: remove strncpy_from_unsafe Thread-Index: AQHWKYLaQq1MCiy4bEiOMK61mlvZyainWQNA Date: Thu, 14 May 2020 10:01:45 +0000 Message-ID: <6ca8d8499bf644aba0b242d194df5a60@AcuMS.aculab.com> References: <20200513160038.2482415-1-hch@lst.de> <20200513160038.2482415-12-hch@lst.de> <20200513192804.GA30751@lst.de> <0c1a7066-b269-9695-b94a-bb5f4f20ebd8@iogearbox.net> <20200513232816.GZ23230@ZenIV.linux.org.uk> <866cbe54-a027-04eb-65db-c6423d16b924@iogearbox.net> In-Reply-To: <866cbe54-a027-04eb-65db-c6423d16b924@iogearbox.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org RnJvbTogRGFuaWVsIEJvcmttYW5uDQo+IFNlbnQ6IDE0IE1heSAyMDIwIDAwOjU5DQo+IE9uIDUv MTQvMjAgMToyOCBBTSwgQWwgVmlybyB3cm90ZToNCj4gPiBPbiBUaHUsIE1heSAxNCwgMjAyMCBh dCAxMjozNjoyOEFNICswMjAwLCBEYW5pZWwgQm9ya21hbm4gd3JvdGU6DQo+ID4NCj4gPj4+IFNv IG9uIHNheSBzMzkwIFRBU0tfU0laRV9VU1VBTEx5IGlzICgtUEFHRV9TSVpFKSwgd2hpY2ggbWVh bnMgd2UnZCBhbHdheQ0KPiA+Pj4gdHJ5IHRoZSB1c2VyIGNvcHkgZmlyc3QsIHdoaWNoIHNlZW1z IG9kZC4NCj4gPj4+DQo+ID4+PiBJJ2QgcmVhbGx5IGxpa2UgdG8gaGVyZSBmcm9tIHRoZSBicGYg Zm9sa3Mgd2hhdCB0aGUgZXhwZWN0ZWQgdXNlIGNhc2UNCj4gPj4+IGlzIGhlcmUsIGFuZCBpZiB0 aGUgdHlwaWNhbCBhcmd1bWVudCBpcyBrZXJuZWwgb3IgdXNlciBtZW1vcnkuDQo+ID4+DQo+ID4+ IEl0J3MgdXNlZCBmb3IgYm90aC4gR2l2ZW4gdGhpcyBpcyBlbmFibGVkIG9uIHByZXR0eSBtdWNo IGFsbCBwcm9ncmFtIHR5cGVzLCBteQ0KPiA+PiBhc3N1bXB0aW9uIHdvdWxkIGJlIHRoYXQgdXNh Z2UgaXMgc3RpbGwgbW9yZSBvZnRlbiBvbiBrZXJuZWwgbWVtb3J5IHRoYW4gdXNlciBvbmUuDQo+ ID4NCj4gPiBUaGVuIGl0IG5lZWRzIGFuIGFyZ3VtZW50IHRlbGxpbmcgaXQgd2hpY2ggb25lIHRv IHVzZS4gIExvb2sgYXQgc3BhcmM2NC4NCj4gPiBPciBzMzkwLiAgT3IgcGFyaXNjLiAgRXQgc29k ZGluZyBjZXRlcmEuDQo+ID4NCj4gPiBUaGUgdW5kZXJseWluZyBtb2RlbCBpcyB0aGF0IHRoZSBr ZXJuZWwgbGl2ZXMgaW4gYSBzZXBhcmF0ZSBhZGRyZXNzIHNwYWNlLg0KPiA+IFllcywgb24geDg2 IGl0J3MgYWN0dWFsbHkgc2hhcmluZyB0aGUgcGFnZSB0YWJsZXMgd2l0aCB1c2VybGFuZCwgYnV0 IHRoYXQncw0KPiA+IG5vdCB1bml2ZXJzYWwuICBUaGUgc2FtZSBhZGRyZXNzIGNhbiBiZSBib3Ro IGEgdmFsaWQgdXNlcmxhbmQgb25lIF9hbmRfDQo+ID4gYSB2YWxpZCBrZXJuZWwgb25lLiAgWW91 IG5lZWQgdG8gdGVsbCB3aGljaCBvbmUgZG8geW91IHdhbnQuDQo+IA0KPiBZZXMsIHNlZSBhbHNv IDZhZTA4YWUzZGVhMiAoImJwZjogQWRkIHByb2JlX3JlYWRfe3VzZXIsIGtlcm5lbH0gYW5kIHBy b2JlX3JlYWRfe3VzZXIsDQo+IGtlcm5lbH1fc3RyIGhlbHBlcnMiKSwgYW5kIG15IG90aGVyIHJl cGx5IHdydCBicGZfdHJhY2VfcHJpbnRrKCkgb24gaG93IHRvIGFkZHJlc3MNCj4gdGhpcy4gQWxs IEknbSB0cnlpbmcgdG8gc2F5IGlzIHRoYXQgYm90aCBicGZfcHJvYmVfcmVhZCgpIGFuZCBicGZf dHJhY2VfcHJpbnRrKCkgZG8NCj4gZXhpc3QgaW4gdGhpcyBmb3JtIHNpbmNlIGVhcmx5IFtlXWJw ZiBkYXlzIGZvciB+NXlycyBub3cgYW5kIHdoaWxlIGJyb2tlbiBvbiBub24teDg2DQo+IHRoZXJl IGFyZSBhIGxvdCBvZiB1c2VycyBvbiB4ODYgZm9yIHRoaXMgaW4gdGhlIHdpbGQsIHNvIHRoZXkg bmVlZCB0byBoYXZlIGEgY2hhbmNlDQo+IHRvIG1pZ3JhdGUgb3ZlciB0byB0aGUgbmV3IGZhY2ls aXRpZXMgYmVmb3JlIHRoZXkgYXJlIGZ1bGx5IHJlbW92ZWQuDQoNCklmIGl0J3Mgbm90IGEgc3R1 cGlkIHF1ZXN0aW9uIHdoeSBpcyBhIEJQRiBwcm9ncmFtIGFsbG93ZWQgdG8gZ2V0DQppbnRvIGEg c2l0dWF0aW9uIHdoZXJlIGl0IG1pZ2h0IGhhdmUgYW4gaW52YWxpZCBrZXJuZWwgYWRkcmVzcy4N Cg0KSXQgYWxsIHN0aW5rcyBvZiBhIGhvbGUgdGhhdCBhbGxvd3MgYWxsIG9mIGtlcm5lbCBtZW1v cnkgdG8gYmUgcmVhZA0KYW5kIGNvcGllZCB0byB1c2Vyc3BhY2UuDQoNCk5vdyB5b3UgbWlnaHQg d2FudCB0byBzb21ldGhpbmcgc3BlY2lhbCBzbyB0aGF0IEJQRiBwcm9ncmFtcyBqdXN0DQphYm9y dCBvbiBPT1BTIGluc3RlYWQgb2YgcG9zc2libHkgcGFuaWtpbmcgdGhlIGtlcm5lbC4NCkJ1dCB0 aGF0IGlzIGRpZmZlcmVudCBmcm9tIGEgY29weSB0aGF0IGV4cGVjdHMgdG8gYmUgcGFzc2VkIGdh cmJhZ2UuDQoNCglEYXZpZA0KDQotDQpSZWdpc3RlcmVkIEFkZHJlc3MgTGFrZXNpZGUsIEJyYW1s ZXkgUm9hZCwgTW91bnQgRmFybSwgTWlsdG9uIEtleW5lcywgTUsxIDFQVCwgVUsNClJlZ2lzdHJh dGlvbiBObzogMTM5NzM4NiAoV2FsZXMpDQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eu-smtp-delivery-151.mimecast.com ([146.101.78.151]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jZAgb-0007O0-Di for linux-um@lists.infradead.org; Thu, 14 May 2020 10:01:55 +0000 From: David Laight Subject: RE: [PATCH 11/18] maccess: remove strncpy_from_unsafe Date: Thu, 14 May 2020 10:01:45 +0000 Message-ID: <6ca8d8499bf644aba0b242d194df5a60@AcuMS.aculab.com> References: <20200513160038.2482415-1-hch@lst.de> <20200513160038.2482415-12-hch@lst.de> <20200513192804.GA30751@lst.de> <0c1a7066-b269-9695-b94a-bb5f4f20ebd8@iogearbox.net> <20200513232816.GZ23230@ZenIV.linux.org.uk> <866cbe54-a027-04eb-65db-c6423d16b924@iogearbox.net> In-Reply-To: <866cbe54-a027-04eb-65db-c6423d16b924@iogearbox.net> Content-Language: en-US MIME-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: 'Daniel Borkmann' , Al Viro Cc: "bpf@vger.kernel.org" , "linux-parisc@vger.kernel.org" , Netdev , the arch/x86 maintainers , linux-um , Alexei Starovoitov , Linux Kernel Mailing List , Linux-MM , Masami Hiramatsu , Andrew Morton , "bgregg@netflix.com" , Linus Torvalds , Christoph Hellwig From: Daniel Borkmann > Sent: 14 May 2020 00:59 > On 5/14/20 1:28 AM, Al Viro wrote: > > On Thu, May 14, 2020 at 12:36:28AM +0200, Daniel Borkmann wrote: > > > >>> So on say s390 TASK_SIZE_USUALLy is (-PAGE_SIZE), which means we'd alway > >>> try the user copy first, which seems odd. > >>> > >>> I'd really like to here from the bpf folks what the expected use case > >>> is here, and if the typical argument is kernel or user memory. > >> > >> It's used for both. Given this is enabled on pretty much all program types, my > >> assumption would be that usage is still more often on kernel memory than user one. > > > > Then it needs an argument telling it which one to use. Look at sparc64. > > Or s390. Or parisc. Et sodding cetera. > > > > The underlying model is that the kernel lives in a separate address space. > > Yes, on x86 it's actually sharing the page tables with userland, but that's > > not universal. The same address can be both a valid userland one _and_ > > a valid kernel one. You need to tell which one do you want. > > Yes, see also 6ae08ae3dea2 ("bpf: Add probe_read_{user, kernel} and probe_read_{user, > kernel}_str helpers"), and my other reply wrt bpf_trace_printk() on how to address > this. All I'm trying to say is that both bpf_probe_read() and bpf_trace_printk() do > exist in this form since early [e]bpf days for ~5yrs now and while broken on non-x86 > there are a lot of users on x86 for this in the wild, so they need to have a chance > to migrate over to the new facilities before they are fully removed. If it's not a stupid question why is a BPF program allowed to get into a situation where it might have an invalid kernel address. It all stinks of a hole that allows all of kernel memory to be read and copied to userspace. Now you might want to something special so that BPF programs just abort on OOPS instead of possibly paniking the kernel. But that is different from a copy that expects to be passed garbage. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um