linux-kernel - Synchronizing userspace and kernel using mmaped memory

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAG3n4CQYZEtYfCjQ_n=iWhwFoaW4x-ovXZh3bNiwbGVtgq+jVg@mail.gmail.com>
Date:	Wed, 11 Apr 2012 13:30:18 +0300
From:	Tomer Margalit <tomermargalit@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	scipioenterprises@...oo.com,
	Nezer Zaidenberg <nzaidenberg@....com>,
	"Zaidenberg, Nezer" <Nezer.Zaidenberg@...energy.com>,
	Amir Averbuch <amir@...h.tau.ac.il>
Subject: Synchronizing userspace and kernel using mmaped memory

Hi All,

I was wondering whether it is possible to use an mmaped byte to
synchronize userspace and kernel.
To elaborate, I have a line of buffers that need to be transfered from
a kernel driver into a userspace daemon, so they can be sent to the
internet.
My current communication scheme is to use a series of mmaped buffers,
copy the data to them, and then when done, set a bit (in that same
memory mapped region), that indicates the page was filled and is ready
for transmission.

I have implemented this scheme in two ways - one is to change the bit
both from kernel and userspace (set the bit when a page is filled and
clear it when emptied).
The other is to only change the bit from kernel, and only read the bit
from userspace (when the page is to be cleared, a custom ioctl is
used).

The problem is that this only works 99% of time. I.e. once in every
million pages, there is a page that the kernel says it has filled
(according to logs), but userspace sees as cleared.
My initial instinct was that this is a bug, and I have tried debugging
it for a long time - with no results.
Figuring it was some kind of "illegal" memory access, I put guard
bytes around the problematic byte - but after checking, they remain
untouched.

So, before I continue debugging, I thought to ask whether this is a
good approach?
Specifically, when writing/reading a memory mapped page from kernel
(or userspace for that matter) - is there any action that needs to be
taken to flush the data or protect it?

Thanks,
  Tomer
--
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/