Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <9c0cff84-45b1-268f-bdad-38c16316dbc3@amd.com>
Date:   Sat, 15 Jul 2023 00:03:16 -0400
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/3] drm/scheduler: Fix UAF in
 drm_sched_fence_get_timeline_name
Content-Language: en-CA, en-US
To:     =?UTF-8?Q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>,
        Asahi Lina <lina@asahilina.net>,
        David Airlie <airlied@gmail.com>,
        Daniel Vetter <daniel@ffwll.ch>,
        Sumit Semwal <sumit.semwal@linaro.org>
Cc:     Faith Ekstrand <faith.ekstrand@collabora.com>,
        Alyssa Rosenzweig <alyssa@rosenzweig.io>,
        dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        linux-media@vger.kernel.org, asahi@lists.linux.dev
References: <20230714-drm-sched-fixes-v1-0-c567249709f7@asahilina.net>
 <20230714-drm-sched-fixes-v1-2-c567249709f7@asahilina.net>
 <bef7ef62-3cd9-6ceb-5eb4-5ae0c0236778@amd.com>
 <de502b41-2864-db1e-16a0-8a5d5e0e4ad3@asahilina.net>
 <d9dc2fd5-d054-dbf3-72b7-fe9deaa46350@amd.com>
From:   Luben Tuikov <luben.tuikov@amd.com>
Autocrypt: addr=luben.tuikov@amd.com; keydata=
 xjMEY1i6jxYJKwYBBAHaRw8BAQdAhfD+Cc+P5t/fiF08Vw25EMLiwUuxULYRiDQAP6H50MTN
 I0x1YmVuIFR1aWtvdiA8bHViZW4udHVpa292QGFtZC5jb20+wpkEExYKAEEWIQQyyR05VSHw
 x45E/SoppxulNG8HhgUCY1i6jwIbAwUJCWYBgAULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIX
 gAAKCRAppxulNG8Hhk53AP4k4UY5xfcje0c5OF1k22pNv8tErxtVpgKKZgvfetA4xwD+OoAh
 vesLIYumBDxP0BoLiLN84udxdT15HwPFUGiDmwDOOARjWLqPEgorBgEEAZdVAQUBAQdAzSxY
 a2EtvvIwd09NckBLSTarSLNDkUthmqPnwolwiDYDAQgHwn4EGBYKACYWIQQyyR05VSHwx45E
 /SoppxulNG8HhgUCY1i6jwIbDAUJCWYBgAAKCRAppxulNG8HhnBLAP4yjSGpK6PE1mapKhrq
 8bSl9reo+F6EqdhE8X2TTHPycAEAt8EkTEstSiaOpM66gneU7r+xxzOYULo1b1XjXayGvwM=
