[qubes-devel] module-vchan-sink and alternate sample format (float32le specifically) question
Hi! I've been poking around trying to figure out why pulseaudio equalizer has such horrible underrun/hiccup issues, and I vaguely suspect it is due to format conversion (I have been able to replicate roughly same behavior with loopback interfaces by meddling with format conversions (s16le-float32le-s24le). Also careful reading of pulse logs indicates that the equalizer LADSPA plugin only deals in float32le and it seems to me that the s16le->float32le->s16le conversion has something to do with it. It *seems* to me that "pre-converting" stuff before the equalizer using a null sink and a loopback fixed the issue (but it's clumsy, hard to automate, and there seems to be an unrelated sampling issue with loopback where loopbacks resample sourse no matter what, even if it's "44100->44100" (mentiones speex instead of copy in log when initializing loopback interfaces) so I want to try sending audio from the VM to the ladspa plugin in float32le format However, I'm not smart enough to actually read module-vchan-sink source beyond seeing that "format" option is supported. So before I waste a day doing something damnably stupid, I'd like to ask: Does module-vchan-sink support format float32le (rate being left at default 44100) ? -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/393a4f29-7422-40f5-b8bb-349b5c73e504%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Announcement: Toward a Reasonably Secure Laptop
On 07/08/2017 10:58 PM, Andrew David Wong wrote: So far, no third-party manufacturers have produced a computer that satisfies these requirements. However, ITL has entered initial talks with a promising partner with whom we can foresee creating a true Reasonably Secure Laptop. Our plan is to introduce a tier-based model of laptop support: It would be great to have a reasonably secure & modern laptop that has physical / non-programmable power switches and LEDs (and removable batteries). Whenever I think about 'blue pill' I think about the possibility that malware could fake reboot sequences. Knowing when a computer has truly reset / powered-on is part of the initial verification and trust process. -- Chris Laprise, tas...@openmailbox.org https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/73460ed0-9b30-1fb1-2cea-5a30cd1d5570%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: 'Hypervisor Introspection defeated Eternalblue a priori'
On 07/13/2017 08:02 PM, Marek Marczykowski-Górecki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Jul 13, 2017 at 04:45:35PM -0700, pixel fairy wrote: On Friday, July 7, 2017 at 1:20:10 PM UTC-7, Chris Laprise wrote: I know Joanna's reservations about VM introspection, but this Bitdefender introspection example is interesting nonetheless: https://businessinsights.bitdefender.com/hypervisor-introspection-defeated-enternalblue-a-priori Im curious about these reservations. is it the attack surface? Yes, at least two kinds: 1. Enabling API for reading VM memory break VM isolation - misbehaving monitoring VM can steal any secret and you'll never know If scanning VM instance (template based) could be granted access to only one subject VM, risk may not be terribly different from a disposable VM used to render documents. This can also be approximated to some degree when scanning the private storage of a subject VM... the attach function permits access to nothing else, and the scanner's state will disappear after it issues a (hopefully not false-negative) report and shuts down. A template-based VM may also perform checks on its own private storage as its mounted, as I'm exploring in a simple way with Qubes-VM-hardening. But 'attaching' a subject VM's memory as if it were a read-only drive would be a nifty thing to see.* 2. Parsing VM memory (operating system structures, application structures etc) is very complex - VM that know it is monitored can try exploit the parsing code; then go to point 1 for example As for examples what could possibly go wrong when adding anti-virus parsing whatever it can find, see here: https://bugs.chromium.org/p/project-zero/issues/detail?id=1252 Of course, but recognizing browser + traditional OS threat model is somewhat different vs Qubes disposable VMs. (* Not suggesting feature requests; just want to explore possibilities.) -- Chris Laprise, tas...@openmailbox.org https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/659ff35f-fa95-0f5e-8de4-e4551e0d8b52%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Fedora Template Desktop Flavors and more.
Nice work! Thanks Le samedi 8 juillet 2017 10:31:15 UTC+2, Epitre a écrit : > > Dear all, > > I'm quite new in the Qubes community and I'm pleased to be a part of as > QubesOS is a great distro. I'm daily using it now for several weeks and I'm > working on having a more comfortable user experience (at least for me). > > A first part I have been working is to add Fedora template flavors. I > created these templates in qubes-builder-fedora based on kickstart files > provided by Fedora for the spins, at least, for a minimum packages > selection. In order to have the proper desktop environment selected when > booting the AppVM (eg. appearance management), I added xinit scripts based > on start desktop scripts corresponding to the flavor selected (XFCE, LXQT > and so on). At this time, I tried flavors for KDE, LXDE, LXQT and XFCE, and > I'm daily using XFCE desktop for my AppVMs because it's small and also > uniform with the default choice of dom0. Before creating things properly on > github repos, I would like to know if it would interest some user and also > Qubes team. > > A second part was the general screen appearance. I like the Arc theme > developed by horst3180 (https://github.com/horst3180/arc-theme) but the > default package provided does not allow XFWM coloring of AppVM because it's > using PNG assets instead of XPM ones. I corrected this and forked the repo ( > https://github.com/fepitre/arc-theme for those who wants to try, don't > forget to build it with : --with-gnome=3.18 for Qubes 3.2). Probably some > colors adjustments are needed but it's a good start. This theme uses a nice > blue color for widgets, selection background etc. so for me it's perfect > for dom0. By the way, I wanted to go further than only coloring the window > borders in dom0. I have created arc-themes with all the colors of Qubes for > AppVMs in order to have in my opinion a more visual confirmation of which > VMs we are using. I have almost finished to prepare things for github ( > https://github.com/fepitre/qubes-arc-themes) so stay tuned ! Here is a > screenshot http://i.imgur.com/OLGKwo3.png > > Best Regards, > Epitre > > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/026aa631-cd33-4798-b917-91d691bd2bd1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Announcement: Toward a Reasonably Secure Laptop
Well, at least one phone maker has recognised that the best security comes from physical separation. Unfortunately, PC / laptop makers are a long way behind. Privat phone: http://privat-smartphone.com/#solution "PRIVAT has two independent mainboards, one for the smartphone hardware and the other one for the independent camera. Furthermore, each one has its own operating system with an internal memory and an expandable SD slot. You can also physically disconnect through a switch the GPS module, cameras and microphones. The use of PRIVAT could be useful for famous artists, business men, politicians or simply everyone who needs to keep high control of his private data through an robust system." -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/54146eb0-6576-40d9-92c4-2f32365b753a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
