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

[Rashmica Gupta]

On Tue, May 8, 2018 at 2:01 PM, Joel Stanley <joel at jms.id.au> wrote:
> 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.
>

Good point. So perhaps I should leave this check here and change the
error message to something like:

"Cannot access /sys/kernel/debug/powerpc/scom. Is
CONFIG_SCOM_DEBUGFS set? You may need to re-run the command
as 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