On 30/07/2019 21:03, Rob Herring wrote:
> On Thu, Jul 25, 2019 at 9:35 AM Steven Price wrote:
>>
>> On 25/07/2019 15:59, Steven Price wrote:
>> [...]
>>> It would appear that in the following call sgt==NULL:
ret = sg_alloc_table_from_pages(sgt, pages + page_offset,
On 30/07/2019 20:08, Rob Herring wrote:
> On Tue, Jul 30, 2019 at 12:55 PM Alyssa Rosenzweig
> wrote:
>>
>>> In any case, per process AS is a prerequisite to all this.
>>
>> Oh, I hadn't realized that was still a todo. In the meantime, what's the
>> implication of shipping without it? (I.e. in whi
> In any case, per process AS is a prerequisite to all this.
Oh, I hadn't realized that was still a todo. In the meantime, what's the
implication of shipping without it? (I.e. in which threat model are
users vulnerable without it?) Malicious userspace process snooping on
other framebuffers (on X11
On Thu, Jul 25, 2019 at 9:35 AM Steven Price wrote:
>
> On 25/07/2019 15:59, Steven Price wrote:
> [...]
> > It would appear that in the following call sgt==NULL:
> >> ret = sg_alloc_table_from_pages(sgt, pages + page_offset,
> >> NUM_FAULT_PAGES, 0, SZ_2M
On Tue, Jul 30, 2019 at 12:55 PM Alyssa Rosenzweig
wrote:
>
> > In any case, per process AS is a prerequisite to all this.
>
> Oh, I hadn't realized that was still a todo. In the meantime, what's the
> implication of shipping without it? (I.e. in which threat model are
> users vulnerable without i
On Mon, Jul 29, 2019 at 1:18 AM Steven Price wrote:
>
> On 25/07/2019 18:40, Alyssa Rosenzweig wrote:
> >> Sorry, I was being sloppy again![1] I meant CPU mmapped.
> >
> > No worries, just wanted to check :)
> >
> >> Apparently the blob in some cases creates a SAME_VA GROW_ON_GPF buffer -
> >> sin
On 25/07/2019 18:40, Alyssa Rosenzweig wrote:
Sorry, I was being sloppy again![1] I meant CPU mmapped.
No worries, just wanted to check :)
Apparently the blob in some cases creates a SAME_VA GROW_ON_GPF buffer -
since SAME_VA means permanently mapped on the CPU this translated to
mmapping a H
> It looks like the driver might be allocated a depth or stencil buffer
> without knowing whether it will be used. The buffer is then "grown" if
> it is needed by the GPU. The problem is it is possible for the
> application to access it later.
Hmm. I "think" you should be able to use a dummy (unba
On Fri, Jul 26, 2019 at 3:15 AM Steven Price wrote:
>
> On 25/07/2019 22:11, Rob Herring wrote:
> > On Thu, Jul 25, 2019 at 7:08 AM Robin Murphy wrote:
> >>
> >> Hi Rob,
> >>
> >> On 25/07/2019 02:10, Rob Herring wrote:
> >> [...]
> >>> @@ -328,6 +427,18 @@ static irqreturn_t panfrost_mmu_irq_han
On 25/07/2019 22:11, Rob Herring wrote:
On Thu, Jul 25, 2019 at 7:08 AM Robin Murphy wrote:
Hi Rob,
On 25/07/2019 02:10, Rob Herring wrote:
[...]
@@ -328,6 +427,18 @@ static irqreturn_t panfrost_mmu_irq_handler(int irq, void
*data)
access_type = (fault_status >> 8) & 0x3;
On 25/07/2019 15:59, Steven Price wrote:
[...]
> It would appear that in the following call sgt==NULL:
>> ret = sg_alloc_table_from_pages(sgt, pages + page_offset,
>> NUM_FAULT_PAGES, 0, SZ_2M, GFP_KERNEL);
>
> Which means we've ended up with a BO with bo-
> Sorry, I was being sloppy again![1] I meant CPU mmapped.
No worries, just wanted to check :)
> Apparently the blob in some cases creates a SAME_VA GROW_ON_GPF buffer -
> since SAME_VA means permanently mapped on the CPU this translated to
> mmapping a HEAP object. Why it does this I've no idea
> Either we should prevent mapping of HEAP objects
I'm good with that. AFAIK, HEAP objects shouldn't be (CPU) mmapped
anyway in normal use; if you need them mapped (for debugging etc), it's
no big deal to just.. not set the HEAP flag in debug builds.
Or do you mean GPU mapping?
signature.asc
De
On 25/07/2019 02:10, Rob Herring wrote:
> The midgard/bifrost GPUs need to allocate GPU heap memory which is
> allocated on GPU page faults and not pinned in memory. The vendor driver
> calls this functionality GROW_ON_GPF.
>
> This implementation assumes that BOs allocated with the
> PANFROST_BO_
On 25/07/2019 17:13, Alyssa Rosenzweig wrote:
>> Either we should prevent mapping of HEAP objects
>
> I'm good with that. AFAIK, HEAP objects shouldn't be (CPU) mmapped
> anyway in normal use; if you need them mapped (for debugging etc), it's
> no big deal to just.. not set the HEAP flag in debug
On 25/07/2019 22:28, Rob Herring wrote:
On Thu, Jul 25, 2019 at 9:35 AM Steven Price wrote:
On 25/07/2019 15:59, Steven Price wrote:
[...]
It would appear that in the following call sgt==NULL:
ret = sg_alloc_table_from_pages(sgt, pages + page_offset,
On 26/07/2019 10:15, Steven Price wrote:
On 25/07/2019 22:11, Rob Herring wrote:
On Thu, Jul 25, 2019 at 7:08 AM Robin Murphy
wrote:
Hi Rob,
On 25/07/2019 02:10, Rob Herring wrote:
[...]
@@ -328,6 +427,18 @@ static irqreturn_t panfrost_mmu_irq_handler(int
irq, void *data)
ac
On Thu, Jul 25, 2019 at 9:35 AM Steven Price wrote:
>
> On 25/07/2019 15:59, Steven Price wrote:
> [...]
> > It would appear that in the following call sgt==NULL:
> >> ret = sg_alloc_table_from_pages(sgt, pages + page_offset,
> >> NUM_FAULT_PAGES, 0, SZ_2M
On Thu, Jul 25, 2019 at 7:08 AM Robin Murphy wrote:
>
> Hi Rob,
>
> On 25/07/2019 02:10, Rob Herring wrote:
> [...]
> > @@ -328,6 +427,18 @@ static irqreturn_t panfrost_mmu_irq_handler(int irq,
> > void *data)
> > access_type = (fault_status >> 8) & 0x3;
> > source_id
Hi Rob,
On 25/07/2019 02:10, Rob Herring wrote:
[...]
@@ -328,6 +427,18 @@ static irqreturn_t panfrost_mmu_irq_handler(int irq, void
*data)
access_type = (fault_status >> 8) & 0x3;
source_id = (fault_status >> 16);
+ /* Page fault only */
+
20 matches
Mail list logo