<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 2, 2020 at 8:15 PM Martin Doucha <<a href="mailto:mdoucha@suse.cz">mdoucha@suse.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 02. 07. 20 11:48, Li Wang wrote:<br>
> <br>
> Martin Doucha <<a href="mailto:mdoucha@suse.cz" target="_blank">mdoucha@suse.cz</a> <mailto:<a href="mailto:mdoucha@suse.cz" target="_blank">mdoucha@suse.cz</a>>> wrote:<br>
> <br>
>     ...<br>
>     +static void *alloc_zero_page(void *baseaddr)<br>
>     +{<br>
>     +       int i;<br>
>     +       void *ret;<br>
>     +<br>
>     +       /* Find aligned chunk of address space. MAP_HUGETLB doesn't<br>
>     work. */<br>
>     +       for (i = 0; i < 16; i++, baseaddr += thp_size) {<br>
>     +               ret = mmap(baseaddr, thp_size, PROT_READ,<br>
>     +                       MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);<br>
> <br>
> <br>
> I'm wondering why here request the READ ONLY memory, shouldn't we write<br>
> something into the write_thp loopingly then?<br>
<br>
We do write into it. Except we do it through /proc/self/mem file<br>
descriptor. I didn't try with PROT_WRITE but presume that mapping the<br>
memory as read-only is important for confusing the kernel into thinking<br>
that the address space doesn't need to be copied on write.<br>
<br>
Nevertheless, I've tested the reproducer on a vulnerable kernel and it<br>
works reliably.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Thanks for the explanation, I helped merge the patchset v3.</div></div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>