Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966511AbbBCSVO (ORCPT ); Tue, 3 Feb 2015 13:21:14 -0500 Received: from mail-ob0-f176.google.com ([209.85.214.176]:40147 "EHLO mail-ob0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966181AbbBCSVL (ORCPT ); Tue, 3 Feb 2015 13:21:11 -0500 MIME-Version: 1.0 In-Reply-To: <54D0F1B7.7020204@android.com> References: <1421194580-20230-1-git-send-email-salyzyn@android.com> <871tmfz06r.fsf%stlman@poczta.fm> <54C91C5A.400@android.com> <54CBF049.7000808@poczta.fm> <54D0F1B7.7020204@android.com> Date: Tue, 3 Feb 2015 10:21:10 -0800 X-Google-Sender-Auth: XSlDRvtLx_ll97vC7FBxn-VIvcs Message-ID: Subject: Re: [PATCH v4 4/5] pstore: add pmsg From: Kees Cook To: Mark Salyzyn Cc: Lukasz Stelmach , LKML , Anton Vorontsov , Colin Cross , Tony Luck , Krzysztof Kozlowski , =?UTF-8?B?QmFydMWCb21pZWogxbtvxYJuaWVya2lld2ljeg==?= Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3837 Lines: 99 On Tue, Feb 3, 2015 at 8:05 AM, Mark Salyzyn wrote: > Thanks for your response. > > On 01/30/2015 12:57 PM, Lukasz Stelmach wrote: >> >> On 28.01.2015 18:28, Mark Salyzyn wrote: >>> >>> - Precious little user-space content goes to kmsg (otherwise you >>> can ask why is there a syslogd?), there is a reason for this, user >>> space is notorious for containing Personal Identifiable Information >>> whereas kernel information does not. >> >> Sure it does too: MAC addresses, UUIDs, serial numbers. With mobile >> devices these are actually PII. > > :-) > > Names, Passwords, credit card number, addresses. Personal Identifiable > Information, lawsuits are never lodged against MAC addresses UUIDs or serial > numbers. >>> >>> - pmsg0 can take a lot of content (with a ramoops backend) and >>> will not disrupt/DOS the kernel logs. >> >> Documentation/ramoops.txt says it is for logging kernel oopses >> and panics not user logs. > > I probably should have changed the ramoops.txt content with the addition of > pmsg :-) >> >> >> - /dev/pmsg0 write is atomic >> devkmsg_write + vprintk_emit are atomic too. > > Hmmm, I managed to get content corrupted >>> >>> - /dev/pmsg0 is write only, there is no access to the live content >>> _unless_ there is a reboot. >> >> Why do you consider this an advantage? > > It is more serendipity than design, once this feature was highlighted, it > became a must-have for the security concerns. The current boot instance > contains an environment of files, programs and state information that > combined would be useful for cracking a large amount of PII. Once a kernel > panics what remains is a trace of user-space activities that can be > correlated with kernel activities in order to replay or triage what lead up > to the kernel panic. Yet crippled enough to not be as useful as a vector. >>> >>> - Personal identification which abounds in user space could be placed >>> into /dev/pmsg0, and there is no way except a reboot in order to >>> extract the content, and then /sys/fs/pstore/pmsg-ramoops-0 can be >>> deleted, or heavily MAC and DAC controlled to enforce protection >>> (doing so to kmsg would be unlivable) >> >> Read access to /dev/kmsg can be limited too. > > When you delete /sys/fs/pstore/pmsg-ramoops-0 after moving it to secure > storage, it is gone. Same is separately true for > /sys/fs/pstore/console-ramoops-0, so yes, similar characteristics. The issue > is separation. The issue is also no ability to read the live content of the > user space data until it becomes relevant (kernel panic triage). >> >> >> I think that the goals you present can be met with less code. >> You could try adding support for multiple /dev/kmsg instances >> for example. How about that? > > Not a bad idea. But with multiple kmsg instances, you also get to add code > in pstore to divide it up along with a device tree that decides how much > storage is provided for each instance. I would wager a desire will be > expressed to make sure the live co There is a vacuum.ntent be accessible > with a netlink socket and a new flag in dmesg which would be counter to our > security concerns. > > pstore is all about persistence. kmsg is not, until pstore supports it. A > user-space persistent storehouse felt appropriate to support at the bottom > layer. > FWIW, I prefer keeping "pmsg" separate from "kmsg". They do feel similar, but given the persistence backing, I think it justifies the separation. I'm not sure it's right to change the semantics of kmsg. -Kees > Sincerely -- Mark Salyzyn -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/