[Pdbg] [PATCH 1/2] libpdbg: Check if scom controllers are exposed

[Joel Stanley]

On 8 May 2018 at 13:23, Rashmica Gupta <rashmica.g at gmail.com> wrote:
> On Tue, May 8, 2018 at 10:23 AM, Joel Stanley <joel at jms.id.au> wrote:
>> On 8 May 2018 at 09:41, Rashmica Gupta <rashmica.g at gmail.com> wrote:
>>> If CONFIG_SCOM_DEBUGFS is not set in the running kernel then
>>> the scom controllers are not exposed and so using getscom
>>> won't work. Add check for /sys/kernel/debug/powerpc/scom to
>>> give a more useful error message.
>>>
>>> Signed-off-by: Rashmica Gupta <rashmica.g at gmail.com>
>>> ---
>>>  libpdbg/host.c | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/libpdbg/host.c b/libpdbg/host.c
>>> index f43b355..cf71e5c 100644
>>> --- a/libpdbg/host.c
>>> +++ b/libpdbg/host.c
>>> @@ -95,6 +95,13 @@ static int host_pib_probe(struct pdbg_target *target)
>>>         if (chip_id == -1)
>>>                 goto out;
>>>
>>> +       /* This check should probably be done earlier */
>>> +       if (access(XSCOM_BASE_PATH, F_OK) == -1)
>>> +       {
>>> +               fprintf(stderr, "Can not access %s. ", XSCOM_BASE_PATH);
>>> +               fprintf(stderr, "Is CONFIG_SCOM_DEBUGFS set?\n");
>>
>> We're in the same boat if the user runs without sufficient permission
>> (debugfs is usually not readable for normal users).
>
>  I was thinking of adding a check to see if we have root permissions
> earlier in the process. Do all things require root permission? (I've
> only played around with getscom and htm so far)
>

We looked at doing that recently, but decided we didn't need to go
that far. There are some commands where you don't need to be root:

 https://lists.ozlabs.org/pipermail/pdbg/2018-April/000112.html

I think a better way of looking at it is testing for the things we
actually need - is it /dev/mem, is it write permission to
/sys/kernel/debug/scoms, etc? and bailing out if we don't have that
permission. That way, if down the track the tool eg. doesn't need
write permission, and read permission is available, we don't have
something running as root.

On the BMC this could be a udev rule that has given read/write
permission to /dev/scom{1,2}, which are the userspace interfaces for
in-kernel FSI. If that were in place, the person debugging on the BMC
doesn't need to be root.

This is all a bit theoretical, as all use cases where we're running on
target hardware (ppc or arm) need to be root at the moment.

Cheers,

Joel