On Tue, Feb 3, 2015 at 8:05 AM, Mark Salyzyn <saly...@android.com> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/