From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966266AbbBCQFS (ORCPT ); Tue, 3 Feb 2015 11:05:18 -0500 Received: from mail-ig0-f172.google.com ([209.85.213.172]:43323 "EHLO mail-ig0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755996AbbBCQFO (ORCPT ); Tue, 3 Feb 2015 11:05:14 -0500 Message-ID: <54D0F1B7.7020204@android.com> Date: Tue, 03 Feb 2015 08:05:11 -0800 From: Mark Salyzyn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Lukasz Stelmach CC: LKML , Anton Vorontsov , Colin Cross , Kees Cook , Tony Luck , Krzysztof Kozlowski , =?UTF-8?B?QmFydMWCb21pZWog?= =?UTF-8?B?xbtvxYJuaWVya2lld2ljeg==?= Subject: Re: [PATCH v4 4/5] pstore: add pmsg References: <1421194580-20230-1-git-send-email-salyzyn@android.com> <871tmfz06r.fsf%stlman@poczta.fm> <54C91C5A.400@android.com> <54CBF049.7000808@poczta.fm> In-Reply-To: <54CBF049.7000808@poczta.fm> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Sincerely -- Mark Salyzyn