Messages in this thread | | | Date | Tue, 19 Jan 2021 10:42:47 +0530 | From | Sai Prakash Ranjan <> | Subject | Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode tracing |
| |
On 2021-01-18 20:17, Mattias Nissler wrote: > On Fri, Jan 15, 2021 at 6:46 AM Sai Prakash Ranjan > <saiprakash.ranjan@codeaurora.org> wrote: >> >> Hello Mathieu, Suzuki >> >> On 2020-10-15 21:32, Mathieu Poirier wrote: >> > On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote: >> >> On production systems with ETMs enabled, it is preferred to >> >> exclude kernel mode(NS EL1) tracing for security concerns and >> >> support only userspace(NS EL0) tracing. So provide an option >> >> via kconfig to exclude kernel mode tracing if it is required. >> >> This config is disabled by default and would not affect the >> >> current configuration which has both kernel and userspace >> >> tracing enabled by default. >> >> >> > >> > One requires root access (or be part of a special trace group) to be >> > able to use >> > the cs_etm PMU. With this kind of elevated access restricting tracing >> > at EL1 >> > provides little in terms of security. >> > >> >> Apart from the VM usecase discussed, I am told there are other >> security concerns here regarding need to exclude kernel mode tracing >> even for the privileged users/root. One such case being the ability >> to analyze cryptographic code execution since ETMs can record all >> branch instructions including timestamps in the kernel and there may >> be other cases as well which I may not be aware of and hence have >> added Denis and Mattias. Please let us know if you have any questions >> further regarding this not being a security concern. > > Well, the idea that root privileges != full control over the kernel > isn't new and at the very least since lockdown became part of mainline > [1] no longer an esoteric edge case. Regarding the use case Sai hints > at (namely protection of secrets in the kernel), Matthew Garret > actually has some more thoughts about confidentiality mode for > lockdown for secret protection [2]. And thus, unless someone can make > a compelling case that instruction-level tracing will not leak secrets > held by the kernel, I think an option for the kernel to prevent itself > from being traced (even by root) is valuable. > > Finally, to sketch a practical use case scenario: Consider a system > where disk contents are encrypted and the encryption key is set up by > the user when mounting the file system. From that point on the > encryption key resides in the kernel. It seems reasonable to expect > that the disk encryption key be protected from exfiltration even if > the system later suffers a root compromise (or even against insiders > that have root access), at least as long as the attacker doesn't > manage to compromise the kernel. > > [1] https://lwn.net/Articles/796866/ > [2] https://mjg59.dreamwidth.org/55105.html >
Thanks for the detailed description, it is way better put than my crude explanation.
Thanks, Sai
-- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
| |