Maestro: A Linux-compatible kernel in Rust • Hacker News Board

Re: Maestro: A Linux-compatible kernel in Rust

#361

Post by drtgh » Fri, Jan 05, 2024, 12:29 PM UTC

samus wrote: post #359

drtgh wrote: post #352

Earlier quoted context omitted.

Containers are portability tools, that can partially control a benign application, but in no way will contain a Trojan. The community warns such tools give a false sense of security. As long as the Trojan is moderately advanced, there is nothing to stop it (currently, mouse and cat). The only thing one can do is to detect signs of its activities, just routine. When the least unexpected day one detect the signs, one n…

That was exactly what I was referring to. One would have to at least use a VM to mitigate that danger, or completely airgap the system. Logging suspicious accesses for forensic purposes is surely useful, but expecting the user to review all these notifications won't improve security, unless this is intended to become their job.

I ask kernel support for this kind of monitoring, and you have twice recommended tools that you know will not accomplish the task, even assuring it is not possible to bypass them, just in case in a big hypothetical ten or twenty years (Linux) an unformal petition in a forum were implemented, and just in case much later you were asked to use it in your job, knowing it is unlikely and that it is an operative system where all the services can be customized and disabled. I surrender.

Re: Maestro: A Linux-compatible kernel in Rust

#362

Post by sylware » Fri, Jan 05, 2024, 12:31 PM UTC

BatmanAoD wrote: post #357

sylware wrote: post #328

Earlier quoted context omitted.

This would not happen overnight! It would a slow process. Of course you will need still RISC-V support in current compilers for legacy software. RISC-V is a modern "good enough" with "good balance" ISA, everything is about trade-off, hence "perfection" does not make any sense. What is really different with RISC-V: it is already there, moving forward, is worldwide PI lockfree (unlike x86_64 and arm). Ofc, without extr…

Nobody said anything about RISC-V being "perfect" or not. The problem isn't how good RISC-V is or isn't; it's that your desire for software to target one and only one type of hardware just doesn't make any sense. That's not how computers have ever worked. By the way, what do you mean by "PI lockfree"? Googling "ISA PI lockfree" just leads me to...another hacker news thread where you're arguing that RISC-V should repl…

If you keep explicitely ignoring the core reason why RISC-V is redefining the way to "move forward", I don't know what you want me to tell you.

Re: Maestro: A Linux-compatible kernel in Rust

#363

Post by samus » Fri, Jan 05, 2024, 6:12 PM UTC

drtgh wrote: post #361

samus wrote: post #359

Earlier quoted context omitted.

That was exactly what I was referring to. One would have to at least use a VM to mitigate that danger, or completely airgap the system. Logging suspicious accesses for forensic purposes is surely useful, but expecting the user to review all these notifications won't improve security, unless this is intended to become their job.

I ask kernel support for this kind of monitoring, and you have twice recommended tools that you know will not accomplish the task, even assuring it is not possible to bypass them, just in case in a big hypothetical ten or twenty years (Linux) an unformal petition in a forum were implemented, and just in case much later you were asked to use it in your job, knowing it is unlikely and that it is an operative system whe…

I never suggested that it's not possible to bypass them by exploits.

In an environment where security matters to such a degree, employees don't have for rights and are not given a choice whether to use such monitoring tools. The (non-)existence of such mechanisms is an important criterion in software selection in such environments. But these places actually have the resources to do this and to actually make use of the forensic data.

The basic infrastructure exists. Whether it is sufficient is another question. But it is surely an important use case for a lot of companies. For example, Google added a knob to turn off io_uring because the existing security infrastructure around it was found lacking.

Commercialization of such a solution would be difficult due to the GPL though. One would have to get it as part of appliances (like IBM or Teradata do). Places like Google and Meta could have their own. As you say, we are reliant on someone eventually upstreaming theirs.

Re: Maestro: A Linux-compatible kernel in Rust

#364

Post by Karellen » Fri, Jan 05, 2024, 8:44 PM UTC

tredre3 wrote: post #353

SpaghettiCthulu wrote: post #254

Earlier quoted context omitted.

That's only in terms of the driver interface, right? My understanding is that the userspace interface is extremely stable.

