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

Joel Stanley joel at jms.id.au
Tue May 8 14:20:39 AEST 2018


On 8 May 2018 at 13:45, Rashmica Gupta <rashmica.g at gmail.com> wrote:
> On Tue, May 8, 2018 at 2:01 PM, Joel Stanley <joel at jms.id.au> wrote:
>>>  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."

Looks good to me! For bonus points, do an audit of each time we open a
file, and add similar messages.

Cheers,

Joel


More information about the Pdbg mailing list