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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 AA77AC433DF for ; Thu, 14 May 2020 10:28:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9522A206DA for ; Thu, 14 May 2020 10:28:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725999AbgENK1s (ORCPT ); Thu, 14 May 2020 06:27:48 -0400 Received: from www62.your-server.de ([213.133.104.62]:33820 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725925AbgENK1r (ORCPT ); Thu, 14 May 2020 06:27:47 -0400 Received: from sslproxy02.your-server.de ([78.47.166.47]) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1jZB5c-0007ik-1o; Thu, 14 May 2020 12:27:44 +0200 Received: from [178.196.57.75] (helo=pc-9.home) by sslproxy02.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jZB5b-000K33-L4; Thu, 14 May 2020 12:27:43 +0200 Subject: Re: [PATCH 11/18] maccess: remove strncpy_from_unsafe To: Masami Hiramatsu , Linus Torvalds Cc: Christoph Hellwig , the arch/x86 maintainers , Alexei Starovoitov , Andrew Morton , linux-parisc@vger.kernel.org, linux-um , Netdev , bpf@vger.kernel.org, Linux-MM , Linux Kernel Mailing List References: <20200513160038.2482415-1-hch@lst.de> <20200513160038.2482415-12-hch@lst.de> <20200513192804.GA30751@lst.de> <0c1a7066-b269-9695-b94a-bb5f4f20ebd8@iogearbox.net> <20200514082054.f817721ce196f134e6820644@kernel.org> <20200514100009.a8e6aa001f0ace5553c7904f@kernel.org> <20200514184419.0fbf548ccf883c097d94573a@kernel.org> From: Daniel Borkmann Message-ID: <9c2f90fd-9cac-67c3-4d96-4f873c7649e7@iogearbox.net> Date: Thu, 14 May 2020 12:27:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20200514184419.0fbf548ccf883c097d94573a@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.102.2/25811/Wed May 13 14:11:53 2020) Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org On 5/14/20 11:44 AM, Masami Hiramatsu wrote: > On Wed, 13 May 2020 19:43:24 -0700 > Linus Torvalds wrote: >> On Wed, May 13, 2020 at 6:00 PM Masami Hiramatsu wrote: >>> >>>> But we should likely at least disallow it entirely on platforms where >>>> we really can't - or pick one hardcoded choice. On sparc, you really >>>> _have_ to specify one or the other. >>> >>> OK. BTW, is there any way to detect the kernel/user space overlap on >>> memory layout statically? If there, I can do it. (I don't like >>> "if (CONFIG_X86)" thing....) >>> Or, maybe we need CONFIG_ARCH_OVERLAP_ADDRESS_SPACE? >> >> I think it would be better to have a CONFIG variable that >> architectures can just 'select' to show that they are ok with separate >> kernel and user addresses. >> >> Because I don't think we have any way to say that right now as-is. You >> can probably come up with hacky ways to approximate it, ie something >> like >> >> if (TASK_SIZE_MAX > PAGE_OFFSET) >> .... they overlap .. >> >> which would almost work, but.. > > It seems TASK_SIZE_MAX is defined only on x86 and s390, what about > comparing STACK_TOP_MAX with PAGE_OFFSET ? > Anyway, I agree that the best way is introducing a CONFIG. Agree, CONFIG knob that archs can select feels cleanest. Fwiw, I've cooked up fixes for bpf side locally here and finishing up testing, will push out later today. Thanks, Daniel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from www62.your-server.de ([213.133.104.62]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jZB5f-0008R0-8q for linux-um@lists.infradead.org; Thu, 14 May 2020 10:27:48 +0000 Subject: Re: [PATCH 11/18] maccess: remove strncpy_from_unsafe References: <20200513160038.2482415-1-hch@lst.de> <20200513160038.2482415-12-hch@lst.de> <20200513192804.GA30751@lst.de> <0c1a7066-b269-9695-b94a-bb5f4f20ebd8@iogearbox.net> <20200514082054.f817721ce196f134e6820644@kernel.org> <20200514100009.a8e6aa001f0ace5553c7904f@kernel.org> <20200514184419.0fbf548ccf883c097d94573a@kernel.org> From: Daniel Borkmann Message-ID: <9c2f90fd-9cac-67c3-4d96-4f873c7649e7@iogearbox.net> Date: Thu, 14 May 2020 12:27:42 +0200 MIME-Version: 1.0 In-Reply-To: <20200514184419.0fbf548ccf883c097d94573a@kernel.org> Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Masami Hiramatsu , Linus Torvalds 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 , Andrew Morton , Christoph Hellwig On 5/14/20 11:44 AM, Masami Hiramatsu wrote: > On Wed, 13 May 2020 19:43:24 -0700 > Linus Torvalds wrote: >> On Wed, May 13, 2020 at 6:00 PM Masami Hiramatsu wrote: >>> >>>> But we should likely at least disallow it entirely on platforms where >>>> we really can't - or pick one hardcoded choice. On sparc, you really >>>> _have_ to specify one or the other. >>> >>> OK. BTW, is there any way to detect the kernel/user space overlap on >>> memory layout statically? If there, I can do it. (I don't like >>> "if (CONFIG_X86)" thing....) >>> Or, maybe we need CONFIG_ARCH_OVERLAP_ADDRESS_SPACE? >> >> I think it would be better to have a CONFIG variable that >> architectures can just 'select' to show that they are ok with separate >> kernel and user addresses. >> >> Because I don't think we have any way to say that right now as-is. You >> can probably come up with hacky ways to approximate it, ie something >> like >> >> if (TASK_SIZE_MAX > PAGE_OFFSET) >> .... they overlap .. >> >> which would almost work, but.. > > It seems TASK_SIZE_MAX is defined only on x86 and s390, what about > comparing STACK_TOP_MAX with PAGE_OFFSET ? > Anyway, I agree that the best way is introducing a CONFIG. Agree, CONFIG knob that archs can select feels cleanest. Fwiw, I've cooked up fixes for bpf side locally here and finishing up testing, will push out later today. Thanks, Daniel _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um