linux-kernel - Re: [PATCH] Tracing events with GPIOs

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]

Date:	Fri, 3 Jan 2014 19:50:14 +0900
From:	Alexandre Courbot <gnurou@...il.com>
To:	Jean-Jacques Hiblot <jjhiblot@...phandler.com>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Tracing events with GPIOs

On Fri, Dec 20, 2013 at 5:40 PM, Jean-Jacques Hiblot
<jjhiblot@...phandler.com> wrote:
> 2013/12/20 Alexandre Courbot <gnurou@...il.com>:
>> On Thu, Dec 19, 2013 at 8:38 PM, Jean-Jacques Hiblot
>> <jjhiblot@...phandler.com> wrote:
>>> 2013/12/19 Alexandre Courbot <gnurou@...il.com>:
>>>> The problems I can see so far:
>>>>
>>>> - Using gpiod, GPIOs are not specified as integers, but are typically
>>>> mapped to a given (device, function) pair (device can be NULL) using
>>>> device tree/platform data/ACPI and obtained by the corresponding
>>>> device driver through gpiod_get(). You would need to find a different
>>>> way to specify GPIOs, maybe using the gpio_chip's label and the GPIO
>>>> hardware number.
>>>>
>>>> - Even if you do so, there is currently no way to arbitrarily obtain a
>>>> GPIO that has not been explicitly mapped to a (device, function), and
>>>> IIUC you need to specify the tracing GPIO freely from user-space. This
>>>> hints that we will need to add a function that is sensibly the same as
>>>> gpio_request_one() to the gpiod API, but I wonder if that does not
>>>> defeats the purpose somehow.
>>>
>>> This is something I was wondering about for another reason. In many
>>> cases the GPIOs that are physically available for probing will be
>>> limited to the GPIOs already assigned a function (backlight control
>>> for example), others are usually not routed except in eval boards or
>>> early prototypes. And consequently those GPIOs will be requested by a
>>> driver long before a probe is set.
>>> It would be nice not to have to remove the driver to be able to use
>>> this GPIO  as a probe. Maybe a gpiod_steal() interface and a flag
>>> indicating that the GPIO can be safely stolen?
>>
>> Mmm an explicit way to hijack a GPIO does not sound very safe. Do you
>> have concrete cases where you need to do so? I guess most boards you
>> may want to use this patch with would have at least some spare GPIOs
>> with pins somewhere on the board for this kind of purpose.
> It's not always true. There are quite a few platforms where GPIOs is a
> scarce resource (ppc for example). For example, the board I'm working
> on at the moment is built around a APM powerpc which has only 16
> GPIOs. Of those 16 GPIOS, some are not routed and most of the others
> are hidden by the shielding so that I can probe only those that go to
> external connectors.
> IMHO it's probably the case for most of the boards that go into a
> final product where EMI and space constraints are tight.
> But I agree that's not safe. I thought that maybe a flag indicating
> when it is safe would help (on my board that would be : ok to use the
> GPIO that turns on or off the backlight, not ok to use the GPIO that
> controls the power supply)

Rather than a flag per GPIO or board (my definition of "safe" is
rather strict ; I'd consider being able to mess with the backlight as
unsafe), I think I'd be more comfortable with having this as a kernel
config option, defaulting to 'n', and clearly stating that this can
potentially allow any GPIO to be hijacked (which is, apart for the
last point, what you already did). That way people can make an
informed decision about whether to enable it or not (disabled for
distro kernels, enabled for the occasional hacker who wants to use
this feature).

But before doing this, I'd like to make sure we explore every
possibility to make this safer by design.
--
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/