[Intel-gfx] pin OABUFFER to GGTT

[Rutkowski, Adam J]

Hi

> Chris alludes to the fact that if there's a way for one application to gather
> data about other applications (whatever kind of data), that's an automatic
> security concern.

We have a few use cases for OA buffer and "one application to gather data about other applications" is basically a definition of at least some of them. 

> I'm unclear why they need the offset. Can it not work like any other relocation, except with the requirement that it's in the GGTT?
We read OA_TAIL_PTR register via batch buffer (SRM) and we need to subtract OA buffer offset from it to get the relative tail.

Currently in most cases we write to OACONTROL, OABUFFER and other OA registers via MMIO in user mode.

I suppose your answer is to move OA ownership to kernel and provide new API for this. This is fine for us as long as multiple non-root applications are able to freely access contents of OA buffer in an efficient manner. We are ok with limiting other functionalities (like setting up / programming OA) to root only. 

One more thing. Assuming usermode has OA buffer mapped I don't see how to avoid exposing of OA buffer offset to user mode in real life scenarios. To profile selected commands usermode driver must read OA_TAIL_PTR via SRM (so that it is written to memory together with perf counters). And it needs to know how the value read translates to offset in OA buffer. This implies usermode needs to know OA buffer offset (since the address in OA_BUFFER_PTR is not relative to the buffer boundary). 

Having said all this, how about restoring the pin_ioctl? At least for some time? We do have a use case and moving to other - better - solution would take time. I think backward compatibility is something that you take into consideration as well.

Thanks
Adam

> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf
> Of Madajczak, Tomasz
> Sent: Wednesday, July 2, 2014 1:12 PM
> To: Lespiau, Damien
> Cc: Ben Widawsky; Intel-gfx at lists.freedesktop.org
> Subject: Re: [Intel-gfx] pin OABUFFER to GGTT
> 
> bo_pin had so far root privileges - they were sufficient and it would be
> enough to get bo_pin back the same way. This also implies that root can only
> start the OA buffer measurements.
> 
> -Tomasz
> 
> -----Original Message-----
> From: Lespiau, Damien
> Sent: Wednesday, July 02, 2014 12:49 PM
> To: Madajczak, Tomasz
> Cc: Mateo Lozano, Oscar; Chris Wilson; Ben Widawsky; Intel-
> gfx at lists.freedesktop.org
> Subject: Re: [Intel-gfx] pin OABUFFER to GGTT
> 
> On Wed, Jul 02, 2014 at 10:31:45AM +0000, Madajczak, Tomasz wrote:
> > There isn't any secret or privacy in that OA buffer data - just
> > results of performance counters, shown by tools such as GPA/ Vtune.
> 
> Chris alludes to the fact that if there's a way for one application to gather
> data about other applications (whatever kind of data), that's an automatic
> security concern.
> 
> One may think that's only very theoretical, but the side channel attacks are
> (surpringly) real and effective. It cannot be proven easily that exposing data
> about other contexes is totally secure.
> 
> There are ways around that however. If only root can gather that data, I think
> we've contained the issue enough for the case at hand?
> 
> --
> Damien
--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.