On February 14, 2024 10:59:32 PM PST, "Petr Tesařík" <petr@xxxxxxxxxxx> wrote: >On Wed, 14 Feb 2024 10:52:47 -0800 >Xin Li <xin@xxxxxxxxx> wrote: > >> On 2/14/2024 10:22 AM, Petr Tesařík wrote: >> > On Wed, 14 Feb 2024 06:52:53 -0800 >> > Dave Hansen <dave.hansen@xxxxxxxxx> wrote: >> > >> >> On 2/14/24 03:35, Petr Tesarik wrote: >> >>> This patch series implements x86_64 arch hooks for the generic SandBox >> >>> Mode infrastructure. >> >> >> >> I think I'm missing a bit of context here. What does one _do_ with >> >> SandBox Mode? Why is it useful? >> > >> > I see, I split the patch series into the base infrastructure and the >> > x86_64 implementation, but I forgot to merge the two recipient lists. >> > :-( >> > >> > 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. >> > >> > In its current form, sandbox mode is too limited for that, but I'm >> > trying to find some balance between "publish early" and reaching a >> > feature level where some concrete examples can be shown. I'd rather >> > fail fast than maintain hundreds of patches in an out-of-tree branch >> > before submitting (and failing anyway). >> > >> > Petr T >> > >> >> What you're proposing sounds a gigantic thing, which could potentially >> impact all subsystems. > >True. Luckily, sandbox mode allows me to move gradually, one component >at a time. > >> Unless you prove it has big advantages with real >> world usages, I guess nobody even wants to look into the patches. >> >> BTW, this seems another attempt to get the idea of micro-kernel into >> Linux. > >We know it's not feasible to convert Linux to a micro-kernel. AFAICS >that would require some kind of big switch, affecting all subsystems at >once. > >But with a growing code base and more or less constant bug-per-LOC rate, >people will continue to come up with some ideas how to limit the >potential impact of each bug. Logically, one of the concepts that come >to mind is decomposition. > >If my attempt helps to clarify how such decomposition should be done to >be acceptable, it is worthwile. If nothing else, I can summarize the >situation and ask Jonathan if he would kindly accept it as a LWN >article... > >Petr T > I have been thinking more about this, and I'm more than ever convinced that exposing kernel memory to *any* kind of user space is a really, really bad idea. It is not a door we ever want to open; once that line gets muddled, the attack surface opens up dramatically. And, in fact, we already have a sandbox mode in the kernel – it is called eBPF.
