Re: [PATCH v4 4/5] pstore: add pmsg

[Mark Salyzyn <salyzyn@android.com>]

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