Received: by 10.223.164.202 with SMTP id h10csp745629wrb; Fri, 10 Nov 2017 14:13:41 -0800 (PST) X-Google-Smtp-Source: AGs4zMZD5rR9qdJUb5fqoPGoYIj+W8zxWTwz33Ki8UYA4qsKgSEAbQxBnrlvCrGJl9jr2k7nqDtM X-Received: by 10.84.129.2 with SMTP id 2mr1842686plb.270.1510352021301; Fri, 10 Nov 2017 14:13:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510352021; cv=none; d=google.com; s=arc-20160816; b=TOwi77v3lnfOhdsK930hpGVX9IJYP5kgKqEaT43KEnsgqi1yYTR+/1Y4lhBSAIBw4T qrTFaWkvMRN0nkPflmGAKYbdaYOgBO3pyoGj8aKVH/MPuD7TB80Pth3zI5MKopsmveid TudgKUOjRbHIepB7nFWNR6Mw+n2+Y9aK8sYeb6IdMRwh3nScombiZ2cVfNE/oA2bW6Cs 4GQGYj3bwPNoHxa4Z0xIfapzpKzkuuY2pdw+sjDmJMCJCfjU7SLvtbvfsfchbu8f6lY2 viODApVsfIn35b6PQMC2VKoydNKlK1MVnCS9Z2l10MbqrYLXekBJphTVBcq2XbLa916L OT3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=aHMYfKNcbsqXQy9C2yJlvz/lJ8El8/fFgDO8B6HvR7Y=; b=Wqk1jJngeUDNUQ0fHX9QPLV88PTUM/ECHqzgp7yYsNc60iZgQ+shp3j651Va3wbSlK KLM4Ltli4kJjUZc7n/3P0mtYajqQWL+BhxftnvLiqlDIxMdNYFhvlKpMxEbOrgzseye0 l2UPSxQGCDIfWwSk+Zp8x7mgY5QZT0C0cqdnboAd14RHUPeO9uniK6HsjyDAV1xB1Yg4 3vuVKtaEVVAiBCfo4w1cUUakMRgIYMVaRjN12ovbUd3N3xrCv5RFLkotoZwgO9CoMOtK vFVT7h667iz1l10Iuu+OH1xVV8fws4moutSCcPuBu3azBYQ4BS+CYdZxx42bYQ4pgjj0 DQnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=JChJgmGh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r6si9924714pls.313.2017.11.10.14.13.29; Fri, 10 Nov 2017 14:13:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=JChJgmGh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754557AbdKJWMu (ORCPT + 83 others); Fri, 10 Nov 2017 17:12:50 -0500 Received: from mail-pf0-f182.google.com ([209.85.192.182]:46528 "EHLO mail-pf0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753977AbdKJWMt (ORCPT ); Fri, 10 Nov 2017 17:12:49 -0500 Received: by mail-pf0-f182.google.com with SMTP id p87so7605013pfj.3; Fri, 10 Nov 2017 14:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aHMYfKNcbsqXQy9C2yJlvz/lJ8El8/fFgDO8B6HvR7Y=; b=JChJgmGhjTJ4p9s0hItU/sD2pB50gPsggjFhPktUHZhJQ4nLy8I/aMG935e0F5Ys7s hKuJN7zTZxE5G7vuLZfYk8kmqkwwcClmDoPASih0tHxfCZL+XbEmYTkeFwmNgdOwKGNT DHsvpkltEy57DgHeG6Rh1YnryYRrGbgNSgiit+kph1mHY+2Jji2UviQTi90AyYwQy6fU RieO/ExHFBmjfUobH80kmD4JZ4leZkY3OVVsOoYu+Nn1kUXm0dM4QA4UhDO1BlKhHAin Ev9JZlGaXSb2YMRO9TTnQ7egIcD1kP5EPT4S0NXn49HrfUvXU2cQv/bXi1ixWvgNztGM bdAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aHMYfKNcbsqXQy9C2yJlvz/lJ8El8/fFgDO8B6HvR7Y=; b=ZxDQ9NByeBaYEicJL+z7Z7hrJ18ZuX4msojsXlmlS1sDZ85k2sMq78634nvyOePxQl vyf1ak+uRU8Bzia4j+LQdqCCP5bshamPczz2x0AltiyS9Z4nFrtGIi+TZVNepsCFhJc/ g8oPc6QfmO9cCxvcFHowpMoEnMFLfwX0YUUTRqqkgoIz07765j3JfySIGqCE20iGY179 upGMPNyKA70o3Z/HMmVw+eKxSrH8gNFZrEIvbMNTW6LOHRTqWxiJrC7dLzBHpqA8jitp 6SwKGb0+2iYe5w1KNbTQ9m15of2NHytC5XSTjU9MgLU6QxuLr/dbybks1K5DcS8sJz5V 0xBQ== X-Gm-Message-State: AJaThX4U9UQDHvNYlLd+2AHtOW5yatd5cZVmMRnj9mfhz4PbuS5gHCXK lROo3vMde5AyRtvz4uDKZ3o= X-Received: by 10.84.171.195 with SMTP id l61mr1725392plb.27.1510351968580; Fri, 10 Nov 2017 14:12:48 -0800 (PST) Received: from [192.168.1.70] (c-73-93-215-6.hsd1.ca.comcast.net. [73.93.215.6]) by smtp.gmail.com with ESMTPSA id 68sm5159801pfk.162.2017.11.10.14.12.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 14:12:47 -0800 (PST) Subject: Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl To: Michael Ellerman , "Tobin C. Harding" , kernel-hardening@lists.openwall.com Cc: "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@vger.kernel.org, Network Development , David Miller References: <1510050731-32446-1-git-send-email-me@tobin.cc> <87k1z12cof.fsf@concordia.ellerman.id.au> From: Frank Rowand Message-ID: <7fa01b32-4db0-3742-067b-955969020953@gmail.com> Date: Fri, 10 Nov 2017 14:12:46 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <87k1z12cof.fsf@concordia.ellerman.id.au> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Michael, Tobin, On 11/08/17 04:10, Michael Ellerman wrote: > "Tobin C. Harding" writes: >> Currently we are leaking addresses from the kernel to user space. This >> script is an attempt to find some of those leakages. Script parses >> `dmesg` output and /proc and /sys files for hex strings that look like >> kernel addresses. >> >> Only works for 64 bit kernels, the reason being that kernel addresses >> on 64 bit kernels have 'ffff' as the leading bit pattern making greping >> possible. > > That doesn't work super well on other architectures :D > > I don't speak perl but presumably you can check the arch somehow and > customise the regex? > > ... >> +# Return _all_ non false positive addresses from $line. >> +sub extract_addresses >> +{ >> + my ($line) = @_; >> + my $address = '\b(0x)?ffff[[:xdigit:]]{12}\b'; > > On 64-bit powerpc (ppc64/ppc64le) we'd want: > > + my $address = '\b(0x)?[89abcdef]00[[:xdigit:]]{13}\b'; > > >> +# Do not parse these files (absolute path). >> +my @skip_parse_files_abs = ('/proc/kmsg', >> + '/proc/kcore', >> + '/proc/fs/ext4/sdb1/mb_groups', >> + '/proc/1/fd/3', >> + '/sys/kernel/debug/tracing/trace_pipe', >> + '/sys/kernel/security/apparmor/revision'); > > Can you add: > > /sys/firmware/devicetree > > and/or /proc/device-tree (which is a symlink to the above). /proc/device-tree is a symlink to /sys/firmware/devicetree/base /sys/firmware contains fdt -- the flattened device tree that was passed to the kernel on boot devicetree/base/ -- the data that is currently in the live device tree. This live device tree is represented as directories and files beneath base/ The information in fdt is directly available in the kernel source tree (possible exception: the bootloader may have modified the fdt, possibly to add/modify the boot command line, add memory size). The information in devicetree/base/ is directly available in the kernel source tree for _most_ architectures, with the same possible exception for the bootloader. ppc64 may also modify this information dynamically after the system is booted. When overlay support is working, overlay device trees will also be able to modify this information dynamically (and again, this information will be directly available in the kernel source tree). Not having read the code in leaking_addresses.pl, trusting that the comments are correct, it seems that /sys/firmware should be in @skip_walk_dirs_abs instead of putting /sys/firmware/devicetree in @skip_parse_files_abs. > We should also start restricting access to that because it may have > potentially interesting physical addresses in it, but that will break > existing tools, so it will need to be opt-in and done over time. > > cheers > From 1583687666683590234@xxx Fri Nov 10 13:57:32 +0000 2017 X-GM-THRID: 1583410491222242898 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread