On Wed, Jan 9, 2013 at 6:29 PM, Lucas De Marchi
wrote:
> On Sun, Jan 6, 2013 at 4:59 PM, Michael Kerrisk (man-pages)
> wrote:
>> Hi Rusty, (and Lucas, and Kees)
>>
>> On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell wrote:
>>> Michael Kerrisk writes:
Hi Rusty,
>>>
>>> Hi Michael,
>>>
On Sun, Jan 6, 2013 at 4:59 PM, Michael Kerrisk (man-pages)
wrote:
> Hi Rusty, (and Lucas, and Kees)
>
> On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell wrote:
>> Michael Kerrisk writes:
>>> Hi Rusty,
>>
>> Hi Michael,
>>
>>> The description here is rather thin. Could you supply a sentence or
>>>
On Sun, Jan 6, 2013 at 4:59 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
Hi Rusty, (and Lucas, and Kees)
On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Michael Kerrisk mtk.manpa...@gmail.com writes:
Hi Rusty,
Hi Michael,
The description here is
On Wed, Jan 9, 2013 at 6:29 PM, Lucas De Marchi
lucas.demar...@profusion.mobi wrote:
On Sun, Jan 6, 2013 at 4:59 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
Hi Rusty, (and Lucas, and Kees)
On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Michael
On Sun, Jan 6, 2013 at 9:24 PM, Kees Cook wrote:
> On Sun, Jan 6, 2013 at 11:59 AM, Michael Kerrisk (man-pages)
> wrote:
>> Hi Rusty, (and Lucas, and Kees)
>>
>> On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell wrote:
>>> Michael Kerrisk writes:
Hi Rusty,
>>>
>>> Hi Michael,
>>>
The
On Sun, Jan 6, 2013 at 11:59 AM, Michael Kerrisk (man-pages)
wrote:
> Hi Rusty, (and Lucas, and Kees)
>
> On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell wrote:
>> Michael Kerrisk writes:
>>> Hi Rusty,
>>
>> Hi Michael,
>>
>>> The description here is rather thin. Could you supply a sentence or
Hi Rusty, (and Lucas, and Kees)
On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell wrote:
> Michael Kerrisk writes:
>> Hi Rusty,
>
> Hi Michael,
>
>> The description here is rather thin. Could you supply a sentence or
>> two for each of MODULE_INIT_IGNORE_MODVERSIONS and
>>
Hi Rusty, (and Lucas, and Kees)
On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Michael Kerrisk mtk.manpa...@gmail.com writes:
Hi Rusty,
Hi Michael,
The description here is rather thin. Could you supply a sentence or
two for each of MODULE_INIT_IGNORE_MODVERSIONS
On Sun, Jan 6, 2013 at 11:59 AM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
Hi Rusty, (and Lucas, and Kees)
On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Michael Kerrisk mtk.manpa...@gmail.com writes:
Hi Rusty,
Hi Michael,
The description here
On Sun, Jan 6, 2013 at 9:24 PM, Kees Cook keesc...@chromium.org wrote:
On Sun, Jan 6, 2013 at 11:59 AM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
Hi Rusty, (and Lucas, and Kees)
On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Michael Kerrisk
Michael Kerrisk writes:
> Hi Rusty,
Hi Michael,
> The description here is rather thin. Could you supply a sentence or
> two for each of MODULE_INIT_IGNORE_MODVERSIONS and
> MODULE_INIT_IGNORE_VERMAGIC that would be suitable for the manual
> page?
>
> Thanks,
There are one or two safety checks
Michael Kerrisk mtk.manpa...@gmail.com writes:
Hi Rusty,
Hi Michael,
The description here is rather thin. Could you supply a sentence or
two for each of MODULE_INIT_IGNORE_MODVERSIONS and
MODULE_INIT_IGNORE_VERMAGIC that would be suitable for the manual
page?
Thanks,
There are one or two
Hi Rusty,
On Mon, Oct 22, 2012 at 9:39 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" writes:
>>> FIX: add flags arg to sys_finit_module()
>>>
>>> Thanks to Michael Kerrisk for keeping us honest.
>>
>> w00t! Thanks, Rusty ;-).
>>
>> Acked-by: Michael Kerrisk
>
> Here's the version I
Hi Rusty,
On Mon, Oct 22, 2012 at 9:39 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes:
FIX: add flags arg to sys_finit_module()
Thanks to Michael Kerrisk for keeping us honest.
w00t! Thanks, Rusty ;-).
Acked-by: Michael Kerrisk
Kees Cook writes:
> Rusty,
>
> I haven't seen this land in your modules-next tree. I just wanted to
> make sure it hadn't gotten lost. I'd like to do some kmod tests
> against linux-next, but I've been waiting for this to appear.
Yes, sorting that out now, they should be in tomorrow's
Kees Cook keesc...@chromium.org writes:
Rusty,
I haven't seen this land in your modules-next tree. I just wanted to
make sure it hadn't gotten lost. I'd like to do some kmod tests
against linux-next, but I've been waiting for this to appear.
Yes, sorting that out now, they should be in
On Mon, Oct 22, 2012 at 12:39 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" writes:
>>> FIX: add flags arg to sys_finit_module()
>>>
>>> Thanks to Michael Kerrisk for keeping us honest.
>>
>> w00t! Thanks, Rusty ;-).
>>
>> Acked-by: Michael Kerrisk
>
> Here's the version I ended up
On Mon, Oct 22, 2012 at 12:39 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes:
FIX: add flags arg to sys_finit_module()
Thanks to Michael Kerrisk for keeping us honest.
w00t! Thanks, Rusty ;-).
Acked-by: Michael Kerrisk
Lucas De Marchi writes:
> On Tue, Oct 23, 2012 at 1:42 PM, Kees Cook wrote:
>> On Mon, Oct 22, 2012 at 9:08 PM, Lucas De Marchi
>> wrote:
>>> sure... but do you realize this will fail in case kernel is checking
>>> module signature and we passed --force to modprobe (therefore mangled
>>> the
Lucas De Marchi lucas.demar...@profusion.mobi writes:
On Tue, Oct 23, 2012 at 1:42 PM, Kees Cook keesc...@chromium.org wrote:
On Mon, Oct 22, 2012 at 9:08 PM, Lucas De Marchi
lucas.demar...@profusion.mobi wrote:
sure... but do you realize this will fail in case kernel is checking
module
On Tue, Oct 23, 2012 at 1:42 PM, Kees Cook wrote:
> On Mon, Oct 22, 2012 at 9:08 PM, Lucas De Marchi
> wrote:
>> On Tue, Oct 23, 2012 at 1:40 AM, Kees Cook wrote:
>>> On Mon, Oct 22, 2012 at 7:37 PM, Lucas De Marchi
>>> wrote:
On Mon, Oct 22, 2012 at 5:39 AM, Rusty Russell
wrote:
On 10/23/2012 08:42 AM, Kees Cook wrote:
Hm, yeah, userspace mangling of a module plus signing would fail.
Seems like mangling and signing aren't compatible. Doing it in
kernel-space (as now written for finit_module) solves that, but it
means that now compression isn't possible if you need both
On Mon, Oct 22, 2012 at 9:08 PM, Lucas De Marchi
wrote:
> On Tue, Oct 23, 2012 at 1:40 AM, Kees Cook wrote:
>> On Mon, Oct 22, 2012 at 7:37 PM, Lucas De Marchi
>> wrote:
>>> On Mon, Oct 22, 2012 at 5:39 AM, Rusty Russell
>>> wrote:
"Michael Kerrisk (man-pages)" writes:
>> FIX: add
On Mon, Oct 22, 2012 at 9:39 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" writes:
>>> FIX: add flags arg to sys_finit_module()
>>>
>>> Thanks to Michael Kerrisk for keeping us honest.
>>
>> w00t! Thanks, Rusty ;-).
>>
>> Acked-by: Michael Kerrisk
>
> Here's the version I ended up
On Mon, Oct 22, 2012 at 9:39 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes:
FIX: add flags arg to sys_finit_module()
Thanks to Michael Kerrisk for keeping us honest.
w00t! Thanks, Rusty ;-).
Acked-by: Michael Kerrisk
On Mon, Oct 22, 2012 at 9:08 PM, Lucas De Marchi
lucas.demar...@profusion.mobi wrote:
On Tue, Oct 23, 2012 at 1:40 AM, Kees Cook keesc...@chromium.org wrote:
On Mon, Oct 22, 2012 at 7:37 PM, Lucas De Marchi
lucas.demar...@profusion.mobi wrote:
On Mon, Oct 22, 2012 at 5:39 AM, Rusty Russell
On 10/23/2012 08:42 AM, Kees Cook wrote:
Hm, yeah, userspace mangling of a module plus signing would fail.
Seems like mangling and signing aren't compatible. Doing it in
kernel-space (as now written for finit_module) solves that, but it
means that now compression isn't possible if you need both
On Tue, Oct 23, 2012 at 1:42 PM, Kees Cook keesc...@chromium.org wrote:
On Mon, Oct 22, 2012 at 9:08 PM, Lucas De Marchi
lucas.demar...@profusion.mobi wrote:
On Tue, Oct 23, 2012 at 1:40 AM, Kees Cook keesc...@chromium.org wrote:
On Mon, Oct 22, 2012 at 7:37 PM, Lucas De Marchi
On Tue, Oct 23, 2012 at 1:40 AM, Kees Cook wrote:
> On Mon, Oct 22, 2012 at 7:37 PM, Lucas De Marchi
> wrote:
>> On Mon, Oct 22, 2012 at 5:39 AM, Rusty Russell wrote:
>>> "Michael Kerrisk (man-pages)" writes:
> FIX: add flags arg to sys_finit_module()
>
> Thanks to Michael Kerrisk
On Mon, Oct 22, 2012 at 7:37 PM, Lucas De Marchi
wrote:
> On Mon, Oct 22, 2012 at 5:39 AM, Rusty Russell wrote:
>> "Michael Kerrisk (man-pages)" writes:
FIX: add flags arg to sys_finit_module()
Thanks to Michael Kerrisk for keeping us honest.
>>>
>>> w00t! Thanks, Rusty ;-).
>>>
On Mon, Oct 22, 2012 at 5:39 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" writes:
>>> FIX: add flags arg to sys_finit_module()
>>>
>>> Thanks to Michael Kerrisk for keeping us honest.
>>
>> w00t! Thanks, Rusty ;-).
>>
>> Acked-by: Michael Kerrisk
>
> Here's the version I ended up
"Michael Kerrisk (man-pages)" writes:
>> FIX: add flags arg to sys_finit_module()
>>
>> Thanks to Michael Kerrisk for keeping us honest.
>
> w00t! Thanks, Rusty ;-).
>
> Acked-by: Michael Kerrisk
Here's the version I ended up with when I added two flags.
Lucas, is this useful to you?
BTW
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes:
FIX: add flags arg to sys_finit_module()
Thanks to Michael Kerrisk for keeping us honest.
w00t! Thanks, Rusty ;-).
Acked-by: Michael Kerrisk mtk.manpa...@gmail.com
Here's the version I ended up with when I added two flags.
Lucas,
On Mon, Oct 22, 2012 at 5:39 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes:
FIX: add flags arg to sys_finit_module()
Thanks to Michael Kerrisk for keeping us honest.
w00t! Thanks, Rusty ;-).
Acked-by: Michael Kerrisk
On Mon, Oct 22, 2012 at 7:37 PM, Lucas De Marchi
lucas.demar...@profusion.mobi wrote:
On Mon, Oct 22, 2012 at 5:39 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes:
FIX: add flags arg to sys_finit_module()
Thanks to Michael Kerrisk for
On Tue, Oct 23, 2012 at 1:40 AM, Kees Cook keesc...@chromium.org wrote:
On Mon, Oct 22, 2012 at 7:37 PM, Lucas De Marchi
lucas.demar...@profusion.mobi wrote:
On Mon, Oct 22, 2012 at 5:39 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes:
"H. Peter Anvin" writes:
> On 10/18/2012 07:23 PM, Rusty Russell wrote:
>> "H. Peter Anvin" writes:
>>> Given that, I have to say I now seriously question the value of
>>> finit_module(). The kernel can trivially discover if the pointed-to
>>> memory area is a MAP_SHARED mmap() of a file
H. Peter Anvin zytor.com> writes:
> > It is a bit more indirect, but also in practice it's a bit trickier than
> > that. We need to ensure the memory doesn't change underneath us and
> > stays attached to that fd. I can easily see that code slipping and
> > ending in an exploit.
> >
> > But
H. Peter Anvin hpa at zytor.com writes:
It is a bit more indirect, but also in practice it's a bit trickier than
that. We need to ensure the memory doesn't change underneath us and
stays attached to that fd. I can easily see that code slipping and
ending in an exploit.
But that may
H. Peter Anvin h...@zytor.com writes:
On 10/18/2012 07:23 PM, Rusty Russell wrote:
H. Peter Anvin h...@zytor.com writes:
Given that, I have to say I now seriously question the value of
finit_module(). The kernel can trivially discover if the pointed-to
memory area is a MAP_SHARED mmap() of a
On 10/18/2012 07:23 PM, Rusty Russell wrote:
"H. Peter Anvin" writes:
Given that, I have to say I now seriously question the value of
finit_module(). The kernel can trivially discover if the pointed-to
memory area is a MAP_SHARED mmap() of a file descriptor and if so which
file descriptor...
"H. Peter Anvin" writes:
> Given that, I have to say I now seriously question the value of
> finit_module(). The kernel can trivially discover if the pointed-to
> memory area is a MAP_SHARED mmap() of a file descriptor and if so which
> file descriptor... why can't we handle this behind the
On 10/18/2012 08:28 AM, Kees Cook wrote:
The goal for finit_module is to make sure we're getting what's on the
filesystem, not an arbitrary blob, so we can reason about it for
security policy.
Yes, I get that... although I'm starting to think that that might
actually be a really bad idea.
On Thu, Oct 18, 2012 at 7:26 AM, H. Peter Anvin wrote:
> On 10/18/2012 01:05 AM, Michael Kerrisk (man-pages) wrote:
>>>
>>>
>>> So perhaps what we *should* have is something that points to the module
>>> to a (buffer, length) in userspace, and the equivalent of the current
>>> init_module() would
On 10/18/2012 01:05 AM, Michael Kerrisk (man-pages) wrote:
So perhaps what we *should* have is something that points to the module
to a (buffer, length) in userspace, and the equivalent of the current
init_module() would be open() + mmap() + minit_module() + close()?
So, I don't get it. What
On Thu, Oct 18, 2012 at 5:12 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" writes:
>> Sure. But my point that started this subthread was: should we take the
>> opportunity now to add a 'flags' argument to the new finit_module()
>> system call, so as to allow flexibility in extending
On Thu, Oct 18, 2012 at 6:24 AM, H. Peter Anvin wrote:
> On 10/11/2012 03:16 PM, Rusty Russell wrote:
>> "H. Peter Anvin" writes:
>>
>>> On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
Good point. A "whole hog" openat()-style interface is worth thinking about
too.
>>>
>>>
On Thu, Oct 18, 2012 at 6:24 AM, H. Peter Anvin h...@zytor.com wrote:
On 10/11/2012 03:16 PM, Rusty Russell wrote:
H. Peter Anvin h...@zytor.com writes:
On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
Good point. A whole hog openat()-style interface is worth thinking about
too.
On Thu, Oct 18, 2012 at 5:12 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes:
Sure. But my point that started this subthread was: should we take the
opportunity now to add a 'flags' argument to the new finit_module()
system call, so as
On 10/18/2012 01:05 AM, Michael Kerrisk (man-pages) wrote:
So perhaps what we *should* have is something that points to the module
to a (buffer, length) in userspace, and the equivalent of the current
init_module() would be open() + mmap() + minit_module() + close()?
So, I don't get it. What
On Thu, Oct 18, 2012 at 7:26 AM, H. Peter Anvin h...@zytor.com wrote:
On 10/18/2012 01:05 AM, Michael Kerrisk (man-pages) wrote:
So perhaps what we *should* have is something that points to the module
to a (buffer, length) in userspace, and the equivalent of the current
init_module() would
On 10/18/2012 08:28 AM, Kees Cook wrote:
The goal for finit_module is to make sure we're getting what's on the
filesystem, not an arbitrary blob, so we can reason about it for
security policy.
Yes, I get that... although I'm starting to think that that might
actually be a really bad idea.
H. Peter Anvin h...@zytor.com writes:
Given that, I have to say I now seriously question the value of
finit_module(). The kernel can trivially discover if the pointed-to
memory area is a MAP_SHARED mmap() of a file descriptor and if so which
file descriptor... why can't we handle this
On 10/18/2012 07:23 PM, Rusty Russell wrote:
H. Peter Anvin h...@zytor.com writes:
Given that, I have to say I now seriously question the value of
finit_module(). The kernel can trivially discover if the pointed-to
memory area is a MAP_SHARED mmap() of a file descriptor and if so which
file
On Thu, Oct 18, 2012 at 12:12 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" writes:
>> Sure. But my point that started this subthread was: should we take the
>> opportunity now to add a 'flags' argument to the new finit_module()
>> system call, so as to allow flexibility in extending
On 10/11/2012 03:16 PM, Rusty Russell wrote:
> "H. Peter Anvin" writes:
>
>> On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
>>> Good point. A "whole hog" openat()-style interface is worth thinking about
>>> too.
>>
>> *Although* you could argue that you can always simply open the
"Michael Kerrisk (man-pages)" writes:
> Sure. But my point that started this subthread was: should we take the
> opportunity now to add a 'flags' argument to the new finit_module()
> system call, so as to allow flexibility in extending the behavior in
> future? There have been so many cases of
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes:
Sure. But my point that started this subthread was: should we take the
opportunity now to add a 'flags' argument to the new finit_module()
system call, so as to allow flexibility in extending the behavior in
future? There have been so
On 10/11/2012 03:16 PM, Rusty Russell wrote:
H. Peter Anvin h...@zytor.com writes:
On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
Good point. A whole hog openat()-style interface is worth thinking about
too.
*Although* you could argue that you can always simply open the module
On Thu, Oct 18, 2012 at 12:12 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes:
Sure. But my point that started this subthread was: should we take the
opportunity now to add a 'flags' argument to the new finit_module()
system call, so as
Rusty,
On Fri, Oct 12, 2012 at 12:16 AM, Rusty Russell wrote:
> "H. Peter Anvin" writes:
>
>> On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
>>> Good point. A "whole hog" openat()-style interface is worth thinking about
>>> too.
>>
>> *Although* you could argue that you can always
"H. Peter Anvin" writes:
> On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
>> Good point. A "whole hog" openat()-style interface is worth thinking about
>> too.
>
> *Although* you could argue that you can always simply open the module
> file first, and that finit_module() is really
H. Peter Anvin h...@zytor.com writes:
On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
Good point. A whole hog openat()-style interface is worth thinking about
too.
*Although* you could argue that you can always simply open the module
file first, and that finit_module() is really
Rusty,
On Fri, Oct 12, 2012 at 12:16 AM, Rusty Russell ru...@rustcorp.com.au wrote:
H. Peter Anvin h...@zytor.com writes:
On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
Good point. A whole hog openat()-style interface is worth thinking about
too.
*Although* you could argue
[resending because my mobile device decided it
wanted to send HTML, which of course bounced.]
On Oct 10, 2012 12:09 AM, "H. Peter Anvin" wrote:
>
> On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
> > Good point. A "whole hog" openat()-style interface is worth thinking about
> > too.
On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
> Good point. A "whole hog" openat()-style interface is worth thinking about
> too.
*Although* you could argue that you can always simply open the module
file first, and that finit_module() is really what we should have had in
the first
On Tue, Oct 9, 2012 at 11:58 PM, H. Peter Anvin wrote:
> On 10/10/2012 05:54 AM, Michael Kerrisk wrote:
>> Kees,
>>
>>> +SYSCALL_DEFINE2(finit_module, int, fd, const char __user *, uargs)
>>
>> Given the repeated experience of the last few years--new system calls
>> that are in essence revisions
On 10/10/2012 05:54 AM, Michael Kerrisk wrote:
> Kees,
>
>> +SYSCALL_DEFINE2(finit_module, int, fd, const char __user *, uargs)
>
> Given the repeated experience of the last few years--new system calls
> that are in essence revisions of older system calls with a 'flags'
> argument bolted on to
Kees,
> +SYSCALL_DEFINE2(finit_module, int, fd, const char __user *, uargs)
Given the repeated experience of the last few years--new system calls
that are in essence revisions of older system calls with a 'flags'
argument bolted on to allow more flexible behavior (e.g., accept4(),
dup3(),
Kees,
+SYSCALL_DEFINE2(finit_module, int, fd, const char __user *, uargs)
Given the repeated experience of the last few years--new system calls
that are in essence revisions of older system calls with a 'flags'
argument bolted on to allow more flexible behavior (e.g., accept4(),
dup3(),
On 10/10/2012 05:54 AM, Michael Kerrisk wrote:
Kees,
+SYSCALL_DEFINE2(finit_module, int, fd, const char __user *, uargs)
Given the repeated experience of the last few years--new system calls
that are in essence revisions of older system calls with a 'flags'
argument bolted on to allow
On Tue, Oct 9, 2012 at 11:58 PM, H. Peter Anvin h...@zytor.com wrote:
On 10/10/2012 05:54 AM, Michael Kerrisk wrote:
Kees,
+SYSCALL_DEFINE2(finit_module, int, fd, const char __user *, uargs)
Given the repeated experience of the last few years--new system calls
that are in essence revisions
On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
Good point. A whole hog openat()-style interface is worth thinking about
too.
*Although* you could argue that you can always simply open the module
file first, and that finit_module() is really what we should have had in
the first
[resending because my mobile device decided it
wanted to send HTML, which of course bounced.]
On Oct 10, 2012 12:09 AM, H. Peter Anvin h...@zytor.com wrote:
On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
Good point. A whole hog openat()-style interface is worth thinking about
Mimi Zohar writes:
> Why? Not only have you had these patches sitting for a while, way
> before you had the kernel module patches, they've been acked/signed off
> by Kees, Serge, Eric, and myself. All security subtree maintainers.
> The module patches could have easily been built on top of
On Thu, Oct 4, 2012 at 8:50 PM, Rusty Russell wrote:
> Mimi Zohar writes:
>> Why? Not only have you had these patches sitting for a while, way
>> before you had the kernel module patches, they've been acked/signed off
>> by Kees, Serge, Eric, and myself. All security subtree maintainers.
>>
On Thu, Oct 4, 2012 at 8:50 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Mimi Zohar zo...@linux.vnet.ibm.com writes:
Why? Not only have you had these patches sitting for a while, way
before you had the kernel module patches, they've been acked/signed off
by Kees, Serge, Eric, and myself.
Mimi Zohar zo...@linux.vnet.ibm.com writes:
Why? Not only have you had these patches sitting for a while, way
before you had the kernel module patches, they've been acked/signed off
by Kees, Serge, Eric, and myself. All security subtree maintainers.
The module patches could have easily been
On Wed, Oct 3, 2012 at 10:39 PM, Rusty Russell wrote:
> Kees Cook writes:
>
>> On Thu, Sep 20, 2012 at 3:14 PM, Kees Cook wrote:
>>> As part of the effort to create a stronger boundary between root and
>>> kernel, Chrome OS wants to be able to enforce that kernel modules are
>>> being loaded
As part of the effort to create a stronger boundary between root and
kernel, Chrome OS wants to be able to enforce that kernel modules are
being loaded only from our read-only crypto-hash verified (dm_verity)
root filesystem. Since the init_module syscall hands the kernel a module
as a memory
On Thu, 2012-10-04 at 15:09 +0930, Rusty Russell wrote:
> Kees Cook writes:
>
> > On Thu, Sep 20, 2012 at 3:14 PM, Kees Cook wrote:
> >> As part of the effort to create a stronger boundary between root and
> >> kernel, Chrome OS wants to be able to enforce that kernel modules are
> >> being
On Thu, 2012-10-04 at 15:09 +0930, Rusty Russell wrote:
Kees Cook keesc...@chromium.org writes:
On Thu, Sep 20, 2012 at 3:14 PM, Kees Cook keesc...@chromium.org wrote:
As part of the effort to create a stronger boundary between root and
kernel, Chrome OS wants to be able to enforce that
As part of the effort to create a stronger boundary between root and
kernel, Chrome OS wants to be able to enforce that kernel modules are
being loaded only from our read-only crypto-hash verified (dm_verity)
root filesystem. Since the init_module syscall hands the kernel a module
as a memory
On Wed, Oct 3, 2012 at 10:39 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Kees Cook keesc...@chromium.org writes:
On Thu, Sep 20, 2012 at 3:14 PM, Kees Cook keesc...@chromium.org wrote:
As part of the effort to create a stronger boundary between root and
kernel, Chrome OS wants to be able
Kees Cook writes:
> On Thu, Sep 20, 2012 at 3:14 PM, Kees Cook wrote:
>> As part of the effort to create a stronger boundary between root and
>> kernel, Chrome OS wants to be able to enforce that kernel modules are
>> being loaded only from our read-only crypto-hash verified (dm_verity)
>> root
On Thu, Sep 20, 2012 at 3:14 PM, Kees Cook wrote:
> As part of the effort to create a stronger boundary between root and
> kernel, Chrome OS wants to be able to enforce that kernel modules are
> being loaded only from our read-only crypto-hash verified (dm_verity)
> root filesystem. Since the
On Thu, Sep 20, 2012 at 3:14 PM, Kees Cook keesc...@chromium.org wrote:
As part of the effort to create a stronger boundary between root and
kernel, Chrome OS wants to be able to enforce that kernel modules are
being loaded only from our read-only crypto-hash verified (dm_verity)
root
Kees Cook keesc...@chromium.org writes:
On Thu, Sep 20, 2012 at 3:14 PM, Kees Cook keesc...@chromium.org wrote:
As part of the effort to create a stronger boundary between root and
kernel, Chrome OS wants to be able to enforce that kernel modules are
being loaded only from our read-only
On 09/20/2012 07:22 PM, James Morris wrote:
> On Thu, 20 Sep 2012, Kees Cook wrote:
>
>> Earlier proposals for appending signatures to kernel modules would not be
>> useful in Chrome OS, since it would involve adding an additional set of
>> keys to our kernel and builds for no good reason: we
On 09/20/2012 07:22 PM, James Morris wrote:
On Thu, 20 Sep 2012, Kees Cook wrote:
Earlier proposals for appending signatures to kernel modules would not be
useful in Chrome OS, since it would involve adding an additional set of
keys to our kernel and builds for no good reason: we already
On Fri, 2012-09-21 at 12:22 +1000, James Morris wrote:
> On Thu, 20 Sep 2012, Kees Cook wrote:
>
> > Earlier proposals for appending signatures to kernel modules would not be
> > useful in Chrome OS, since it would involve adding an additional set of
> > keys to our kernel and builds for no good
On Thu, Sep 20, 2012 at 7:22 PM, James Morris wrote:
> On Thu, 20 Sep 2012, Kees Cook wrote:
>
>> Earlier proposals for appending signatures to kernel modules would not be
>> useful in Chrome OS, since it would involve adding an additional set of
>> keys to our kernel and builds for no good
On Thu, 20 Sep 2012, Kees Cook wrote:
> Earlier proposals for appending signatures to kernel modules would not be
> useful in Chrome OS, since it would involve adding an additional set of
> keys to our kernel and builds for no good reason: we already trust the
> contents of our root filesystem.
As part of the effort to create a stronger boundary between root and
kernel, Chrome OS wants to be able to enforce that kernel modules are
being loaded only from our read-only crypto-hash verified (dm_verity)
root filesystem. Since the init_module syscall hands the kernel a module
as a memory
As part of the effort to create a stronger boundary between root and
kernel, Chrome OS wants to be able to enforce that kernel modules are
being loaded only from our read-only crypto-hash verified (dm_verity)
root filesystem. Since the init_module syscall hands the kernel a module
as a memory
On Thu, 20 Sep 2012, Kees Cook wrote:
Earlier proposals for appending signatures to kernel modules would not be
useful in Chrome OS, since it would involve adding an additional set of
keys to our kernel and builds for no good reason: we already trust the
contents of our root filesystem. We
On Thu, Sep 20, 2012 at 7:22 PM, James Morris jmor...@namei.org wrote:
On Thu, 20 Sep 2012, Kees Cook wrote:
Earlier proposals for appending signatures to kernel modules would not be
useful in Chrome OS, since it would involve adding an additional set of
keys to our kernel and builds for no
On Fri, 2012-09-21 at 12:22 +1000, James Morris wrote:
On Thu, 20 Sep 2012, Kees Cook wrote:
Earlier proposals for appending signatures to kernel modules would not be
useful in Chrome OS, since it would involve adding an additional set of
keys to our kernel and builds for no good reason:
98 matches
Mail list logo
