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  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]
Date:	Mon, 21 Mar 2016 09:47:10 +0200
From:	Alexander Shishkin <>
To:	Chunyan Zhang <>,
Subject: Re: [RESEND PATCH V4 1/4] stm class: provision for statically assigned masterIDs

Chunyan Zhang <> writes:

> From: Mathieu Poirier <>
> Some architecture like ARM assign masterIDs at the HW design
> phase.  Those are therefore unreachable to users, making masterID
> management in the generic STM core irrelevant.
> In this kind of configuration channels are shared between masters
> rather than being allocated on a per master basis.
> This patch adds a new 'mshared' flag to struct stm_data that tells the
> core that this specific STM device doesn't need explicit masterID
> management.

There are two kinds of 'masterIDs' that we're talking about here: the
ones that turn up in the STP stream and the ones that are accessible to
trace-side software (sw_start/sw_end). So in this case we want to
reflect the fact that there is no correlation between the two, because
hardware assigns STP channels dynamically based on the states of the
trace/execution environment. And although the trace side software can do
very little with this information, it does make sense to provide it.

The sw_start==sw_end situation, on the other hand, is a side effect of
the above and, as I said in one of the previous threads, may not even be
the case, or at least I don't see why it has to. And when it is the
case, I don't see the point in handling it differently from
sw_start<sw_end situation.

> In the core sw_start/end of masterID are set to '1',
> i.e there is only one masterID to deal with.

Why does this need to be done in the core and why '1'? IOW,
sw_{start,end} come straight from the driver, this new 'mshared' comes
straight from the driver, why do we need the core to modify the former
based on the latter?

> Also this patch depends on [1], so that the number of masterID
> is '1' too.

It's 7b3bb0e753 in Linus' tree, but I don't see the logical connection
in the statement above.


Powered by blists - more mailing lists