> My understanding is that the userspace interface is extremely stable. Assuming you compile a static binary that doesn't even rely on libc, then yes, something compiled 20 years ago will still run. But in the real world you have to recompile your software constantly due to breakage in dependencies (including glibc). And a binary won't work cross-distros without adding efforts despite running the same kernel (sure, t…

I thought that unless you're relying on buggy behaviour, or other implementation-specific details which are explicitly and prominently documented as unsupported and/or subject to change[0], any binary compiled for Linux libc6/glibc2 (released in Jan '97, available in e.g. Debian "Hamm" in July '98) should still run with the most recent glibc today.[1] Is that not right?

[0] e.g. if your app has a use-after-free bug which happened to work 20 years ago, it may not work any more. Although SimCity famously had a bug like this on Windows, and Microsoft put in a SimCity-specific "shim" to ensure it would continue working when they changed Windows' allocator, if your app is not as popular as SimCity was then it probably won't be as lucky, even on actual Windows.

[1] for the same architecture, obviously. Your i386 app won't run with an s390x or amd64 glibc.

Re: Maestro: A Linux-compatible kernel in Rust

#365

Post by samus » Fri, Jan 05, 2024, 9:46 PM UTC

samus wrote: post #363

drtgh wrote: post #361

Earlier quoted context omitted.

I ask kernel support for this kind of monitoring, and you have twice recommended tools that you know will not accomplish the task, even assuring it is not possible to bypass them, just in case in a big hypothetical ten or twenty years (Linux) an unformal petition in a forum were implemented, and just in case much later you were asked to use it in your job, knowing it is unlikely and that it is an operative system whe…

I never suggested that it's not possible to bypass them by exploits. In an environment where security matters to such a degree, employees don't have for rights and are not given a choice whether to use such monitoring tools. The (non-)existence of such mechanisms is an important criterion in software selection in such environments. But these places actually have the resources to do this and to actually make use of th…

> don't have for rights

should be

> don't have root rights

Re: Maestro: A Linux-compatible kernel in Rust

#366

Post by BatmanAoD » Sat, Jan 06, 2024, 1:41 AM UTC

sylware wrote: post #362

BatmanAoD wrote: post #357

Earlier quoted context omitted.

Nobody said anything about RISC-V being "perfect" or not. The problem isn't how good RISC-V is or isn't; it's that your desire for software to target one and only one type of hardware just doesn't make any sense. That's not how computers have ever worked. By the way, what do you mean by "PI lockfree"? Googling "ISA PI lockfree" just leads me to...another hacker news thread where you're arguing that RISC-V should repl…

If you keep explicitely ignoring the core reason why RISC-V is redefining the way to "move forward", I don't know what you want me to tell you.

...okay, so what is "PI lockfree"?

Re: Maestro: A Linux-compatible kernel in Rust

#367

Post by PrimeMcFly » Sat, Jan 06, 2024, 2:31 AM UTC

drtgh wrote: post #96

This sounds more than great. Unrelated but at same time related, feel your self absolutelly free to ignore this message, Linux needs a HISP with firewall. I comment it here because this need to be supported by a/the kernel, its needed to limit the functions that allow process injections, and also a way for to canalize all the process executions in a supervised mode. As an [put operative system name here] user, I need…

What do you mean by HISP? That doesn't appear to be a standard acronym.

As another user commented though, SELinux would seem to be capable of everything you suggest. You say RSBAC is closer than SELinux but I don't see how it offers anything that SELinux doesn't aside from a few more obscure models.

Re: Maestro: A Linux-compatible kernel in Rust

#368

Post by fch42 » Sat, Jan 06, 2024, 6:59 PM UTC

bluGill wrote: post #124

insanitybit wrote: post #39

Earlier quoted context omitted.

I don't think it's that unfair, but I don't want to get into a whole thing about it, people get really upset about criticisms of the Linux kernel in my experience and I'm not looking to start my morning off with that conversation. We can agree that C was definitely the language to be doing these things in and I don't blame Linus for choosing it. My point wasn't to shit on Linux for its decisions, it was to think abou…

why not ada? Sure rust didn't exist when linux was first being built, but ada did and had a number of memory safety features. (not the same as rust's, but still better than C)

The "historical anecdote" is that somewhen around kernel 0.99, C++ was tried. And given up due to both compiler bugs and (worse) abysmal compilation performance.

For all I know about Ada, the latter has a reputation for "non-speed" on compile worse than C++ even. Nevermind that gnats (gcc ada integration) post-dates Linux by a few years.

Of course, it could simply be that Linus looked, got an allergic fit, and hence didn't bother ...

Re: Maestro: A Linux-compatible kernel in Rust

#369

Post by F3nd0 » Sat, Jan 06, 2024, 11:02 PM UTC

PrimeMcFly wrote: post #351

F3nd0 wrote: post #308

Earlier quoted context omitted.

> What, exactly, is supposed to be so bad about that? The eventual users of the hypothetical commercial OS lose their freedom. (Or don't get their freedom, depending on your point of view.) Permissive licences grant users freedom, but don't preserve those freedoms in derivative works, so the original work can end up helping derived software disrespect users' freedom. For those who believe that users' freedom should a…

Freedom includes allowing users to choose a less free alternative because they derive benefits in doing so.

Copyleft in no way prevents users from choosing to use alternative software. It merely prevents them from stripping away the associated freedoms for other users.

Re: Maestro: A Linux-compatible kernel in Rust

#370

Post by PrimeMcFly » Sat, Jan 06, 2024, 11:29 PM UTC

F3nd0 wrote: post #369

PrimeMcFly wrote: post #351

Earlier quoted context omitted.

Freedom includes allowing users to choose a less free alternative because they derive benefits in doing so.

Copyleft in no way prevents users from choosing to use alternative software. It merely prevents them from stripping away the associated freedoms for other users.

> Copyleft in no way prevents users from choosing to use alternative software.

No, but you arguing every FOSS project should be GPL3 does. You're arguing against alternative licenses here, meaning you're arguing against freedom of people to release software under a license they prefer.