Thread (61 messages) 61 messages, 10 authors, 2024-02-28

Re: [PATCH v1 0/8] x86_64 SandBox Mode arch hooks

From: Petr Tesařík <hidden>
Date: 2024-02-14 19:33:35
Also in: lkml

On Wed, 14 Feb 2024 10:42:57 -0800
Dave Hansen [off-list ref] wrote:
On 2/14/24 10:22, Petr Tesařík wrote:
quoted
Anyway, in the long term I would like to work on gradual decomposition
of the kernel into a core part and many self-contained components.
Sandbox mode is a useful tool to enforce isolation.  
I'd want to see at least a few examples of how this decomposition would
work and how much of a burden it is on each site that deployed it.
Got it. Are you okay with a couple of examples to illustrate the
concept? Because if you want patches that have been acked by the
respective maintainers, it somehow becomes a chicken-and-egg kind of
problem...
But I'm skeptical that this could ever work.  Ring-0 execution really is
special and it's _increasingly_ so.  Think of LASS or SMAP or SMEP.
I have just answered a similar concern by hpa. In short, I don't think
these features are relevant, because by definition sandbox mode does
not share anything with user mode address space.
We're even seeing hardware designers add hardware security defenses to
ring-0 that are not applied to ring-3.

In other words, ring-3 isn't just a deprivileged ring-0, it's more
exposed to attacks.
quoted
I'd rather fail fast than maintain hundreds of patches in an
out-of-tree branch before submitting (and failing anyway).  
I don't see any remotely feasible path forward for this approach.
I can live with such decision. But first, I want to make sure that the
concept has been understood correctly. So far, at least some concerns
suggest an understanding that is not quite accurate.

Is this sandbox idea a bit too much out-of-the-box?

Petr T
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help