linux-kernel - Re: RFC: android logger feedback request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPXgP12jQg+n=-=R+K8J+5Np97QesoKRApxaRtYvd1Jf-LnhzA@mail.gmail.com>
Date:	Thu, 22 Dec 2011 16:13:37 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	NeilBrown <neilb@...e.de>, Tim Bird <tim.bird@...sony.com>,
	Greg KH <gregkh@...e.de>,
	linux-embedded <linux-embedded@...r.kernel.org>,
	linux kernel <linux-kernel@...r.kernel.org>,
	john stultz <johnstul@...ibm.com>,
	Brian Swetland <swetland@...gle.com>,
	Lennart Poettering <lennart@...ttering.net>
Subject: Re: RFC: android logger feedback request

On Thu, Dec 22, 2011 at 15:59, Arnd Bergmann <arnd@...db.de> wrote:

> * Remove all kernel code for this and use a user space library together
>  with tmpfs
> * prepopulate the tmpfs at boot time with all the log buffers in the right
>  size, and set the maximum file system size so that they cannot grow further.
> * Have minimal formatting in the log buffer: A few bytes header (ring buffer
>  start and end)
> * Mandate that user space must use mmap and atomic operations to reserve space
>  in the log and write to the files.
> * Provide a tool to get the log data out of the buffer again in a race-free way.
>
> Since any program that is allowed to write to the buffer can overwrite all
> existing information in it anyway, I think we don't actually need any kernel
> help in maintaining consistency of the contents either -- the reader will
> simply discard any data. The main thing we would not be able to guarantee
> without kernel help is proving the origin of individual messages, but I'm
> not sure if that is a design goal.

I'm very sure you want rate limiting, global sequence numbers and
trusted properties added to the log.

I can imagine that the kernel provides a single character device,
instantiates a tmpfs mountpoint and splits all stuff that travels into
that device into several files (ring buffers) in the tmpfs filesystem.
The files are probably just split by the uid of the incoming message
sender, which maps to an app at Android.

Only the character device would be able to write to the file, but the
user with the matching uid can read its own file back directly from
tmpfs.

I'm very convinced that we should not design a logging system today,
where we give the ownership of the data to the actual untrusted
process that logs.

The current kmsg buffer could just be one additional file in this tmpfs mount.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/