From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754213AbcDNJcl (ORCPT ); Thu, 14 Apr 2016 05:32:41 -0400 Received: from brown.birch.relay.mailchannels.net ([23.83.209.23]:19822 "EHLO brown.birch.relay.mailchannels.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754053AbcDNJch (ORCPT ); Thu, 14 Apr 2016 05:32:37 -0400 X-Sender-Id: wwwh|x-authuser|ed@abdsec.com X-Sender-Id: wwwh|x-authuser|ed@abdsec.com X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|ed@abdsec.com X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1460626368335:3932522922 X-MC-Ingress-Time: 1460626368334 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 14 Apr 2016 03:39:05 -0400 From: Emrah Demir To: Kees Cook Cc: Linus Torvalds , Linux Kernel Mailing List , Dan Rosenberg , kernel-hardening@lists.openwall.com, Dave Jones , keescook@google.com Subject: Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file In-Reply-To: References: <1459947782-5071-1-git-send-email-ed@abdsec.com> Message-ID: User-Agent: Roundcube Webmail/1.0.6 X-AuthUser: ed@abdsec.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016-04-14 00:27, Kees Cook wrote: > On Wed, Apr 6, 2016 at 2:19 PM, Linus Torvalds > wrote: >> On Wed, Apr 6, 2016 at 10:54 AM, Linus Torvalds >> wrote: >>> >>> So I'd find a patch like the attached to be perfectly acceptable (in >>> fact, we should have done this long ago). >> >> I just committed it, let's see if some odd program uses the iomem >> data. I doubt it, and I always enjoy improvements that remove more >> lines of code than they add. > > Hrm, it looks like at least Ubuntu's kernel security test suite > expects to find these entries (when it verifies that STRICT_DEVMEM > hasn't regressed). Also, the commit only removed the entries on x86. > Most (all?) of the other architectures still have them. Could you > revert this for now, and I'll cook up a %pK-based solution for -next? > Actually, I have realized that this patch (Linus's patch) was for x86. I was planning to code the same for other architectures. It seems your method is better. %pK will zero other values in /proc/iomem. Perhaps Ubuntu patch might be a good option.