In-Reply-To: <d9dc2fd5-d054-dbf3-72b7-fe9deaa46350@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SVNrZWc3S0dEWHZsL0xHRWZqYWpQc3Vxb0tPSmFyOG5VQ044NVhlOUlGTDU1?=
 =?utf-8?B?bloydHV6Y0JXYXQ5R0pBWjNmUGt3aHhXeCtoSkhmRkVPd0FudnR3cWNvdS8z?=
 =?utf-8?B?a3dxaUluRlJ1SkN6cm8rdkl6cHUwTGZHSVRXbEowWFYyTTl6UlVsMnBnK2hz?=
 =?utf-8?B?NWwyQytGOVUzVVQvcmlzTEpmRE1HWFkxSGE3QnIyeVN5TUQ3RHE1UE5uMUZh?=
 =?utf-8?B?Mmk3ZktLM21BOWpRcEFtUGZ4N0hTM3EzZVFwcldkcldPM0VrVnZWZ2paQlFG?=
 =?utf-8?B?RlIza1BsWDBiTSsrdnpqRUdEVHlzdE5EeUpienByOHlKdjh1elNubWExcDI1?=
 =?utf-8?B?Y1c0cC9MQUNvdUNiODRRakpYUkRNSTNNTC9ocXA4RkdyYWxacjZ1ZlNKYnpo?=
 =?utf-8?B?a1VmQ0Jka2Z5SGlidWcyMVZ2MVZlWkwvUG8wVFRVMmlWQmI5cG9ZZDlZbWNi?=
 =?utf-8?B?b2pVekJQaEFOWWFSYlBnNE90Y25DR05SaGJCTUg1S05ya2lqd0JsbGhTbisz?=
 =?utf-8?B?ekVuQ3IrbDY1WGJUVWhRd1kwK3VEMnpzdWJCNkRGNFdQYXJRZDNHaVltU1Vo?=
 =?utf-8?B?aU9aTmd5QXFQdTJLSWNqdUtWaVpBS3ZUQmRpNnhVUVdaSUVoRGk1cXUvR3hI?=
 =?utf-8?B?NzVBREZjRVBwNDNoZTFjMFpqUDluZVVScEFVSk9GUWJoa3M3QXNQNFhQNEx4?=
 =?utf-8?B?VU9iaTdkTFNUakhpRDBURzYwYmQreWV2cUlWSlhkK2RnT2daYk5KeGRrT3Rq?=
 =?utf-8?B?YUxsU2UxdFpxZllyajJJTFE2Q2FLMkFWUmlFOWlWb0M1V3huMEVpZVBJSG84?=
 =?utf-8?B?d0M2V0ZOaEYxRU1rMGhXZDlrcTVjM0Y4SVpxTjlHdUxFVjNVa0tLaytXY2Nr?=
 =?utf-8?B?L1BKcDBZNnVZeHdqcXpiajNQTHRxK3RXdFVsOWlNUXpYWVBxSjJyU1kyNGhn?=
 =?utf-8?B?S2t2MG9FWUI4OTh6YWQvM2k0cGpWNmtjQUpJVndHYUptVlNNbjVGL2JrejIy?=
 =?utf-8?B?a3FsVWJiR1ZjcXZCbHA2OHJJQlpyam5OcGFJSmdNVUlrRXoyczVWOXZ0OFk2?=
 =?utf-8?B?ZXZjOHdkdmtrbmJLU2tCb1pubTVzS29vNE50cFZkWThwTDNYRE16QTFCaVF6?=
 =?utf-8?B?dzNSVGVFR2RiMHdRWCs0UWY3RWJLSmQ4VUhQVHQ0V1MxcEF0NkxKMnFub096?=
 =?utf-8?B?NUtReDNuWXN3bEU0VEc0Q1Z4QndoNVY3Ujc3N2JyYnoyRzYrbFQ1YXRrWnZi?=
 =?utf-8?B?ZFNwT3RreWYreGNndlJudCswV0x1NkZ6TkRXNmVkaUlNRmo2cmUxczlPYjIr?=
 =?utf-8?B?SUhqTEk5eUFiK0w4YlBZamRaYTN0Umtuc3ZMWHY1RFplQnhlOHBNWjNEUXhL?=
 =?utf-8?B?Kyt0aFlnT2doc3ljcUVYN2o3RG5uN2JrVjdMUGVYWGI4VTZPaDMrT2RZVzM3?=
 =?utf-8?B?ckk5dkxnZ3BwdUpFN2NNL01wcFhWd0o2aS83Q0NDSWl2Szl5K01IVEFKenk2?=
 =?utf-8?B?NEJFdzgzdmkvTFR1bmlsZm5zNG9jMzF5dm1UeTJJbG03OWdEQkRGaDZGRWdx?=
 =?utf-8?B?cXN6VjZDVzNtVEhwQnFwSHFNR1VDVUVCRlFaNWxxQzh5dTJnaGhxeU9LUE5J?=
 =?utf-8?B?VWIxa1YvWXRLZ0lYSGI4Ty94TzlyRlBXWWs0MUN0dXZqQm1OYW9mTVZLb2Zm?=
 =?utf-8?B?ZTA0NkI2QjZxa0k3WCtFNnlqM1ZIc2pSMzYvTEQxZXJYR2dJbHpaa2xJOVcy?=
 =?utf-8?B?U3J0YXgzMlVKRmxzeG1hTmVoQXVBWk5VUmx6eDZZNFkzbkNrcDFza3R6NlZJ?=
 =?utf-8?B?ZW1qY1FmQ0lYclB3alBqdktiRjVmTm9PTWdSc3FjZEwzVWJLYXlkeXRxTFFW?=
 =?utf-8?B?TnNMQ2VrYXZhT0p0dUhCNjFQdlhhM3NrRTBtVHFaNEZUZG50eUxKTWdxYm5v?=
 =?utf-8?B?VEJXVEpoZGpnWDQ3TEJqZ3JyVXlFSlM4NjJmSHRscEpyN1JhNkViM3ZKUmx4?=
 =?utf-8?B?VU9RWUh2Rkh5S3dSTlRjWVNuVWhlOHVyck1QcWtKWlNqM3RDUm9kc0ppOUE0?=
 =?utf-8?B?YXRVWml4RDJVTFVaQjRxRHpXS1RmeXVzTU4xN3Y5MFJ3L3Iyd2FTQWM1ZjdR?=
 =?utf-8?Q?EyqQMrVPD1ydCRIV1HJ1XaJsU?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 67a219d2-d614-42bf-2c16-08db84e86cc2
