lkml.org 
[lkml]   [2024]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH bpf-next 1/2] bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro()
Date


Le 19/02/2024 à 02:40, Hengqi Chen a écrit :
> [Vous ne recevez pas souvent de courriers de hengqi.chen@gmail.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
>
> Hello Christophe,
>
> On Sun, Feb 18, 2024 at 6:55 PM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>> set_memory_ro() can fail, leaving memory unprotected.
>>
>> Check its return and take it into account as an error.
>>
>
> I don't see a cover letter for this series, could you describe how
> set_memory_ro() could fail.
> (Most callsites of set_memory_ro() didn't check the return values)

Yeah, there is no cover letter because as explained in patch 2 the two
patches are autonomous. The only reason why I sent it as a series is
because the patches both modify include/linux/filter.h in two places
that are too close to each other.

I should have added a link to https://github.com/KSPP/linux/issues/7
See that link for detailed explanation.

If we take powerpc as an exemple, set_memory_ro() is a frontend to
change_memory_attr(). When you look at change_memory_attr() you see it
can return -EINVAL in two cases. Then it calls
apply_to_existing_page_range(). When you go down the road you see you
can get -EINVAL or -ENOMEM from that function or its callees.

Christophe
\
 
 \ /
  Last update: 2024-05-27 15:09    [W:1.269 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site