Messages in this thread | | | Date | Fri, 30 Jan 2015 21:57:45 +0100 | From | Lukasz Stelmach <> | Subject | Re: [PATCH v4 4/5] pstore: add pmsg |
| |
On 28.01.2015 18:28, Mark Salyzyn wrote: > On 01/13/2015 04:16 PM, Łukasz Stelmach wrote: >>> A secured user-space accessible pstore object. Writes >>> to /dev/pmsg0 are appended to the buffer, on reboot >>> the persistent contents are available in >>> /sys/fs/pstore/pmsg-ramoops-[ID]. >>> >>> One possible use is syslogd, or other daemon, can >>> write messages, then on reboot provides a means to >>> triage user-space activities leading up to a panic >>> as a companion to the pstore dmesg or console logs. >>> >>> Signed-off-by: Mark Salyzyn <salyzyn@android.com> >>> --- >> I am not an expert but this smells like duplicating /dev/kmsg. If >> I remember correctly since about Linux 3.5 /dev/kmsg is writable for the >> user-space and every single process (modulo MAC/DAC) can log there. The >> messages from user-space are preserved accross reboots as a part of the >> kmsg/printk buffer anyway. >> >> What is the advantege of pmsg0 over /dev/kmsg? > > - 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.
> - 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.
> - State, Binary or packetized content can go to /dev/pmsg0 and > not interfere with the text content in kmsg
Indeed kmsg can't store arbitrary binary data. However it can, store key/value pairs next to text and there is base64 too. Yes, this one seems a little bit better than kmsg.
> - /dev/pmsg0 write is atomic
devkmsg_write + vprintk_emit are atomic too.
> - /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?
> - 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.
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?
-- Było mi bardzo miło. Twoje oczy lubią mnie >Łukasz< i to mnie zgubi (c)SNL
[unhandled content-type:application/pgp-signature] | |