kernel-hardening - Re: refactor tasklets to avoid unsigned long argument

Follow @Openwall on Twitter for new release announcements and other news

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

Date: Wed, 3 Jul 2019 17:48:42 +0200
From: Romain Perier <romain.perier@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: Kernel Hardening <kernel-hardening@...ts.openwall.com>, 
	Shyam Saini <mayhs11saini@...il.com>
Subject: Re: refactor tasklets to avoid unsigned long argument

It Looks interesting :)

Mhhh, so If I understand it right, the purpose of this task is to
remove the "unsigned long data"  argument passed to tasklet_init() ,
that
is mostly used to pass the pointer of the parent structure that
contains the tasklet_struct to the handler.

We don't change the API of tasklet, we simply remove the code that use
this "unsigned long data" wrongly to pass the pointer of the parent
structure
(by using container_of() or something equivalent).

For example this is the case in:   drivers/firewire/ohci.c   or
drivers/s390/block/dasd.c  .

Several question come:

1. I am not sure but, do we need to modify the prototype of
tasklet_init() ?  well, this "unsigned long data" might be use for
something else that pass the pointer of the parent struct. So I would
say "no"

2. In term of security, this is a problem ? Or this is just an
improvement to force developpers to do things correctly ?

I will update the WIKI

Thanks,
Regards,
Romain

Le mar. 2 juil. 2019 à 23:04, Kees Cook <keescook@...omium.org> a écrit :
>
> On Tue, Jul 02, 2019 at 09:35:17AM +0200, Romain Perier wrote:
> > I would be interested by this task (so I will mark it as "WIP" on the
> > wiki). I just need context :)
>
> Sounds good!
>
> This task is similar to the struct timer_list refactoring. Instead of
> passing an arbitrary "unsigned long" argument, it's better that the
> "parent" structure that holds the tasklet should be found using
> container_of(), and the argument should be the tasklet itself.
>
> Let me know if you need more detail on what that should look like! (And
> as always, double-check the sanity of this work: perhaps the refactoring
> creates more problems than it solves? Part of this work item is
> evaluating the work itself.)
>
> Thanks!
>
> --
> Kees Cook

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.