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: <ecef210b-dc7d-e385-f9b2-927d55a6777e@amd.com>
Date:   Wed, 5 Apr 2023 13:39:25 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.1
Content-Language: en-CA
To:     =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>,
        Danilo Krummrich <dakr@redhat.com>, airlied@gmail.com,
        daniel@ffwll.ch, l.stach@pengutronix.de,
        "Prosyak, Vitaly" <Vitaly.Prosyak@amd.com>
Cc:     dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
References: <20230331000622.4156-1-dakr@redhat.com>
 <6ad72a7f-302f-4be1-0d53-00ff9dc37ef7@amd.com>
From:   Luben Tuikov <luben.tuikov@amd.com>
Subject: Re: [PATCH] drm/scheduler: set entity to NULL in
 drm_sched_entity_pop_job()
In-Reply-To: <6ad72a7f-302f-4be1-0d53-00ff9dc37ef7@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?d2IwWVRLU0xKRTgwRDFqUzBNTjVrVUVVam96QmRhZllLZnJ5NThTZnhsTkow?=
 =?utf-8?B?Y1BvMkZJVjYzUzVMSmM0cnNvZ2JMcGNnNnJWWjlmSEtnUE0rQlV5NTl4czFR?=
 =?utf-8?B?SjFRV21HK0JWOWtwYmF0ak1sWWlzM3NGQjVwbk0vVWZXTXFEWTJCOWlkbW95?=
 =?utf-8?B?MnkyMmNEcy9BMUVJeDBsN3VBYlAwaFhuK2Z3SmlXNnpWaHBzcVJlbHhId1pz?=
 =?utf-8?B?STJ2Nm44V1lBaXN1TTlpRXpnZmtjU2FpU2s2OXVYS21PR1JNQVdIcDYyOTcy?=
 =?utf-8?B?UG9RUC9tNkZoZWxEN3BiOE9ReGNycm1kNlYxaENwUVMyQzN6Tnk5MXF2MjIy?=
 =?utf-8?B?ZjU1VDdrWTU2TEhVKzBiUGFSdmdxSmxGS2ZXUXBxZ0FZdHNWRkU1bUxvTXZU?=
 =?utf-8?B?VENDQkpRY0twMHB1NWV2ODcvRWFkS2hjcGpSKy8rNTk2dmt2NzRHUW5UcUdK?=
 =?utf-8?B?S0VyWmVOZEpmTnZtaTdmbDNib2VIOTc3WVF4ZUdzQkRDMkIzVm9aM2UzOHpE?=
 =?utf-8?B?SHFObzcxZjFmN3pPbHlxOG1WR0IzM0lieHNWdHFFY3B4eVB4WUxzTit1dkdZ?=
 =?utf-8?B?ckpoOERtOUFMeGNpYWhjcmxlS2U1eXdoeXVrQThEeVk0cEdLL2ZwUVFmREpj?=
 =?utf-8?B?MkRIQnFIb0xaRDNCK2dpejdWNHJNamdKVGYxV1lVRG9VU1h0RXBkZ0lScEcz?=
 =?utf-8?B?Wlk4TDNKc2JpcEI4WXNrMWt1b3NhbG1Bc0RDR1JsM010YVFVakhtdExuTm9x?=
 =?utf-8?B?anhYb0QxMXJ5Ykh6NThTQmhYQWxWTk41UGQxbGVFYUNTV0NPUUlkRHhMK3Vy?=
 =?utf-8?B?cnlCTWpGVWNpWlpzbmRraEx2UTNTbktZZHZ1Y2tnRlMwUmZMZjRtNFY0TU5T?=
 =?utf-8?B?L3REUnJlcVgxd0IwRDlJMmZaY1hsbEJrV0RsMjVES0M4TVJua1dtY2MvY2hF?=
 =?utf-8?B?V3hZYktoaGZmZ1VRcmFiYjVxaktoVy9teUR1djVvNW1rQWw4MWVZWkd0allC?=
 =?utf-8?B?OTU1UjFHWlZFRnZvaWVVQ2tWUWVKYWhjYk5DWjcyV3hwcFhoU2hNQmp0ODVw?=
 =?utf-8?B?cFBzL2hMeTR1amdPbkJWR0FkY1pOcmNOdTRlam9mWlFkKytFQXBOeUE1Rk9w?=
 =?utf-8?B?TzFGK2lrWU5vRTVjWlNMYWpjeDVQeGtUcWlPTUFuM2U4dWpSak5lWmlvcjI0?=
 =?utf-8?B?ekV3U0xpbTNrVkpnU0pTVzhBbkJpSTZmNDNQNzZTV1paN0tSZXlKRWtRSW1H?=
 =?utf-8?B?eEFZMElBNG12NXhPYWZnZmxXVXdsbU1kWUFidjVpd0JBR0tFVG52ZkdzeG1K?=
 =?utf-8?B?Z1FZM3ZUZlowMzNZS0l1ZksrZUgrSTV2eG1xdkdtTHZGaGdXN052QzI1bDlS?=
 =?utf-8?B?dTBhNFRWVGtJTlVLMFF3NUl3blAxelZUR1R0ekl0SE1zK1VuNmIza280M2lL?=
 =?utf-8?B?QnIxTlAydkgwcVRHYkJjMXE2T0J5SHdsQ1NtWERvZEJnL01QN2M3bnNzcnRD?=
 =?utf-8?B?L01SbW1TWWtzOEU3MkNqalNHSDcvbFA4YVExdFN2TmJEWUtJUy8wZUpCaDZ6?=
 =?utf-8?B?ek9EaEhER21IUEowdWdsU1lSaHk2SzRwNTgyWTZpSE13V3lBMkRxOTJ3WlFZ?=
 =?utf-8?B?L2JOWjI2OFphSjc3TWhKS2Z5YWFieFlpVnFNbUVEUHVCOHQvZkhqV2czL0VM?=
 =?utf-8?B?U2dMMVp6OFFYOEpPazBqTWhyL3BtWHpERFIrOGVuaWV3Qm9XRnVkMVVLbkZP?=
 =?utf-8?B?YkpWSGlIa1BnV21tcFcyR0dkWnRhZGVUSlpFZk85c1lVb0tMOXJnWTVsbUhJ?=
 =?utf-8?B?SS9WN2x0RzVza0RVSWYvUlpQV2FrVUJINlJmVktLUmE5YThEQlh0VW8walJN?=
 =?utf-8?B?eXZ2NFgvK25nU2pROEY2QSt4TFJGNkxYaDRLRDdmcVR3U0IyTHcvR0lYb2xk?=
 =?utf-8?B?bmNocHFja3ppKzdwcFZ6eFpPQUhwVVJRTXB3ejg4VGtBQUNVcndqRlp4ZWNm?=
 =?utf-8?B?SjdIRitpZEhPM2JqblZtb1FVNHJmNHlnSkVpaEJNZEtOSVU3MGNuSXdJZUhK?=
 =?utf-8?B?anB3S1QrbkkzOStTRGx1Zm8wRStzQWZQZFNQTThYSnUydkFhV2RvamFNY0Vt?=
 =?utf-8?Q?aqXavQpdYA1gMULVkqYtgZXNa?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a9ec803a-fe88-4fc3-bfa7-08db35fcb51e
