From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751920AbdKMFfD (ORCPT ); Mon, 13 Nov 2017 00:35:03 -0500 Received: from sg2plout10-02.prod.sin2.secureserver.net ([182.50.145.5]:46833 "EHLO sg2plout10-02.prod.sin2.secureserver.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751756AbdKMFfB (ORCPT ); Mon, 13 Nov 2017 00:35:01 -0500 X-Google-Smtp-Source: AGs4zMZRLGEiBZCmEEMPN008P1GdBaJNyxlkEsPwNcg5rw2Mf3VS3Z+7Qv/KnQ4ouTaUSpRlcUuaG9bNPHoQzdOJu/o= MIME-Version: 1.0 In-Reply-To: <20171113043511.GH11398@eros> References: <1510050731-32446-1-git-send-email-me@tobin.cc> <20171111231007.iirqce3r7xqqnxd3@node.shutemov.name> <20171112230646.GM19752@eros> <20171113033728.wheztgb2hbc74lj2@node.shutemov.name> <20171113043511.GH11398@eros> From: Kaiwan N Billimoria Date: Mon, 13 Nov 2017 10:57:16 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [kernel-hardening] Re: [PATCH v4] scripts: add leaking_addresses.pl To: "Tobin C. Harding" Cc: "Kirill A. Shutemov" , kernel-hardening@lists.openwall.com, "Jason A. Donenfeld" , "Theodore Ts'o" , Linus Torvalds , Kees Cook , Paolo Bonzini , Tycho Andersen , "Roberts, William C" , Tejun Heo , Jordan Glover , Greg KH , Petr Mladek , Joe Perches , Ian Campbell , Sergey Senozhatsky , Catalin Marinas , Will Deacon , Steven Rostedt , Chris Fries , Dave Weinstein , Daniel Micay , Djalal Harouni , Linux Kernel Mailing List , Network Development , David Miller Content-Type: text/plain; charset="UTF-8" X-CMAE-Envelope: MS4wfA8335xVta+YnILaj3bInOrowKdgM1KjC7hZUN3YIG9IQ+orV2cpR/gafoj2QObh06ME7lWJ8dPBBwEnF0T45cWLSV/xvt15xD7K+3a/mJHPEAAueELb 3Iumd5t/VgRG4YMpj/7qfIMaE8uayb0026rsaeU8I6zdWNtYy/T0wtJNvv4/2m+Jb4MX9RZnZWwVykTvTIerEgATLqsKKmDpVP1aoDwlkrrIzkJBHI+YCn4e Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 13, 2017 at 10:05 AM, Tobin C. Harding wrote: > On Mon, Nov 13, 2017 at 06:37:28AM +0300, Kirill A. Shutemov wrote: >> On Mon, Nov 13, 2017 at 10:06:46AM +1100, Tobin C. Harding wrote: >> > On Sun, Nov 12, 2017 at 02:10:07AM +0300, Kirill A. Shutemov wrote: ... >> > >> > Thanks for the link. So it looks like we need to refactor the kernel >> > address regular expression into a function that takes into account the >> > machine architecture and the number of page table levels. We will need >> > to add this to the false positive checks also. >> > >> > > Not sure if we care. It won't work too for other 64-bit architectrues that >> > > have more than 256TB of virtual address space. >> > >> > Is this because of the virtual memory map? >> >> On x86 direct mapping is the nearest thing we have to userspace. >> >> > Did you mean 512TB? >> >> No, I mean 256TB. >> >> You have all kernel memory in the range from 0xffff000000000000 to >> 0xffffffffffffffff if you have 256 TB of virtual address space. If you >> hvae more, some thing might be ouside the range. > > Doesn't 4-level paging already limit a system to 64TB of memory? So any > system better equipped than this will use 5-level paging right? If I am > totally talking rubbish please ignore, I'm appreciative that you pointed > out the limitation already. Perhaps we can add a comment to the script > > # Script may miss some addresses on machines with more than 256TB of > # memory. I think the 256TB is wrt *virtual* address space not physical RAM. Also, IMHO, the script should 'transparently' take into account the # of paging levels (instead of the user needing to pass a parameter). IOW it should be able to detect the same (say, from the .config file) and act accordingly - in the sense, the regex's and associated logic would accordingly differ. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kaiwan N Billimoria Subject: Re: [kernel-hardening] Re: [PATCH v4] scripts: add leaking_addresses.pl Date: Mon, 13 Nov 2017 10:57:16 +0530 Message-ID: References: <1510050731-32446-1-git-send-email-me@tobin.cc> <20171111231007.iirqce3r7xqqnxd3@node.shutemov.name> <20171112230646.GM19752@eros> <20171113033728.wheztgb2hbc74lj2@node.shutemov.name> <20171113043511.GH11398@eros> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: "Kirill A. Shutemov" , kernel-hardening@lists.openwall.com, "Jason A. Donenfeld" , "Theodore Ts'o" , Linus Torvalds , Kees Cook , Paolo Bonzini , Tycho Andersen , "Roberts, William C" , Tejun Heo , Jordan Glover , Greg KH , Petr Mladek , Joe Perches , Ian Campbell , Sergey Senozhatsky , Catalin Marinas , Will Deacon , Steven Rostedt , Chris Fries To: "Tobin C. Harding" Return-path: In-Reply-To: <20171113043511.GH11398@eros> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Mon, Nov 13, 2017 at 10:05 AM, Tobin C. Harding wrote: > On Mon, Nov 13, 2017 at 06:37:28AM +0300, Kirill A. Shutemov wrote: >> On Mon, Nov 13, 2017 at 10:06:46AM +1100, Tobin C. Harding wrote: >> > On Sun, Nov 12, 2017 at 02:10:07AM +0300, Kirill A. Shutemov wrote: ... >> > >> > Thanks for the link. So it looks like we need to refactor the kernel >> > address regular expression into a function that takes into account the >> > machine architecture and the number of page table levels. We will need >> > to add this to the false positive checks also. >> > >> > > Not sure if we care. It won't work too for other 64-bit architectrues that >> > > have more than 256TB of virtual address space. >> > >> > Is this because of the virtual memory map? >> >> On x86 direct mapping is the nearest thing we have to userspace. >> >> > Did you mean 512TB? >> >> No, I mean 256TB. >> >> You have all kernel memory in the range from 0xffff000000000000 to >> 0xffffffffffffffff if you have 256 TB of virtual address space. If you >> hvae more, some thing might be ouside the range. > > Doesn't 4-level paging already limit a system to 64TB of memory? So any > system better equipped than this will use 5-level paging right? If I am > totally talking rubbish please ignore, I'm appreciative that you pointed > out the limitation already. Perhaps we can add a comment to the script > > # Script may miss some addresses on machines with more than 256TB of > # memory. I think the 256TB is wrt *virtual* address space not physical RAM. Also, IMHO, the script should 'transparently' take into account the # of paging levels (instead of the user needing to pass a parameter). IOW it should be able to detect the same (say, from the .config file) and act accordingly - in the sense, the regex's and associated logic would accordingly differ.