Date: Wed, 16 Nov 2011 08:00:00 +0200 From: Maxim Ignatenko <gelraen.ua@gmail.com> To: mdf@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: Communication between kernel and userspace via local socket Message-ID: <201111160800.02270.gelraen.ua@gmail.com> In-Reply-To: <CAMBSHm-d4chsZpZKo1ufuYJtKTw%2BL6_z3i7HL4Ad=8KOpuK6eQ@mail.gmail.com> References: <201111152218.41031.gelraen.ua@gmail.com> <CAMBSHm-d4chsZpZKo1ufuYJtKTw%2BL6_z3i7HL4Ad=8KOpuK6eQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On =D0=B2=D1=82, 15 =D0=BB=D0=B8=D1=81 2011 23:17:41 mdf@freebsd.org wrote: > On Tue, Nov 15, 2011 at 12:18 PM, Maxim Ignatenko <gelraen.ua@gmail.com>= =20 wrote: > > frHi, > >=20 > > I'm currently inventing the wheel^W^W^Wwriting a firewall from scratch > > and looking for most convenient way to establish communication between > > userspace processes and kernel part. Communication pattern best fits to > > listening PF_LOCAL socket opened from kernel and userspace processes > > connecting to it. Clients should be able to send requests and receive > > responses from kernel (to retrieve list of loaded modules, active > > ruleset, add or remove rules, ...) and vice versa: kernel should be able > > to send request to userspace process and receive response (I'm planning > > to add interactive features like in most firewalls for windows(r)). > >=20 > > First part can be implemented via ioctl, but it should be called not on= ly > > by processes with euid =3D=3D 0, so supplied pointer to receive buffer > > cannot be trusted (is there any mechanism to check memory allocation?) > > and any unprivileged user can instruct kernel to write some trash at > > arbitrary address (for example, VM just rebooted ungracefully when I > > supplied (void*)123 as pointer to destination buffer). >=20 > Were you using copyout(9)? I think FreeBSD's memory isolation between > processes is pretty decent. I would be very surprised if copyout to an > invalid address did something other than return EFAULT. At least the > amd64 implementation of copyout(9) will also explicitly check that the > address is a user address, so that you can't corrupt kernel memory > with a rogue pointer from user-space. >=20 Yep. I've used this https://gitorious.org/acpi_call-freebsd/acpi_call- freebsd/blobs/master/acpi_call.c#line49 for tests.=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201111160800.02270.gelraen.ua>