X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB3370.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2023 17:39:29.1460
 (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: jPbgaiN2BjkQUvu685Vl3vc1Hn+zPPBtvYqLuqQSghyY6Gbt8CON4s/JDwmSjTDu
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB6683
X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
        DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,NICE_REPLY_A,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE
        autolearn=unavailable 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-03-31 01:59, Christian König wrote:
> Am 31.03.23 um 02:06 schrieb Danilo Krummrich:
>> It already happend a few times that patches slipped through which
>> implemented access to an entity through a job that was already removed
>> from the entities queue. Since jobs and entities might have different
>> lifecycles, this can potentially cause UAF bugs.
>>
>> In order to make it obvious that a jobs entity pointer shouldn't be
>> accessed after drm_sched_entity_pop_job() was called successfully, set
>> the jobs entity pointer to NULL once the job is removed from the entity
>> queue.
>>
>> Moreover, debugging a potential NULL pointer dereference is way easier
>> than potentially corrupted memory through a UAF.
>>
>> Signed-off-by: Danilo Krummrich <dakr@redhat.com>
> 
> In general "YES PLEASE!", but I fear that this will break amdgpus reset 
> sequence.
> 
> On the other hand when amdgpu still relies on that pointer it's clearly 
> a bug (which I pointed out tons of times before).
> 
> Luben any opinion on that? Could you drive cleaning that up as well?

I didn't find any references to scheduling entity after the job
is submitted to the hardware. (I commented the same in the other
thread, we just need to decide which way to go.)

Regards,
Luben

> 
> Thanks,
> Christian.
> 
>> ---
>> I'm aware that drivers could already use job->entity in arbitrary places, since
>> they in control of when the entity is actually freed. A quick grep didn't give
>> me any results where this would actually be the case, however maybe I also just
>> didn't catch it.
>>
>> If, therefore, we don't want to set job->entity to NULL I think we should at
>> least add a comment somewhere.
>> ---
>>
>>   drivers/gpu/drm/scheduler/sched_entity.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c
>> index 15d04a0ec623..a9c6118e534b 100644
>> --- a/drivers/gpu/drm/scheduler/sched_entity.c
>> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
>> @@ -448,6 +448,12 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct drm_sched_entity *entity)
>>   			drm_sched_rq_update_fifo(entity, next->submit_ts);
>>   	}
>>   
>> +	/* Jobs and entities might have different lifecycles. Since we're
>> +	 * removing the job from the entities queue, set the jobs entity pointer
>> +	 * to NULL to prevent any future access of the entity through this job.
>> +	 */
>> +	sched_job->entity = NULL;
>> +
>>   	return sched_job;
>>   }
>>   
>