|
qnx is probably still used in aerospace and defense products. Likely because certifications makes it a hard sell to use Linux unless you're willing to foot the bill to get it through the process. I'm willing to bet that QNX provides a lot of the integration engineering for higher profile customers anyway. Contracts like those are probably why they can guarantee your employment. Wind River is still selling its Linux, though, so maybe there's money in it if you can leverage existing clients or coast on your reputation. It's a big feather in your cap to say that your flagship product (vxworks) powers the mars rover. VxWorks has historically been more resource efficient (for integrators) than Linux, which used to be important when 2MB vs 4MB of flash was actually significant - see linksys consumer routers that use vxworks vs linux.
|
#
?
Nov 7, 2021 21:47
|
|
|
|
| # ? May 12, 2024 12:16 |
|
|
will mainline realtime really do much of anything to other vendors short-medium term anyway? i figured most of this would be space where vendor support would be pretty important, and just following mainline would also be ruled out for the usual stable abi reasons?
|
|
#
?
Nov 7, 2021 21:58
|
|
|
You're likely correct. At the very least, another LTS with these changes would have to come first. At the very least, particularly single processor systems, will see improved latency since kernel processes can now be pre-empted. But developers would have to start assigning priority for it to have any real effects. I wonder if Firefox can take advantage of this to allow for more responsive behavior. Kernel side, developers will need to start rewriting code. Which they won't do, unless they get paid for it. So that means that we won't see this work in existing devices... only devices that have BSPs with this new kernel, so likely not for a few years. Something I thought about.... it might even allow for more sloppy drivers, since you don't have to yield the process to let other people do work. It might make single processor SBCs, or even some multi processor SBCs, work better if they have proprietary drivers. Beyond that, I think we would have to see more and more drivers and subsystems adopt more nuanced locking (including the new sleeping lock) so widespread benefits may take awhile to trickle in. Also, exposing this stuff to new developers will undoubtedly lead to further changes. I look forward to the next raspbian that has this enabled. It'll be a fun way to have a hands on look at the effects.
|
|
#
?
Nov 8, 2021 00:23
|
|
|
you can do that now with the beaglebone and the official RT kernel provided by TI. It’s quite good!
|
|
#
?
Nov 8, 2021 18:54
|
|
|
sitaras are all slower than the rpi though so i don't blame them for wanting an apples to apples comparison with what they're used to
|
|
#
?
Nov 8, 2021 18:55
|
|
|
That is fair. Although you could use the non-rt Sitara kernel and the RT Sitara kernel if you want to compare. 
|
|
#
?
Nov 8, 2021 19:01
|
|
|
DoomTrainPhD posted:you can do that now with the beaglebone and the official RT kernel provided by TI. It’s quite good! Sure, just give me a beaglebone and I'll get right on it
|
|
#
?
Nov 9, 2021 04:33
|
|
|
sb hermit posted:Sure, just give me a beaglebone and I'll get right on it 
|
|
#
?
Nov 9, 2021 04:48
|
|
|
I went through some quickstart steps for yocto last night and it *just worked* on my ubuntu 20.04 machine. Now I have to test the image when I get a moment. Then, I'll move to running it on an rpi. Kinda miss the elaborate buildroot menu configuration system but I can see this grow on me.
|
|
#
?
Nov 10, 2021 19:42
|
|
|
If you aren’t using systemd you are wrong and should fix that asap.
|
|
#
?
Nov 10, 2021 20:19
|
|
|
agreed, systemd is a Good Thing on embedded systems. It's a poo poo project maintained by the worst company imaginable (IBM), and easily 50% of it are bad and dumb things. But the other 50% really kicks rear end, and systemd-init is miles above every competitor when it comes to making a good embedded system. Really nice to have an init system that can express things like: - Service A can only run if service B running. Shut it down if Service B crashes. - Service B depends on a USB device being present and active (such as a USB microcontroller that looks like a USB UART). - Service A can't write to anything outside of /tmp, and can't exec anything. - Service C and Service A share a common /tmp, but service B can't see it. - Service C will get auto-restarted if it doesn't kick the watchdog every so often. - Service C will restart up to 10 times with a 0.5 second delay before eventually giving up. - Service A and all children can only run on CPU cores 5 and 6. - Service B is granted setcap to change its own process priority, even though it's running as a non-root user. Poopernickel fucked around with this message at 22:00 on Nov 10, 2021 |
|
#
?
Nov 10, 2021 21:54
|
|
|
I'm just gonna make my main process be the init and install a kernel watchdog to hard reboot the system if poo poo happens no room for systemd at that point, get that poo poo outta here
|
|
#
?
Nov 10, 2021 22:00
|
|
|
sb hermit posted:I'm just gonna make my main process be the init and install a kernel watchdog to hard reboot the system if poo poo happens hope you don't like being able to log in with ssh or a serial-console
|
|
#
?
Nov 10, 2021 22:06
|
|
|
sb hermit posted:I'm just gonna make my main process be the init and install a kernel watchdog to hard reboot the system if poo poo happens perché non entrambe? Why not have a bash script call your app and then exec systemd?
|
|
#
?
Nov 10, 2021 22:06
|
|
|
DoomTrainPhD posted:perché non entrambe? Why not have a bash script call your app and then exec systemd? jeezus that's the worst of every possible world, you'll have a mystery floating process that systemd isn't monitoring. And if it crashes, the kernel won't restart it like it does with PID1.
|
|
#
?
Nov 10, 2021 22:10
|
|
|
well yeah, that’s why you monitor systemd with your process and then fork once systemd is fully up and running so systemd can track the new pid
|
|
#
?
Nov 10, 2021 22:14
|
|
|
Poopernickel posted:jeezus that's the worst of every possible world, you'll have a mystery floating process that systemd isn't monitoring. And if it crashes, the kernel won't restart it like it does with PID1. when your watchdog is 
|
|
#
?
Nov 10, 2021 22:35
|
|
|
I like how yocto linux for the rpi actually gives you an image that you can dump, in its entirety, on an sd card. I also like how logging in as root is as easy as specifying root on the login prompt. No performative security. None of the extraneous guard rails of an automatically expanding rootfs or curses enabled config menu. And I think it's a US based keyboard layout, which makes my life easier. I can still pare the system down and cut the boot time and some memory usage further.
|
|
#
?
Nov 12, 2021 09:00
|
|
|
Been playing with qemu a bit over the past couple of days. The riscv emulator is surprisingly fast. Kernel boots to a login prompt in around 2 seconds.
|
|
#
?
Nov 12, 2021 16:39
|
|
|
what do you mean BSD doesn’t have enough drivers, it has all the drivers my 30+ year old hardware could ever need someone is even working on bringing up X11 on Sun-2 again! but in all seriousness, BSD is pretty straightforward to write drivers for, and both NetBSD and FreeBSD have decent bus/interface/etc. abstractions these days that you can use to keep driver implementation clean not OpenBSD though, that poo poo has different drivers for the same VME boards for different machines because they don’t believe in that level of abstraction (and also compile all drivers into the kernel because they don’t believe in loadable modules) the big two issues I see with BSD are the divergence between NetBSD and FreeBSD so drivers and kernel features are more difficult to share, and the relative lack of separation between “architecture” and “machine” that mostly exist for historical purposes it’d be great if all ARMv7, 68K, etc. architecture systems each used a single kernel and userland, with machine-specific drivers loaded via modules on a RAM disk passed at boot
|
|
#
?
Nov 12, 2021 22:21
|
|
|
sounds like you should post on the freebsd and netbsd mailing lists and ask them to develop a stable kernel abi op
|
|
#
?
Nov 13, 2021 15:55
|
|
|
somebody should make a BSD that runs on Linux and call it Linux Subsystem for BSD (LSB for short)
|
|
#
?
Nov 13, 2021 17:09
|
|
|
Sapozhnik posted:sounds like you should post on the freebsd and netbsd mailing lists and ask them to develop a stable kernel abi op 
|
|
#
?
Nov 13, 2021 20:05
|
|
|
Been at it for two days adding SELinux into our project. It was always planned from the beginning, but yeash. I memory-holed how tedious making a custom policy can be. Adding a context for each of the applications Adding contexts for every file and folder in /data and /factory Adding permissions for restorecon and audit Adding all the policies for each app. I’m happy it’s almost done though! FlapYoJacks fucked around with this message at 07:49 on Dec 10, 2021 |
|
#
?
Dec 10, 2021 07:45
|
|
|
DoomTrainPhD posted:Been at it for two days adding SELinux into our project. It was always planned from the beginning, but yeash. I memory-holed how tedious making a custom policy can be.  Security work is thankless, but at least it can pay the bills if you're lucky.
|
|
#
?
Dec 10, 2021 07:57
|
|
|
that sounds nightmarish ooc, why selinux instead of systemd sandboxing?
|
|
#
?
Dec 10, 2021 08:04
|
|
|
selinux provides very very strong type enforcement of a ton of resources. So if you want to make sure that a constellation of apps only access certain files or directories, or if you want to enforce the ability to only listen to certain network ports, and so on, then selinux is the tool for you. I'm not saying that systemd sandboxing or seccomp are supplanted by selinux. They can certainly complement each other's capabilities, particularly for stuff like system calls. But type enforcement checks off some pretty important checkboxes for some security requirements, so it's worth doing.
|
|
#
?
Dec 10, 2021 08:47
|
|
|
Sapozhnik posted:sounds like you should post on the freebsd and netbsd mailing lists and ask them to develop a stable kernel abi op
|
|
#
?
Dec 10, 2021 08:48
|
|
|
sb hermit posted:selinux provides very very strong type enforcement of a ton of resources. So if you want to make sure that a constellation of apps only access certain files or directories, or if you want to enforce the ability to only listen to certain network ports, and so on, then selinux is the tool for you. systemd does both of these things on a per-service basis and it's super easy filesystem limiting: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ReadWritePaths= port limiting: https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#SocketBindAllow=bind-rule rather than go the selinux route, I've had really good luck with this approach: 1. run all network-accessible services as an unprivileged user 2. very limited setcap for things like changing process niceness 3. systemd sandboxing to enforce access control. Read access to /bin, /sbin, /usr/bin, /usr/sbin was blocked on all services except the firmware update service. 4. Read-only rootfs. 5. Noexec on all writeable paths. 6. For the firmware updater, put the root-needing parts into something you can wrap with passwordless sudo. Use a sudo policy that only lets the thing be launched in very specific ways, and let your non-root service launch it as-needed. Steps 1-5 were all deadass easy with systemd. Also easy to maintain going forward. Poopernickel fucked around with this message at 09:50 on Dec 10, 2021 |
|
#
?
Dec 10, 2021 08:58
|
|
|
Afaik nobody's managed to hack that line of products, although admittedly the stakes are low if they do - just some stolen software unlocks and maybe some secret sauce binaries
|
|
#
?
Dec 10, 2021 09:20
|
|
|
Poopernickel posted:systemd does both of these things on a per-service basis and it's super easy this is all well and good but if you are checking off compliance poo poo, selinux will be accepted by everyone, and im going to guess systemd’s is not. especially since selinux is kernel level.
|
|
#
?
Dec 10, 2021 13:38
|
|
|
Yep, it’s a compliance thing as well as a piece of mind. The system also has: - The root user is disabled. - Every application runs as its user (ocppd has an ocppd user, etc.) without a login. - The root filing system is read-only. - Updates are encrypted, and the keys are in a TPM. - Two root filing systems (ping/pong updates) with automatic rollback support. - No sudo (wtf lol.) - Pam and Polkit are also enabled and used. Overall I’m attempting to put the S in IoT
FlapYoJacks fucked around with this message at 16:47 on Dec 10, 2021 |
|
#
?
Dec 10, 2021 15:53
|
|
|
yeah i would never use that systemd poo poo. looks like garbage.
|
|
#
?
Dec 10, 2021 17:46
|
|
|
CRIP EATIN BREAD posted:yeah i would never use that systemd poo poo. idk about that, but as inconvenient as it is selinux is actually way way up there in software features i really trust. so it makes me happy to hear a iot vendor is putting in the work.
|
|
#
?
Dec 10, 2021 17:50
|
|
|
selinux is actually not that hard to work with here's a good presentation on it: https://www.youtube.com/watch?v=_WOKRaM-HI4
|
|
#
?
Dec 10, 2021 18:50
|
|
|
CRIP EATIN BREAD posted:selinux is actually not that hard to work with SELinux without custom contexts is quite good! Adding your own contexts? Way more tedious. Edit* Also, that video Is the one I recommend to all new Linux developers on my team.
|
|
#
?
Dec 10, 2021 19:14
|
|
|
Just finished the initial SELinux implementation. 12,000 lines changed lmao.
|
|
#
?
Dec 15, 2021 01:10
|
|
|
ping/pong is the same as a/b I assume? I hadn’t heard that described as ping pong before
|
|
#
?
Dec 15, 2021 02:35
|
|
|
tick-tock tick-tock, clarice e: lol loving autocorrect eschaton fucked around with this message at 20:17 on Dec 15, 2021 |
|
#
?
Dec 15, 2021 10:00
|
|
|
|
| # ? May 12, 2024 12:16 |
|
|
DoomTrainPhD posted:Just finished the initial SELinux implementation. 12,000 lines changed lmao. Congrats! Also this is a good demonstration of why selinux is bad
|
|
#
?
Dec 15, 2021 16:02
|
|