lkml.org 
[lkml]   [2015]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 4/5] pstore: add pmsg
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


\
 
 \ /
  Last update: 2015-02-03 17:21    [W:1.092 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site