<div dir="ltr"><div>Thanks Jose,<br><br>You're right, compilation is just data transformation, the security issues arise when the process executes the generated code.  I'm realizing that I don't *deeply* grok the mindset of our security folk; I'll have a talk with them.  For example, the client process has the ability to load shared libraries (otherwise it couldn't load libvulkan.so, nor the ICD obtained from the loader).  So if a client exploit:</div><div>  1) generated some malicious code</div><div>  2) wrote that code to a file</div><div>  3) loaded that file as a .so</div><div>  4) ran the malicious code</div><div>... then I don't see how the outcome is different compared to if 2) and 3) were replaced by generating the same malicious code into writable/executable memory.  I have some ideas about how Fuchsia's capability model might address this, but they're pure speculation that isn't worth writing down.  I'll report back here, in case this is of interest to anyone.</div><div><br></div><div>In your sketched non-Venus solution, I don't understand the first step ("back all buffer/texture memory with shared memory, visible to the 2nd process").  I don't think you're proposing that rendering would occur in the second process, only shader compilation (otherwise there wouldn't be a need to "to tell LLVM either spit out .so files, or to use shared memory").  So then why does the compilation process need access to the buffer/texture memory?</div><div><br></div><div>Thanks,</div><div>Josh</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 27, 2023 at 6:23 AM Jose Fonseca <<a href="mailto:jfonseca@vmware.com">jfonseca@vmware.com</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"><div class="msg393959208381702059">




<div dir="ltr">
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Perhaps I'm getting confused with the terminology, but I don't think moving <i>compilation</i> to a separate process helps here.  IIUC, compilation (as in LLVM IR -> x86 code) can happen anywhere, the problem is loading the JITed code (ie, make writeable memory
 executable.)</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
As mentioned, there are many places this can be done.</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
If Venus does not suite your needs, the easiest way to achieve this would be to:</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
- back all buffer/texture memory with shared memory, visible to the 2<span>^nd process</span></div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span>- modify gallivm to tell LLVM either spit out .so files, or to use shared memory</span></div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span>- modify gallivm_jit_function to return a wrapper that marshals the call into the 2<span>^nd process</span>:</span></div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span>  - either a generic C wrapper which can introspect the LLVM IR Function arguments</span></div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span>  - or hand written C wrappers for every function prototype returned by <span style="background-color:rgb(255,255,255);display:inline">gallivm_jit_function</span></span></div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
- there are also a few places where JIT code refers to host process memory addresses explicitly (e.g, util_format_xxx helper functions) which need to be handled separately (e.g, by passing these addresses in a structure which can be rewritten to match the 2<span>^nd process</span>)</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Jose</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_393959208381702059divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt;color:rgb(0,0,0)"><b>From:</b> mesa-dev <<a href="mailto:mesa-dev-bounces@lists.freedesktop.org" target="_blank">mesa-dev-bounces@lists.freedesktop.org</a>> on behalf of Dave Airlie <<a href="mailto:airlied@gmail.com" target="_blank">airlied@gmail.com</a>><br>
<b>Sent:</b> Thursday, April 27, 2023 08:39<br>
<b>To:</b> Josh Gargus <<a href="mailto:jjosh@google.com" target="_blank">jjosh@google.com</a>><br>
<b>Cc:</b> <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a>><br>
<b>Subject:</b> Re: Advice on modifying Lavapipe to isolate JIT compilation in separate process</font>
<div> </div>
</div>
<div><font size="2"><span style="font-size:11pt">
<div>!! External Email<br>
<br>
On Thu, 27 Apr 2023 at 15:18, Josh Gargus <<a href="mailto:jjosh@google.com" target="_blank">jjosh@google.com</a>> wrote:<br>
><br>
> Thanks for your advice!  I hadn't looked at Venus, but that seems like a very promising place to start.<br>
><br>
> The other approach feels more approachable now too; it feels like there are less "unknown unknowns", although there are plenty of known unknowns to investigate (address independence was one that was already bugging be before I wrote to this list).<br>
<br>
I think it shouldn't be too horrible to work out, another option might<br>
be to abuse the cache somehow, but I think that still needs writable +<br>
executable which probably doesn't help, but stuff should be address<br>
independent as I do write x86 asm programs to the cache and read them<br>
back out, only relocating around the global symbols.<br>
<br>
><br>
> It seems like Venus is the more straightforward approach, so I'm inclined to just go with it.  However, it seems like there would be a performance hit compared to only doing JIT compilation in a separate process.  Do you have a rough sense of the performance
 hit of serializing everything over Venus?  The answer will depend on the workload, I know.<br>
<br>
Yeah I think you'll definitely see a large perf hit than just moving<br>
compilation out to a separate process, I'm not sure of the raw venus<br>
overhead numbers here, someone else might have more information<br>
available.<br>
<br>
Dave.<br>
<br>
!! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.<br>
</div>
</span></font></div>
</div>

</div></blockquote></div></div>