Andrew Donnellan <a...@linux.ibm.com> writes: > On 9/5/19 3:54 pm, Andrew Donnellan wrote: >> On 9/5/19 3:37 pm, Nicholas Piggin wrote: >>> Andrew Donnellan's on May 9, 2019 3:11 pm: >>>> SCOM_DEBUGFS is really not needed for anything other than low-level >>>> hardware debugging. >>>> >>>> opal-prd uses its own interface (/dev/prd) for SCOM access, so it >>>> doesn't >>>> need SCOM_DEBUGFS. >>>> >>>> At some point in the future we'll introduce a debug config fragment >>>> where >>>> this can go instead. >>> >>> That doesn't really explain why you want to disable it. It is useful >>> for low level hardware debugging, I added it. >>> >>> obscurity^Wsecurity? >> >> Mostly just a general feeling that it's not something we need to have by >> default. Security-wise, PRD still provides SCOM access, though we are >> going to look at how we can further lock that down. Shrinks the build by >> only a few kilobytes... >> >> mpe said he's planning on adding a debug.config where we can shift stuff >> like this, and if/when we do that I would like to see this moved there, >> but perhaps this patch can wait until then. I'll let mpe decide. > > mpe do you have thoughts on this? I would like to see at least the rest > of this series merged.
I think it should be off by default, it may be true that root can attack/break the system in many other ways, but providing unrestricted SCOM access is a pretty big opening. This is similar to strict /dev/mem IMO, which "everyone" agrees is a good idea these days. It's pretty trivial for folks doing development to turn it on in their local trees, and I would also welcome a debug.config fragment that enables it. So I'll take the whole series. cheers