X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB3370.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2023 04:03:19.8081
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: WIBhXfbNQcQgtb2XCVDVnOLV395so9gbowBI5dP6s1zo0Blg61gOA//oMqoOwhXE
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB8152
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=no autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2023-07-14 05:57, Christian König wrote:
> Am 14.07.23 um 11:49 schrieb Asahi Lina:
>> On 14/07/2023 17.43, Christian König wrote:
>>> Am 14.07.23 um 10:21 schrieb Asahi Lina:
>>>> A signaled scheduler fence can outlive its scheduler, since fences are
>>>> independencly reference counted. Therefore, we can't reference the
>>>> scheduler in the get_timeline_name() implementation.
>>>>
>>>> Fixes oopses on `cat /sys/kernel/debug/dma_buf/bufinfo` when shared
>>>> dma-bufs reference fences from GPU schedulers that no longer exist.
>>>>
>>>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>>>> ---
>>>>    drivers/gpu/drm/scheduler/sched_entity.c | 7 ++++++-
>>>>    drivers/gpu/drm/scheduler/sched_fence.c  | 4 +++-
>>>>    include/drm/gpu_scheduler.h              | 5 +++++
>>>>    3 files changed, 14 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c 
>>>> b/drivers/gpu/drm/scheduler/sched_entity.c
>>>> index b2bbc8a68b30..17f35b0b005a 100644
>>>> --- a/drivers/gpu/drm/scheduler/sched_entity.c
>>>> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
>>>> @@ -389,7 +389,12 @@ static bool 
>>>> drm_sched_entity_add_dependency_cb(struct drm_sched_entity *entity)
>>>>               /*
>>>>             * Fence is from the same scheduler, only need to wait for
>>>> -         * it to be scheduled
>>>> +         * it to be scheduled.
>>>> +         *
>>>> +         * Note: s_fence->sched could have been freed and reallocated
>>>> +         * as another scheduler. This false positive case is okay, 
>>>> as if
>>>> +         * the old scheduler was freed all of its jobs must have
>>>> +         * signaled their completion fences.
>>>
>>> This is outright nonsense. As long as an entity for a scheduler exists
>>> it is not allowed to free up this scheduler.
>>>
>>> So this function can't be called like this.
>>
>> As I already explained, the fences can outlive their scheduler. That 
>> means *this* entity certainly exists for *this* scheduler, but the 
>> *dependency* fence might have come from a past scheduler that was 
>> already destroyed along with all of its entities, and its address reused.
> 
> Well this is function is not about fences, this function is a callback 
> for the entity.
> 
>>
>> Christian, I'm really getting tired of your tone. I don't appreciate 
>> being told my comments are "outright nonsense" when you don't even 
>> take the time to understand what the issue is and what I'm trying to 
>> do/document. If you aren't interested in working with me, I'm just 
>> going to give up on drm_sched, wait until Rust gets workqueue support, 
>> and reimplement it in Rust. You can keep your broken fence lifetime 
>> semantics and I'll do my own thing.
> 
> I'm certainly trying to help here, but you seem to have unrealistic 
> expectations.
> 
> I perfectly understand what you are trying to do, but you don't seem to 
> understand that this functionality here isn't made for your use case.
> 
> We can adjust the functionality to better match your requirements, but 
> you can't say it is broken because it doesn't work when you use it not 
> in the way it is intended to be used.

I believe "adjusting" functionality to fit some external requirements,
may have unintended consequences, requiring yet more and more "adjustments".
(Or may allow (new) drivers to do wild things which may lead to wild results. :-) )

We need to be extra careful and wary of this.
-- 
Regards,
Luben