13 ms·

Redox OS Crash Challenge

179 points by dragostis 9y ago

halayli 9y ago
Rust being advertised as a safe language (which is true) got so much into the user's heads that they think if they write it in Rust it's safe and crash free by default. There are plenty of security/safety bugs that aren't about dereferencing a null or accessing invalid ptr. No cynicism intended, just an observation from what I see around.
- __s 9y ago
  Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out? ( proggit's got the cynical side going: https://www.reddit.com/r/programming/comments/7ryiih/redox_os_crash_challenge/dt0k4ad/?st=jcp3s4ik&sh=f7bfd88c https://www.reddit.com/r/programming/comments/7ryiih/redox_o... )
  - infinity0 9y ago
    No but the machine shouldn't do something stupid, like burn down.
    - __s 9y ago
      The quote is about data, & now our code is data. The computer indeed should not burn down-- even if the kernel faults
      - infinity0 9y ago
        The kernel faulting is effectively burning down. In modern systems there is the concept of "isolation", if you give bad input to one program (e.g. the shell) the kernel shouldn't fault (taking down unrelated programs with it).
        tscs37 9y ago
        There is (most likely) no perfect isolation. If given no alternatives, a kernel should burn down rather than permitting a privilege escalation. Ideally there is no privilege escalation either. Given bad input the kernel should not fault but sometimes it must.
        infinity0 9y ago
        Imperfect isolation is always treated as a bug. As a kernel developer if you try to argue otherwise you'll get laughed out of the room and/or fired. Hopefully both.
        tscs37 9y ago
        I'm not saying imperfect isolation isn't a bug. Rather that bugs are inevitable and the proper responce to some bugs being exploited (maliciously or not) is to crash the kernel if there is no other option.
        lordnaikon 9y ago
        Hardware can misbehave. If the kernel can detect that it is reasonable to shut down the machine and preventing data corruptions. I cannot think of a kernel developer who would laugh at that.
        EtDybNuvCu 9y ago
        Capability-safe languages in the E family, like E and Monte, have perfect isolation, or as it's known in the community, "working encapsulation." In a capability-safe system, only bugs in the implementation, such as runtime or CPU bugs, can violate isolation. Here's an introduction to E: http://www.erights.org/talks/promises/paper/tgc05-submitted.pdf http://www.erights.org/talks/promises/paper/tgc05-submitted.... The Monte language's manual starts with a tutorial and an explanation of what capability-safe languages do: http://monte.readthedocs.io/ http://monte.readthedocs.io/
        tscs37 9y ago
    - Twirrim 9y ago
      Depends. Did you tell tell it to burn down?
- surajrmal 9y ago
  > Rust being advertised as a safe language (which is true) got so much into the user's heads that they think if they write it in Rust it's safe and crash free by default. There are plenty of security/safety bugs that aren't about dereferencing a null or accessing invalid ptr. > No cynicism intended, just an observation from what I see around. The difference is what happens when a bug is encountered. If it is caught and panicked upon, then that is safe predictible behavior that cannot be exploited into something like privilege escallation.
  - SAI_Peregrinus 9y ago
    Crash bugs caused by a panic can't necessarily be used for privilege escalation, but they can certainly be used for DOS attacks.
  - halayli 9y ago
    My point is that privilege escalation can happen from logical bugs
  - zerokernel 9y ago
    Panics can of course result in exploitable system behaviour.
  - hedora 9y ago
    I remember when all the same arguments were made about Java, which led people to ignore the possibility of memory leakage and privilege escalation, even though both those things are common problems with idiomatic Java. For instance: Swing recommends you register callbacks all over the place, but those cause otherwise dereferenced windows to stay live from the GC’s perspective (this is a general problem with the callback pattern, not swing). Java serialization surfaces all sorts of private methods to outside processes via the reflection APIs, which is even easier to exploit than arbitrary memory stomping in C. Practically everything can throw a null pointer exception, and all generics code can throw ClassCastExceptions. Writing all the error handling logic for this is at least as hard as restricting yourself to a memory-safe subset of C++ templates. If you miss an error handling case, an attacker can use that to escalate up to increasingly high level invariant violations in your code. Basic things like “final” have ill-defined semantics with multithreaded code (final fields can change value, even without reflection). I don’t know Rust well enough to know which classes of these bugs it has (and I doubt the Rust community really does either—-it took the Java world a decade to notice some issues like the above). With the exception of the “final” problems, I think fixing any of the things I listed reduces to solving the halting problem, or giving up on using turing complete languages. This makes me skeptical of many claims coming from Rust proponents at the moment.
- azdle 9y ago
  I don't see anything in the link that seems to imply that they think Redox OS is going to be crash free? In fact this seems to be the opposite, it looks to me like they're looking for bugs to squash.
  - baobrien 9y ago
    I agree. Particularly "There are a few ways already that I believe lockups or program crashes can be triggered, but I am looking for the experiences of others."
  - fny 9y ago
    The OP isn't making a claim about anyone involved in Redox, but rather the general perception of Rust, particularly among non systems programmers. I tend to agree. I've shook hands with a lot of people that see Rust as a panacea rather than a mitigation strategy.
    - Nomentatus 9y ago
      To my mind Rust is neither a panacea nor a mere mitigation strategy. It (or another language like it) is a necessary condition for anything like generally safe (not perfect) computing. Please don't jump to the conclusion that someone who thinks that Rust isn't just one more mitigation strategy is an addled fanboi who thinks it's a total panacea and snake oil. That is NOT what they're saying. They are saying it's necessary for robust computing and I think they're right about that. I'm quite tired of being instantly and vehemently misunderstood on this point so often, personally. So many people seem eager to put not just words but whole chapters in my mouth, even at the cost of using rather rotten logic to accomplish that. Those of us with considerable respect for Rust DO indeed understand that a necessary condition for genuinely safer computing is not a sufficient condition - but I do sometimes wonder if those who have less interest in Rust and sneer at anything resembling enthusiasm for it, have recognized this distinction, or have gotten that far in their thinking.
      - SAI_Peregrinus 9y ago
        The idea that something can be "necessary but not sufficient" comes up a lot, and is very often misunderstood. Rust-like guarantees are necessary but not sufficient for safe systems.
- lobster_johnson 9y ago
  Rust is not just about null pointers. It's also about race conditions in the face of mutation. See this recent [1] for a concrete example in the context of systems programming. [1] https://news.ycombinator.com/item?id=16189088 https://news.ycombinator.com/item?id=16189088
- geofft 9y ago
  > There are plenty of security/safety bugs that aren't about dereferencing a null or accessing invalid ptr. Sure, but there are also plenty of improvements in Rust that aren't about memory safety. For instance, there's the improved type system over C or C++ (tuples, enums, traits, etc.), related features like pattern-matching on enums and trait-based error handling (the question-mark operator), and a macro system that works at the syntax-tree level and not the source level. All of these mean that you're less likely to write code with logic bugs. This isn't as clearly true as it is that you're less likely to write code with memory safety bugs, and it's harder to either argue or measure empirically, so it's not as commonly claimed as the memory safety. But a lot of stupid bugs in C come from things like forgetting to check error returns, or confusing two things that are both represented as char * , or accessing a resource without proper serialization (which isn't strictly speaking a memory-safety bug), or having side effects in an expression you pass to a macro. Those bugs are harder to write in Rust because there are more readable ways to write the same constructs that don't let you make the same mistakes. You certainly can write safe Rust code that makes the same mistakes, you're just less likely to because it's the more cumbersome way to do it.
  - ModernMech 9y ago
    > like forgetting to check error returns One of the most common bugs in C (in my experience) is forgetting to check the error return on a malloc call. Kind of the worst of both worlds.
    - wott 9y ago
      > One of the most common bugs in C (in my experience) is forgetting to check the error return on a malloc call. Very unlikely. 1. it won't happen in regular use, only if your are asking for a huge amount of memory (possibly by mistake), or the system is already full and you will likely experience problems with the whole system (freezes, instability, processes killed, etc) and not just with your program. 2. it will never happen in Linux, because in the classical setup, malloc() never returns NULL, even when there is no memory available. So you have to have those conditions + a return value unchecked for the bug to have a chance to appear. There are thousands of other bug sources.
davisdude 9y ago
Related: the Changelog podcast did a really good interview with the developer[1]. It's pretty long but worth the listen IMO. [1]: https://changelog.com/podcast/280 https://changelog.com/podcast/280
- pohl 9y ago
  I listened to this last night; it’s great.
- jesse_m 9y ago
  just listened to it too. That podcast has some other interesting interviews like with Miguel de Icaza.
snvzz 9y ago
I'd rather trust something with a formal proof, such as seL4. https://sel4.systems https://sel4.systems
- steveklabnik 9y ago
  It's being worked on! part of libstd was formally verified, as well. Lots of more work to be done though. http://plv.mpi-sws.org/rustbelt/ http://plv.mpi-sws.org/rustbelt/ was even just presented at POPL!
- Ar-Curunir 9y ago
  The two aren't mutually exclusive.
- nickpsecurity 9y ago
  https://robigalia.org https://robigalia.org
andrewstuart 9y ago
This was the output I got when I followed the instructions from the book: - what should I have seen? Can you suggest what I can do to make it work? (venv3.5) root@ubuntu-s-1vcpu-1gb-nyc1-01:~# qemu-system-x86_64 -serial mon:stdio -d cpu_reset -d guest_errors -smp 4 -m 1024 -s -machine q35 -device ich9-intel-hda -device hda-duplex -net nic,model=e1000 -net user -device nec-usb-xhci,id=xhci -device usb-tablet,bus=xhci.0 -enable-kvm -cpu host -drive file=redox_0.3.4.bin,format=raw -nographic pulseaudio: pa_context_connect() failed pulseaudio: Reason: Connection refused pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver ALSA lib confmisc.c:768:(parse_card) cannot find card '0' ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib conf.c:4771:(snd_config_expand) Evaluate error: No such file or directory ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default alsa: Could not initialize DAC alsa: Failed to open `default': alsa: Reason: No such file or directory ALSA lib confmisc.c:768:(parse_card) cannot find card '0' ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib conf.c:4771:(snd_config_expand) Evaluate error: No such file or directory ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default alsa: Could not initialize DAC alsa: Failed to open `default': alsa: Reason: No such file or directory audio: Failed to create voice `dac' ALSA lib confmisc.c:768:(parse_card) cannot find card '0' ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib conf.c:4771:(snd_config_expand) Evaluate error: No such file or directory ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default alsa: Could not initialize ADC alsa: Failed to open `default': alsa: Reason: No such file or directory ALSA lib confmisc.c:768:(parse_card) cannot find card '0' ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib conf.c:4771:(snd_config_expand) Evaluate error: No such file or directory ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default alsa: Could not initialize ADC alsa: Failed to open `default': alsa: Reason: No such file or directory audio: Failed to create voice `adc' qemu-system-x86_64: terminating on signal 15 from pid 8287 (venv3.5) root@ubuntu-s-1vcpu-1gb-nyc1-01:~#

179 points by dragostis 9y ago

Rust being advertised as a safe language (which is true) got so much into the user's heads that they think if they write it in Rust it's safe and crash free by default. There are plenty of security/safety bugs that aren't about dereferencing a null or accessing invalid ptr. No cynicism intended, just an observation from what I see around.

__s 9y ago
Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out? ( proggit's got the cynical side going: https://www.reddit.com/r/programming/comments/7ryiih/redox_os_crash_challenge/dt0k4ad/?st=jcp3s4ik&sh=f7bfd88c https://www.reddit.com/r/programming/comments/7ryiih/redox_o... )
- infinity0 9y ago
  No but the machine shouldn't do something stupid, like burn down.
  - __s 9y ago
    The quote is about data, & now our code is data. The computer indeed should not burn down-- even if the kernel faults
    - infinity0 9y ago
      The kernel faulting is effectively burning down. In modern systems there is the concept of "isolation", if you give bad input to one program (e.g. the shell) the kernel shouldn't fault (taking down unrelated programs with it).
      - tscs37 9y ago
        There is (most likely) no perfect isolation. If given no alternatives, a kernel should burn down rather than permitting a privilege escalation. Ideally there is no privilege escalation either. Given bad input the kernel should not fault but sometimes it must.
        infinity0 9y ago
        Imperfect isolation is always treated as a bug. As a kernel developer if you try to argue otherwise you'll get laughed out of the room and/or fired. Hopefully both.
        tscs37 9y ago
        I'm not saying imperfect isolation isn't a bug. Rather that bugs are inevitable and the proper responce to some bugs being exploited (maliciously or not) is to crash the kernel if there is no other option.
        lordnaikon 9y ago
        Hardware can misbehave. If the kernel can detect that it is reasonable to shut down the machine and preventing data corruptions. I cannot think of a kernel developer who would laugh at that.
        EtDybNuvCu 9y ago
        Capability-safe languages in the E family, like E and Monte, have perfect isolation, or as it's known in the community, "working encapsulation." In a capability-safe system, only bugs in the implementation, such as runtime or CPU bugs, can violate isolation. Here's an introduction to E: http://www.erights.org/talks/promises/paper/tgc05-submitted.pdf http://www.erights.org/talks/promises/paper/tgc05-submitted.... The Monte language's manual starts with a tutorial and an explanation of what capability-safe languages do: http://monte.readthedocs.io/ http://monte.readthedocs.io/
        tscs37 9y ago
  - Twirrim 9y ago
    Depends. Did you tell tell it to burn down?
surajrmal 9y ago
> Rust being advertised as a safe language (which is true) got so much into the user's heads that they think if they write it in Rust it's safe and crash free by default. There are plenty of security/safety bugs that aren't about dereferencing a null or accessing invalid ptr. > No cynicism intended, just an observation from what I see around. The difference is what happens when a bug is encountered. If it is caught and panicked upon, then that is safe predictible behavior that cannot be exploited into something like privilege escallation.
- SAI_Peregrinus 9y ago
  Crash bugs caused by a panic can't necessarily be used for privilege escalation, but they can certainly be used for DOS attacks.
- halayli 9y ago
  My point is that privilege escalation can happen from logical bugs
- zerokernel 9y ago
  Panics can of course result in exploitable system behaviour.
- hedora 9y ago
  I remember when all the same arguments were made about Java, which led people to ignore the possibility of memory leakage and privilege escalation, even though both those things are common problems with idiomatic Java. For instance: Swing recommends you register callbacks all over the place, but those cause otherwise dereferenced windows to stay live from the GC’s perspective (this is a general problem with the callback pattern, not swing). Java serialization surfaces all sorts of private methods to outside processes via the reflection APIs, which is even easier to exploit than arbitrary memory stomping in C. Practically everything can throw a null pointer exception, and all generics code can throw ClassCastExceptions. Writing all the error handling logic for this is at least as hard as restricting yourself to a memory-safe subset of C++ templates. If you miss an error handling case, an attacker can use that to escalate up to increasingly high level invariant violations in your code. Basic things like “final” have ill-defined semantics with multithreaded code (final fields can change value, even without reflection). I don’t know Rust well enough to know which classes of these bugs it has (and I doubt the Rust community really does either—-it took the Java world a decade to notice some issues like the above). With the exception of the “final” problems, I think fixing any of the things I listed reduces to solving the halting problem, or giving up on using turing complete languages. This makes me skeptical of many claims coming from Rust proponents at the moment.
azdle 9y ago
I don't see anything in the link that seems to imply that they think Redox OS is going to be crash free? In fact this seems to be the opposite, it looks to me like they're looking for bugs to squash.
- baobrien 9y ago
  I agree. Particularly "There are a few ways already that I believe lockups or program crashes can be triggered, but I am looking for the experiences of others."
- fny 9y ago
  The OP isn't making a claim about anyone involved in Redox, but rather the general perception of Rust, particularly among non systems programmers. I tend to agree. I've shook hands with a lot of people that see Rust as a panacea rather than a mitigation strategy.
  - Nomentatus 9y ago
    To my mind Rust is neither a panacea nor a mere mitigation strategy. It (or another language like it) is a necessary condition for anything like generally safe (not perfect) computing. Please don't jump to the conclusion that someone who thinks that Rust isn't just one more mitigation strategy is an addled fanboi who thinks it's a total panacea and snake oil. That is NOT what they're saying. They are saying it's necessary for robust computing and I think they're right about that. I'm quite tired of being instantly and vehemently misunderstood on this point so often, personally. So many people seem eager to put not just words but whole chapters in my mouth, even at the cost of using rather rotten logic to accomplish that. Those of us with considerable respect for Rust DO indeed understand that a necessary condition for genuinely safer computing is not a sufficient condition - but I do sometimes wonder if those who have less interest in Rust and sneer at anything resembling enthusiasm for it, have recognized this distinction, or have gotten that far in their thinking.
    - SAI_Peregrinus 9y ago
      The idea that something can be "necessary but not sufficient" comes up a lot, and is very often misunderstood. Rust-like guarantees are necessary but not sufficient for safe systems.
lobster_johnson 9y ago
Rust is not just about null pointers. It's also about race conditions in the face of mutation. See this recent [1] for a concrete example in the context of systems programming. [1] https://news.ycombinator.com/item?id=16189088 https://news.ycombinator.com/item?id=16189088
geofft 9y ago
> There are plenty of security/safety bugs that aren't about dereferencing a null or accessing invalid ptr. Sure, but there are also plenty of improvements in Rust that aren't about memory safety. For instance, there's the improved type system over C or C++ (tuples, enums, traits, etc.), related features like pattern-matching on enums and trait-based error handling (the question-mark operator), and a macro system that works at the syntax-tree level and not the source level. All of these mean that you're less likely to write code with logic bugs. This isn't as clearly true as it is that you're less likely to write code with memory safety bugs, and it's harder to either argue or measure empirically, so it's not as commonly claimed as the memory safety. But a lot of stupid bugs in C come from things like forgetting to check error returns, or confusing two things that are both represented as char * , or accessing a resource without proper serialization (which isn't strictly speaking a memory-safety bug), or having side effects in an expression you pass to a macro. Those bugs are harder to write in Rust because there are more readable ways to write the same constructs that don't let you make the same mistakes. You certainly can write safe Rust code that makes the same mistakes, you're just less likely to because it's the more cumbersome way to do it.
- ModernMech 9y ago
  > like forgetting to check error returns One of the most common bugs in C (in my experience) is forgetting to check the error return on a malloc call. Kind of the worst of both worlds.
  - wott 9y ago
    > One of the most common bugs in C (in my experience) is forgetting to check the error return on a malloc call. Very unlikely. 1. it won't happen in regular use, only if your are asking for a huge amount of memory (possibly by mistake), or the system is already full and you will likely experience problems with the whole system (freezes, instability, processes killed, etc) and not just with your program. 2. it will never happen in Linux, because in the classical setup, malloc() never returns NULL, even when there is no memory available. So you have to have those conditions + a return value unchecked for the bug to have a chance to appear. There are thousands of other bug sources.

davisdude 9y ago

Related: the Changelog podcast did a really good interview with the developer[1]. It's pretty long but worth the listen IMO. [1]: https://changelog.com/podcast/280 https://changelog.com/podcast/280

pohl 9y ago
I listened to this last night; it’s great.
jesse_m 9y ago
just listened to it too. That podcast has some other interesting interviews like with Miguel de Icaza.

snvzz 9y ago

I'd rather trust something with a formal proof, such as seL4. https://sel4.systems https://sel4.systems

steveklabnik 9y ago
It's being worked on! part of libstd was formally verified, as well. Lots of more work to be done though. http://plv.mpi-sws.org/rustbelt/ http://plv.mpi-sws.org/rustbelt/ was even just presented at POPL!
Ar-Curunir 9y ago
The two aren't mutually exclusive.
nickpsecurity 9y ago
https://robigalia.org https://robigalia.org

andrewstuart 9y ago

This was the output I got when I followed the instructions from the book: - what should I have seen? Can you suggest what I can do to make it work? (venv3.5) root@ubuntu-s-1vcpu-1gb-nyc1-01:~# qemu-system-x86_64 -serial mon:stdio -d cpu_reset -d guest_errors -smp 4 -m 1024 -s -machine q35 -device ich9-intel-hda -device hda-duplex -net nic,model=e1000 -net user -device nec-usb-xhci,id=xhci -device usb-tablet,bus=xhci.0 -enable-kvm -cpu host -drive file=redox_0.3.4.bin,format=raw -nographic pulseaudio: pa_context_connect() failed pulseaudio: Reason: Connection refused pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver ALSA lib confmisc.c:768:(parse_card) cannot find card '0' ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib conf.c:4771:(snd_config_expand) Evaluate error: No such file or directory ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default alsa: Could not initialize DAC alsa: Failed to open `default': alsa: Reason: No such file or directory ALSA lib confmisc.c:768:(parse_card) cannot find card '0' ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib conf.c:4771:(snd_config_expand) Evaluate error: No such file or directory ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default alsa: Could not initialize DAC alsa: Failed to open `default': alsa: Reason: No such file or directory audio: Failed to create voice `dac' ALSA lib confmisc.c:768:(parse_card) cannot find card '0' ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib conf.c:4771:(snd_config_expand) Evaluate error: No such file or directory ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default alsa: Could not initialize ADC alsa: Failed to open `default': alsa: Reason: No such file or directory ALSA lib confmisc.c:768:(parse_card) cannot find card '0' ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib conf.c:4771:(snd_config_expand) Evaluate error: No such file or directory ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default alsa: Could not initialize ADC alsa: Failed to open `default': alsa: Reason: No such file or directory audio: Failed to create voice `adc' qemu-system-x86_64: terminating on signal 15 from pid 8287 (venv3.5) root@ubuntu-s-1vcpu-1gb-nyc1-01:~#