Stephen, On Fri, Jun 27, 2014 at 12:56 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > On 06/27/2014 12:30 PM, Doug Anderson wrote: >> Stephen, >> >> On Fri, Jun 27, 2014 at 11:20 AM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: >>> On 06/27/2014 10:45 AM, Doug Anderson wrote: >>>> Stephen, >>>> >>>> On Fri, Jun 27, 2014 at 9:10 AM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: >>>>> Surely there's a driver (or could be a driver) for the TPM chip, and >>>>> that driver should have a reset-mask-gpios property, so the driver can >>>>> call gpio_get() and gpio_set_output() on the GPIO? >>>>> >>>>> Faking this out via a not-really-a-regulator or pinctrl hogs seems like >>>>> an abuse of those features to me. > ... >>> As an aside, why do we even care about this? The kernel clearly can >>> unlock the TPM simply by failing to set the GPIO up correctly, so at >>> best this is security through obscurity. If someone actively wanted to >>> do something bad to the TPM, they'd simply comment out this piece of >>> code in the kernel. At least that's true with usptream kernels which >>> aren't validated at all during boot. For a downstream signed kernel, >>> perhaps this patch makes sense (although I haven't thought about all the >>> security angles), but then it'd make sense to keep this patch downstream. >> >> Check out the bullet point about the firmware checking for kernel >> cheats. At resume time the chip actually re-loads read only firmware >> out of SPI flash (no choice about this). This read only firmware can >> check the state of the mask pin (which is preserved across sleep wake) >> to see if the kernel cheated. > > Ah, that covers the security issues then. > > I'd argue that the RO firmware should be setting up GPIOs like this > myself (and the pinmux, from a nice big table), and the kernel simply > not touch it all since it has no direct use for the pin. But I suppose > if the firmware is already baked and read only, that's not possible. Yes. Earlier in this thread I said I had no idea why I didn't have firmware set this up. I couldn't come up with a good reason... :( -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |