Thanks Jose,
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
Perhaps I'm getting confused with the terminology, but I don't think moving
compilation 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.)
As mentioned, there are
On Thu, 27 Apr 2023 at 15:18, Josh Gargus wrote:
>
> Thanks for your advice! I hadn't looked at Venus, but that seems like a very
> promising place to start.
>
> The other approach feels more approachable now too; it feels like there are
> less "unknown unknowns", although there are plenty of
Thanks for your advice! I hadn't looked at Venus, but that seems like a
very promising place to start.
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
On Thu, 27 Apr 2023 at 05:27, Josh Gargus wrote:
>
> Hi, I'm from the Fuchsia team at Google. We would like to provide Lavapipe
> as an ICD within Fuchsia. However, our default security policy is to deny
> client apps the capability to map memory as writable/executable; we don't
> want to
Hi, I'm from the Fuchsia team at Google. We would like to provide Lavapipe
as an ICD within Fuchsia. However, our default security policy is to deny
client apps the capability to map memory as writable/executable; we don't
want to relax this for every client app which uses Vulkan. Therefore, we
