On Thu, 2017-01-12 at 21:16 +1100, Cyril Bur wrote: > My aim here was to only have one process playing with the LPC mapping > registers at a time. > > > Again, use UIO, it will save you from yourself... > > > > Thank-you! This is the first I've heard of UIO and I'll investigate > furthur! Greg, I don't think UIO is the answer here either. Note, this isn't an exploit so much as root shooting itself in the foot as this driver should never be accessed by anybody but root, but see below. This is a BMC, ie, the system controller of a x86 or POWER based system. The LPC controller controls the LPC bus which is mastered by the "host" (ie. the x86 or PPC) and acts as a slave on the BMC side. It has a bunch of registers that need to be configured in more/less system specific ways by the BMC, but more so, it has a pair of registers that allow "mapping" of a region of the BMC physical address space into the host address space. This is by definition dangerous to configure since it gives you a window to any part of the BMC, kernel space, any IOs, etc... however it needs to be configured by a userspace daemon which communicates with the host via a mailbox in order to map either different portions of the system flash controller address space or reserved memory. So in fact it should be done by the kernel, not userspace. What Cyril needs to do to make it more secure is: - For random register accesses, white list what registers specifically are allowed (and if necessary filter values). These registers aren't dangerous from the BMC perspective and need to be set appropriately for the host to operate correctly. - For the mapping of the LPC FW space <-> BMC space, use ioctl's to explicit establish the mapping to a portion of the flash (and nowhere else) or one of the known reserved memory areas. IE, dont have userspace just pass raw physical addresses through, but tell the kernel driver what portion (offset/size) of what area (flash space or reserved memory region) to configure the HW window for. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
