From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755297AbbA3U6C (ORCPT ); Fri, 30 Jan 2015 15:58:02 -0500 Received: from smtpo.poczta.interia.pl ([217.74.65.238]:57472 "EHLO smtpo.poczta.interia.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752637AbbA3U6A (ORCPT ); Fri, 30 Jan 2015 15:58:00 -0500 X-Interia-R: Interia X-Interia-R-IP: 89.65.17.18 X-Interia-R-Helo: <[192.168.0.13]> Message-ID: <54CBF049.7000808@poczta.fm> Date: Fri, 30 Jan 2015 21:57:45 +0100 From: Lukasz Stelmach User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mark Salyzyn 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> In-Reply-To: <54C91C5A.400@android.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="N0gK0h31wDL2ovEVCOaF8Be5GulwqQSPA" X-Interia-Antivirus: OK Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --N0gK0h31wDL2ovEVCOaF8Be5GulwqQSPA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 28.01.2015 18:28, Mark Salyzyn wrote: > On 01/13/2015 04:16 PM, =C5=81ukasz 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 >>> --- >> 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 t= he >> user-space and every single process (modulo MAC/DAC) can log there. Th= e >> messages from user-space are preserved accross reboots as a part of th= e >> kmsg/printk buffer anyway. >> >> What is the advantege of pmsg0 over /dev/kmsg? >=20 > - 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? --=20 By=C5=82o mi bardzo mi=C5=82o. Twoje oczy lubi=C4=85 mn= ie >=C5=81ukasz< i to mnie zgubi (c)SNL= --N0gK0h31wDL2ovEVCOaF8Be5GulwqQSPA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUy/BNAAoJEAC2l2xjkdNxaYcH/AjrUmEcW7XRB3HmOQGrt455 7NOe+zh2kMcb/6kyFd42eBvJpMgCuWmOKg8JpFKrU3nrEQWjMeTWT+3PcMzt/FUE RmHGbi7uqKqaVaroAuj9dgqoAggWJI/K8gamBOf1+kzykluUEkAJSg8IPeJT8n/3 bLB5BzTYgzRGux5wtECG0qbLG30HVzS9NcDFLld8YF6MQuMewmYKqe2/qUYpVaPk 1lzG5jiaA56jJdMwB/eJS4Fqzjom6ZA1cK1V2oXnN6kG/TYakYGTZl7KXUOjOTtI f9PI4HH1/HF+U8K5WJnLx4rU56hKvBG9zErR9S0BuzljGG4M6ZTXz4QIbzXnNkM= =gKkR -----END PGP SIGNATURE----- --N0gK0h31wDL2ovEVCOaF8Be5GulwqQSPA--