linux-kernel - RE: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87twld3ovy.fsf@ashishki-desk.ger.corp.intel.com>
Date:	Fri, 12 Feb 2016 17:54:41 +0200
From:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:	Al Grant <Al.Grant@....com>,
	Mathieu Poirier <mathieu.poirier@...aro.org>
Cc:	Chunyan Zhang <zhang.chunyan@...aro.org>,
	"robh\@kernel.org" <robh@...nel.org>,
	Mark Brown <broonie@...nel.org>,
	Pratik Patel <pratikp@...eaurora.org>,
	Nicolas GUION <nicolas.guion@...com>,
	Jon Corbet <corbet@....net>,
	Mark Rutland <Mark.Rutland@....com>,
	Mike Leach <Mike.Leach@....com>,
	"Jeremiassen\, Tor" <tor@...com>,
	Lyra Zhang <zhang.lyra@...il.com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel\@lists.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-api\@vger.kernel.org" <linux-api@...r.kernel.org>,
	"linux-doc\@vger.kernel.org" <linux-doc@...r.kernel.org>
Subject: RE: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

Al Grant <Al.Grant@....com> writes:

>> Mike did write "master IDs are hardwired to individual cores and core security
>> states", which make assignment for one platform very static.
>> On the flip side those will change from one system to another.
>
> It depends on your perspective.  From the perspective of a userspace
> process not pinned to a core, the master id will appear to vary
> dynamically and unpredictably as the thread migrates from one
> core to another.  (That's actually useful if the decoder wants to know
> where the thread is running at any given point, as it can find that out
> for free, without the need to track migration events.)
>
> On the other hand if you are pinned (e.g. you're the kernel on a
> particular core, or you're a per-core worker thread in some thread
> pooling system) then you have a fixed master id, and then you can
> have one instance per core all using the same range of channel
> numbers, with the master id indicating the core - this saves on
> channel space compared to having to give each core its own
> range of channel space.

What I understood from Mike's explanation is that basically nothing is
fixed from the software perspective (talking about Coresight STM). One
doesn't know the master id with which one's data will be tagged,
regardless of whether one is cpu-affine or not, because:

 * even per-core master IDs will be highly implementation dependent and
   therefore not knowable by the kernel and subsequently userspace,
 * master IDs may change based on other conditions (besides security
   states), so even if we knew per-core master IDs for sure, it wouldn't
   give us the complete picture.

So even though from the HW perspective master IDs may be "hardwired" to
hardware states, the hardware states themselves are dynamic, so from the
SW perspective these master IDs are not static or hardwired at all.

If the same mmio write done by software would always result in the exact
same master ID tagged to it, that would be more like "static" to me.

Regards,
--
Alex