Lennart Poettering On The Open-Source Community: A Sick Place To Be In

[erendorn]

SystemD has more features like D-Bus activation, socket activation which means it has bigger attack surface.

This is not really relevant per se.

The important thing is, first, determining the the level of exploits are made accessible by attacking pid 1. Then, the second step is, what is the total attack surface of the system that may result in this level of exploit. That's the surfaces you have to compare, not just a single component. You cannot compare a single link of a whole chain when determining the chain's strength.

If your exploit is crashing the system, or getting root access, or evading a container, the surfaces involved are muuuch bigger than 10 or 300kb anyway, and it's not even quite clear that they are bigger with systemd.

[JS987]

No, attack surfaces doesn't work like that. You can't just count the size of the executable. A small executable that allows someone pretty much unlimited access to do whatever they want has a larger attack surface than a big executable that only exposes specific interfaces in limited ways and that keeps close tabs on what is going on.

SystemD has more features like D-Bus activation, socket activation which means it has bigger attack surface.

[jaylittle]

So the entirety of your "technical argument" now revolves around the size of the executable? Based on that argument you are screwed. OpenBSD is clearly too insecure for you. Once Gentoo dumps OpenRC in favor of SystemD what will you switch to then? Windows? MUHAHAHAHAHAHA. Good luck with that.

EDIT: TheBlackCat of course nails it. Size of the executable has absolutely nothing to do with the size of the attack area.

[TheBlackCat]

sysvinit PID1 has only about 40 kB, which means systemd PID1 has over 30 times bigger attack surface.

No, attack surfaces doesn't work like that. You can't just count the size of the executable. A small executable that allows someone pretty much unlimited access to do whatever they want has a larger attack surface than a big executable that only exposes specific interfaces in limited ways and that keeps close tabs on what is going on.

Probability will increase with complexity.

All other things being equal. But of course they aren't in this case, far from it. Probability will also increase with the flexibility you give the user, since it makes it more likely to hit untested code paths.

[JS987]

I'm curious, what language did you think /sbin/init was written in? Hmmm... let's go check on the most secure open source operating system around, OpenBSD.
Oops. It's written in C. The compiled executable is over 300 kilobytes. Holy. Shit. Somebody ought to run and tell Theo that he's doing it wrong. I nominate you.

sysvinit PID1 has only about 40 kB, which means systemd PID1 has over 30 times bigger attack surface.

Duh. Yet SystemD has never crashed for me. Not even once. Hmmmmm... Perhaps you are just doing something wrong, eh?

If it didn't crash, doesn't mean it can't. Probability will increase with complexity.

[jaylittle]

Your post don't contain any relevant information.

Coming from you, that's practically priceless.

SystemD has bad impact on security and stability of Linux because of executable running as PID 1 with size over 1300 kB written in dangerous language like C by lax developers has big attack surface.

I'm curious, what language did you think /sbin/init was written in? Hmmm... let's go check on the most secure open source operating system around, OpenBSD.

Oops. It's written in C. The compiled executable is over 300 kilobytes. Holy. Shit. Somebody ought to run and tell Theo that he's doing it wrong. I nominate you.

Crash of PID 1 will crash whole system.

Duh. Yet SystemD has never crashed for me. Not even once. Hmmmmm... Perhaps you are just doing something wrong, eh?

If you make post, post something relevant.

If you make post, post something true.

[finalzone]

nice
i am in fact interested in the result, since, due to the VIA envy chip, your configuration is the best possible for PA
i would also like to know if there is a difference in cpu usage when playing a 44.1kHz sound compared to a 48kHz sound, as that would show if PA treats your card properly

basically with resampling moved to the sound card, this is mostly a benchmark of the overhead of PA's timing implementation and copy-ing
it is not that precise thou since dealing with alsa adds to the cpu usage of PA

I will try that when I get the chance. For your information about the onboard sound chip from both laptop:
Intel [HDA Intel], device 0: ALC262 Analog [ALC262 Analog]
Subdevices: 0/1
Subdevice #0: subdevice #0

and desktop:
VIA1708S 8 -Channel High Definition Audio CODEC
DTS Surround Sensation UltraPC
- Supports Jack-Detection, Multi-Streaming, and Front Panel Jack-Retasking
- Optical S/PDIF Out ports at back I/O
- ASUS Noise Filtering

I don't own a dedicated sound card. Starting another topic will be great.

[gens]

one system is enough thou, since they have the same sound card chip

correction, i misunderstood that bout your laptop and desktop have a VIA envy
oh well..

your laptop playing a sound that has a sample rate different then the default output would be the worst case scenario (unless they changed the default software resampler, then its just bad)
desktop with VIA envy would be the best case scenario

well... VIA envy on raw alsa output would be the best case scenario, thus a baseline

[gens]

Test was done in stock configuration.
My system both desktop (VIA soundchip) and laptop uses onboard soundcard. Tested both using above method. Still very minimal cpu usage. I will post a full detail later.

nice
i am in fact interested in the result, since, due to the VIA envy chip, your configuration is the best possible for PA
i would also like to know if there is a difference in cpu usage when playing a 44.1kHz sound compared to a 48kHz sound, as that would show if PA treats your card properly

basically with resampling moved to the sound card, this is mostly a benchmark of the overhead of PA's timing implementation and copy-ing
it is not that precise thou since dealing with alsa adds to the cpu usage of PA


since your card supports resampling, i would also be interested in what is the difference in the cpu usage of the application itself when using the alsa-PA plugin vs raw

pcm.!default{
type hw
card 0
}
ctl.!default{
type hw
card 0
}

this goes into $HOME/.asoundrc, it tells libalsa to use the sound card directly
on any other sound card this would cause problems when trying to play from 2 or more sound sources, but not on your

one system is enough thou, since they have the same sound card chip

maybe i am asking too much


note that this has, for the most part, nothing to do with latency
to properly measure latency would require an M-M 3.5mm cable connecting the cards output to input (and a resistor on it)
as described http://apps.linuxaudio.org/wiki/jack_latency_tests

[finalzone]

unless you changed the default resampling.. function used or all those sources put out the same sampling rate and bit depth as the output, PA should use relatively plenty of cpu
cpu frequency scaling also matters, since you are using an absolute value for cpu usage

Test was done in stock configuration.

try just playing a sound from one, light, source (like sox, aplay, moc or something like that)
then compare the cpu usage of that source to the cpu usage of PA
set the cpu freq scaling to "performance" for more precise results ( echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor )
edit: it also matters on if your sound card boasts a resampling feature, that i know of only one commercial that does (the ICE, aka VIA envy, chip)

My system both desktop (VIA soundchip) and laptop uses onboard soundcard. Tested both using above method. Still very minimal cpu usage. I will post a full detail later.