From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com 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 In-Reply-To: References: <1459947782-5071-1-git-send-email-ed@abdsec.com> Message-ID: Subject: [kernel-hardening] Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file To: Kees Cook Cc: Linus Torvalds , Linux Kernel Mailing List , Dan Rosenberg , kernel-hardening@lists.openwall.com, Dave Jones , keescook@google.com List-ID: 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.