Re:size_t-to-int vulnerability in Linux’s filesystem layer
by mjevans on Tuesday July 20, 2021 @06:45PM
(#27900254)
Poorly designed security architecture and division of labor. A more idealized init / systemd would have all of the execution flow of PID 1 mathematically provably correct, and correspondingly have as small a footprint as possible there. All additional functions would run under one or more child processes (where the bulk of systemd would execute).
[ Parent
| on HN ]
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by bigiain on Tuesday July 20, 2021 @08:30PM
(#27900921)
"Lets put the graphics drivers in ring 0, for better performance!" -- Windows NT architects, 1996
"Ummm, lets not do that, it's not such a great idea..." -- Windows Vista team, 2006
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by fomine3 on Wednesday July 21, 2021 @12:15AM
(#27902261)
Initial Windows NT uses user mode graphic driver, then NT 4.0 move it kernel mode.
https://docs.microsoft.com/en-us/previous-versions//cc750820...
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by bigiain on Wednesday July 21, 2021 @01:41AM
(#27902712)
Yep. In about '96.
(Well, it came out late '96, so I suppose a bunch of that was actually done in '95.)
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by Spivak on Tuesday July 20, 2021 @10:43PM
(#27901791)
Different trade offs for different eras and different constraints.
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by failwhaleshark on Wednesday July 21, 2021 @12:06AM
(#27902219)
Systemd is a swiss-army-kitchen-sink-knife monolith of brittle complexity.
A proper init system similar to runit or s6 would be written in something safer (minimum unsafe) like Rust, be modular, simpler, follow UNIX philosophy, and not try to do everything in one process. Microkernel-style.