[qubes-users] Qubes OS list all available templates?
Hello, how can I list all available VM templates, for both Qubes OS and all templates provided by the community? Regards J. Eppler -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/68d20164-a250-4b92-b63f-391788423e14%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] How to make /lib/modules/* writable on R4.0 standalone?
I'm trying to manually add a kernel module to a standalone (from debian template) VM, but I can't re-mount the modules dir as read-write. I also tried to bind-mount a copy of modules to /lib/modules but modprobe doesn't see the new module. (insmod does see it, but it doesn't take care of dependencies like modprobe does). Is there a way to do this permanently? -- Chris Laprise, tas...@posteo.net https://github.com/tasket 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-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fafd1dc5-d372-6d2c-ce88-841ac9f8d7d2%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Archlinux upgrade error
Hello, I tried to upgrade my Archlinux VM. I did not upgrade it for some time. However, I get the following dependency errors: qubes-vm-gui: installing pulsaudio (11.1-1) breaks dependency 'pulsaudio<10.0' qubes-vm-gui: installing xorg-server (1.19.5-1) breaks dependency 'xorg-server<1.19.0' Is there any fix for that issue? I really like Archlinux on top of Qubes OS. Best regards J. Eppler -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/936e4600-5d65-488e-96d1-ae80f1dc41db%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: R3.2 Upgrading Fedora 25 --> 26 templates - PulseAudio issue
I would be interested in Fedora 26 or even better 27 in R3.2 as well. Best regards J. Eppler -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1ffacd57-8fc7-4604-a304-59d5fa099273%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: R3.2 Upgrading Fedora 25 --> 26 templates - PulseAudio issue
+1 if possible a rawhide repository too (for latest package updates -> security reason) On 11/05/2017 11:00 PM, J. Eppler wrote: > I would be interested in Fedora 26 or even better 27 in R3.2 as well. > > Best regards > J. Eppler > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/oto2gg%24o58%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Unable to Attach ISO to Windows HVM
I’m still going to try to fix this problem, because I heard that apparently Windows 10 installs and runs fine as an HVM on Qubes. However, inter-VM interaction doesn’t work. Has anyone here ever successfully installed and ran Windows 10 on Qubes 3.2? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e19e2edf-5cde-48b4-aa29-b02a6526bd94%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes 4.0 rc2 problem: domain labels broken
I tried install of Qubes 4.0 rc2 on multiple computers. I also "verified iso" from the Qubes installer menu after burning. The issue I am having is that unlike Qubes 3.2, Qubes 4.0 rc2 shows all domains as "domain" instead of differentiating between "Domain", "Template:", "ServiceVM:". Is this a bug? I am surprised no one else has reported this. Is this known issue? Or is this a feature? Why would you disguise a template VM as a AppVM that makes it easy to accidentally use a template instead of AppVM for general things such as web browsing? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f4c72eedcaef8f8f31612f0e03d947ab.squirrel%40_. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes 3.2 questions and issues.....
Hello, jumping from Windows directly to Qubes OS is a big step. Congrats for being able to make the step. > During installation I selected luks encryption, which works fine. But my ssd > is encrypted using the bios, so perhaps not using luks would give me better > battery life, and cpu performance? I am not sure how the BIOS is able to encrypt your SSD. However, when it comes to encryption I only trust Open Source and LUKS + dm-crypt is Open Source. The reason is that others or myself can verify if LUKS + dm-crypt is secure. Of course not everybody is an expert in cryptography, but there are some smart people who did or do the work for you (or us). Regarding performance, LUKS + dm-crypt in Qubes OS uses AES (Advanced Encryption Standard). CPUs have additional instructions to improve the performance of AES in hardware. See [AES-NI](https://en.wikipedia.org/wiki/AES_instruction_set) and [Intel® Advanced Encryption Standard (Intel® AES) Instructions Set - Rev 3.01](https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-aes-instructions-set/). Therefore, your CPU is very energy efficient in doing the encryption and decryption operations. In addition, AES is already optimized for modern desktop and embedded CPUs. Keep in mind that full disk encryption requires far less resources compared to displaying a window on your screen. > I did have trouble shutting qubes down. And, I found the best practice was to > shutdown all vms and system vms, first. That way I'm guaranteed a quick and > easy shutdown, without any issues. I do the same, because I run into the same issues. > The power manager on the taskbar occasionally crashes when being used, and I > have to go to 'system tools' and restart it. Interesting, I cannot confirm that behavior. It must be specific to your device. > Should I install the package inside a new and clean templatevm, then create > an appvm from that template? Or create a standalonevm from a clean template > and install package inside the appvm? I normally download the default templatevm and then create a clone which I modify. I then create AppVMs from the cloned/modified template. > Also, the qubes instructions says fedora minimal uses 300mb disk space, but > mine is currently using 1500mb. Which seems like a lot. Yes, 1500 is the smallest Fedora template. I don't know why 300mb are mentioned. I think it refers to the size of the template package. Regrading your other questions which I skipped. Have a look at: https://github.com/Jeeppler/qubes-cheatsheet Best regards J. Eppler -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/730a38bd-1a02-474d-b22b-5386c31e3d0b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: What do you guys think about the "OnlyKey"
NitroKey is another alternative: https://www.nitrokey.com/ NitroKey is a product from Germany. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/34c8ef32-56a7-4ba9-8a7b-93da11c33528%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Coreboot VS Libreboot :: Which is better for Qubes OS ?
On 11/04/2017 09:12 PM, 'Marek Jenkins' via qubes-users wrote: What is the difference between Coreboot and Libreboot ? Philosophy, that's it. Coreboot is sterile and corporate (as evidenced by not only the quiet acceptance of boards with closed source init but the removal of older open source boards from the tree, most people in the project and on the list work for intel/google/etc so any questioning of this is always shot down) Thanks for that info. From what I found, Librecore also seems to a fork of Coreboot, they only remove all the blobs. But my main concern are Intel AMT/ME/vPro - so in other words any remote access / backdoor, so I guess I could live with Coreboot. As I said there isn't any difference if you compile coreboot for a board supported by libreboot. I am going for the KGPE-D16 and it seems they really have put in a lot of effort to support it. Also Raptor Engineering seems to do a lot to make KGPE-D16 and coreboot work. I planned to go for a 62xx or 63xx CPU, but probably for a 62xx, because I read the 63xx series has a lot of issues with coreboot/libreboot and needs firmware / "microcode" updates to work properly - like you mentioned as well. 63xx/43xx is fine as long as you include a microcode update, you need to use coreboot for those but it will do it automatically by default. Do you know if not only the KCMA-D8 but also the KGPE-D16 is also fully supported ? Should be, right ? Sure is, they're pretty much the same thing. Thanks for your help! I just told Holger I probably would postpone the installation of Coreboot, because I have issues with compiling the ROM. As long as you have the prerequisites installed it should work with the default config. I know that I won't have problems with flashing the BIOS chip myself - my main problem is getting the settings right in the Coreboot config console (i am using "$ make nconfig" to compile). But I am overwhelmed by all the settings. E.g. which payload (Seabios, GRUB2,etc) to use and which other settings for the KGPE-D16 ? SeaBIOS for beginners, other then that you don't need to mess with anything the default settings are fine. So if that would be solved, I might definitely consider to use Coreboot in the near future. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/86e89b0b-75df-e4d7-c525-e84d3140d01f%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Mainboard buying advice :: Should we still avoid mainboards with Intel vPro ??
On 11/04/2017 09:36 PM, 'Marek Jenkins' via qubes-users wrote: Although an advantage of the KGPE-D16 is that it includes the $50 module needed to run OpenBMC - your choice. I looked it up, but I don't really understand the purpose of the OpenBMC module. Was it for TPE/AEM support ? It is for libre remote access and hardware fan control (instead of running fancontrol in linux) Usual retail: KGPE-D16 - $400 KCMA-D8 - $250-300 CPU: 4386 - $100-130 6386 - $100-200 Thanks for the overview. Do you by any chance know for sure, if the 6386 works with Coreboot ? Yeah it does. Because on the Coreboot website they advise to avoid the whole 63xx series, due to the "microcode update" issue. No that's what the libreboot site says, I maintain the kgpe-d16 article on the coreboot wiki and I would never state that. I initially also wanted to go for a 63xx CPU but due to their advise I thought about switching to 62xx to avoid all those problems. Maybe that can be solved ? Because the 63xx is only insignificantly more expensive than the 62xx CPUs... Get a 63xx/43xx, they're slightly faster. PS: I will also switch off Google very soon, I didn't know they were doing such advanced things in regards to tracking.. They are truly the worlds most powerful corporation, they are even putting cameras and mics around urban centers now to help with their AI research and of course advertising. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0224121d-13fa-f922-9185-35cd816b36c1%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: [qubes-devel] Qubes R3.2 - Severe graphics issues/glitches ? (HCL Report included)
On Fri, Nov 3, 2017 at 1:18 PM, 'Marek Jenkins' via qubes-users wrote: > >> > Hi Jean-Philippe, >> > >> > thanks for your advice. >> > >> > I have read the docs over here regarding kernel updates: >> > https://www.qubes-os.org/doc/software-update-dom0/ >> > >> > So should I simply run the following terminal commands in dom0 ? >> > >> > sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel >> > kernel-qubes-vm >> > >> > Also, do I need to enable / specify a repo (e.g. unstable, current-testing, >> > etc) or can I also use the command like this: >> > >> > sudo qubes-dom0-update kernel kernel-qubes-vm >> > >> > Thank you for your support ! >> > >> > PS: I posted this also in qubes-devel, because I thought this issue is >> > quite >> > difficult for normal users to solve. >> > Sorry about that, I have also posted my HCL Report in qubes-users and will >> > update there if I find a fix ! >> > >> > Best regards, >> > Marek >> >> just start with >> $ sudo qubes-dom0-update >> in dom0 and reboot >> >> only if that doesn't work then try -testing or -unstable repos. > > I just wanted to let you know that I upgraded the kernel and shortly after > the screen corruption happened again (green screen). This happened right > before I wanted to update the grub file. Now the system doesn't boot up > anymore but gets stuck. > > I think I need to reinstall everything. You might consider trying Qubes R4(-rc2). the system feels a bit different and isn't quite release-worthy yet IMO, but it has much newer hardware support and your graphics issues might be fixed. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CABQWM_DO3MtBzoNh9DC%3DJMg0voMdwuYW7Au2iGVVd_fPsXWObw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] riseup.net red
I wrote my experience with bitmask here: https://github.com/QubesOS/qubes-issues/issues/2021#issuecomment-294700472 Also in this list there is this topic: https://groups.google.com/forum/#!topic/qubes-users/dUgf68iiN4I -- iuri.neocities.org -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAF0bz4SoAj3j6c3JaHHGHmNurXv_unQ-roOVRC4E_65fCeqaUw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Configuration of selective, optional network interface in ProxyVM
On Qubes 3.2: * I have a network interface that I would like to expose to some ProxyVMs but not to others. * I would like all of these AppVMs to share the same Fedora-25 TemplateVM. * In TemplateVM, I created a symbolic link to interface configuration file: ln -s /rw/config/ifcfg-enp0s0 /etc/sysconfig/network-scripts/ifcfg-enp0s0 * In device-enabled ProxyVM, I added device via VM Settings, and manually added ifcfg-enp0s0 to /rw/config. * In device-disabled ProxyVM, I removed device via VM Settings, and left no configuration file in /rw/config. This setup works - but every device-disabled VM has a very long startup time because of the timeout caused by waiting for device response. Is there a better way to do this? Thanks. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/KyE_Nij--B-0%40tuta.io. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Mainboard buying advice :: Should we still avoid mainboards with Intel vPro ??
On Monday, 6 November 2017 02:09:32 UTC+1, tai...@gmx.com wrote: > On 11/04/2017 09:36 PM, 'Marek Jenkins' via qubes-users wrote: > > >> Although an advantage of the KGPE-D16 is that it includes the $50 module > >> needed to run OpenBMC - your choice. > > I looked it up, but I don't really understand the purpose of the OpenBMC > > module. Was it for TPE/AEM support ? > It is for libre remote access and hardware fan control (instead of > running fancontrol in linux) Thanks for the clarification! I probably won't really need the remote access feature, but hardware fan control is always good. Even better when libre. > > Do you by any chance know for sure, if the 6386 works with Coreboot ? > Yeah it does. > > Because on the Coreboot website they advise to avoid the whole 63xx series, > > due to the "microcode update" issue. > No that's what the libreboot site says, I maintain the kgpe-d16 article > on the coreboot wiki and I would never state that. Cool, I didn't expect that - great to get so much support first-hand :) Initially, my plan was also to get a 63xx CPU but then I stumbled on Libreboot's wiki, where they state one should "AVOID [the 63xx series] LIKE THE PLAGUE". Seemed a bit hysterical to me as well, but then again, I thought they know their stuff (no offence) :D (Source: https://libreboot.org/docs/hardware/kgpe-d16.html) I'm really glad the 63xx CPUs are also supported by Coreboot. I don't really mind about Libreboot' philosophical issues - if it works on Coreboot I'm happy. And now as I have checked the Coreboot Wiki page again I actually realized you openly state the 63xx series works fine ;) By the way, I also finally managed to compile the Coreboot .rom file yesterday, with the help of the wiki (https://www.coreboot.org/Build_HOWTO). It was just for testing purposes, and I didn't really change much during the setup. I simply chose the ASUS KGPE-D16 mainboard and compiled it as a i386 ROM (AMD chipset). Basically like this: 1. $ make menuconfig (ASUS KGPE-D16, PS/2 init, SeaBios) 2. $ make crossgcc-i386 CPUS=8 3. $ make Is that all it takes to compile the .rom correctly ? Does SeaBios work out-of-the-box with Qubes ? Also, would it be best to simply clone the latest working config for the KGPE-D16 from the Coreboot website (https://www.coreboot.org/Supported_Motherboards), which can be downloaded here for example: - https://review.coreboot.org/cgit/coreboot.git/commit/?id=3f09b0ffef990286ecca344cf73023b35be42406 - https://review.coreboot.org/cgit/board-status.git/tree/asus/kgpe-d16/4.6-1125-g3f09b0f/2017-08-21T04_40_02Z/config.txt Regarding Coreboot, IOMMU and security : On your wiki page it says "The 63xx "Piledriver" series processors require microcode updates to enable IOMMU (Errata) and may require microcode updates for safe operation due to the 2016 gain-root-via-NMI exploit." I found some details about the 63xx microcode security updates on the Debian mailing list, but I'm not really sure if the same manual update procedure applies to our use case (Qubes/Xen/Coreboot) since dom0 is based on Fedora. (Source: https://lists.debian.org/debian-user/2016/03/msg01044.html) Would you generally agree, that "Microcode update" is just a fancy name for fetching + installing a certain AMD package from a repository that patches the security vulnerability in the CPU? Or what is the approach I need to follow to enable IOMMU and fix the security vulnerability when running a 63xx CPU under Qubes/Xen? > Get a 63xx/43xx, they're slightly faster. Yes definitely. > > PS: I will also switch off Google very soon, I didn't know they were doing > > such advanced things in regards to tracking.. > They are truly the worlds most powerful corporation, they are even > putting cameras and mics around urban centers now to help with their AI > research and of course advertising. Yes it's really crazy and a bit alarming how much data they gather :/ That's also the main reason why I want to keep my browsing in different VMs (work, banking, music/streaming, etc). I mean know one knows, what they will really do with all the personal data in the future.. they sure sell the data or use it for advertising purposes. Besides that, the added security of Qubes against malware was another great thing that convinced me to switch. Best regards! Marek -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/eecb43ef-98ca-4dd3-9ca2-197ad58cec1f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Coreboot VS Libreboot :: Which is better for Qubes OS ?
> 63xx/43xx is fine as long as you include a microcode update, you need to > use coreboot for those but it will do it automatically by default. Is that only the case with Coreboot BIOS or also with the stock BIOS ? > > I just told Holger I probably would postpone the installation of Coreboot, > > because I have issues with compiling the ROM. > As long as you have the prerequisites installed it should work with the > default config. > > I know that I won't have problems with flashing the BIOS chip myself - my > > main problem is getting the settings right in the Coreboot config console > > (i am using "$ make nconfig" to compile). > > > > But I am overwhelmed by all the settings. E.g. which payload (Seabios, > > GRUB2,etc) to use and which other settings for the KGPE-D16 ? > SeaBIOS for beginners, other then that you don't need to mess with > anything the default settings are fine. > > So if that would be solved, I might definitely consider to use Coreboot in > > the near future. > > Hi, I just saw you pretty much answered all questions I had regarding Coreboot and its setup for KGPE-D16. I didn't see you already posted here at the time of writing my reply in the other thread. So in other words, you don't really need to go into great detail again in the other thread - I think I am good ! Maybe I get back to you in case I want to add any security features (AEM) to Coreboot. But for now, I will start to test it with basic settings. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d08e75bf-baf8-48d6-a2bc-897a6e0a6a2b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Mainboard buying advice :: Should we still avoid mainboards with Intel vPro ??
On 11/06/2017 12:42 AM, 'Marek Jenkins' via qubes-users wrote: On Monday, 6 November 2017 02:09:32 UTC+1, tai...@gmx.com wrote: On 11/04/2017 09:36 PM, 'Marek Jenkins' via qubes-users wrote: Although an advantage of the KGPE-D16 is that it includes the $50 module needed to run OpenBMC - your choice. I looked it up, but I don't really understand the purpose of the OpenBMC module. Was it for TPE/AEM support ? It is for libre remote access and hardware fan control (instead of running fancontrol in linux) Thanks for the clarification! I probably won't really need the remote access feature, but hardware fan control is always good. Even better when libre. Do you by any chance know for sure, if the 6386 works with Coreboot ? Yeah it does. Because on the Coreboot website they advise to avoid the whole 63xx series, due to the "microcode update" issue. No that's what the libreboot site says, I maintain the kgpe-d16 article on the coreboot wiki and I would never state that. Cool, I didn't expect that - great to get so much support first-hand :) Initially, my plan was also to get a 63xx CPU but then I stumbled on Libreboot's wiki, where they state one should "AVOID [the 63xx series] LIKE THE PLAGUE". Seemed a bit hysterical to me as well, but then again, I thought they know their stuff (no offence) :D (Source: https://libreboot.org/docs/hardware/kgpe-d16.html) I'm really glad the 63xx CPUs are also supported by Coreboot. I don't really mind about Libreboot' philosophical issues - if it works on Coreboot I'm happy. And now as I have checked the Coreboot Wiki page again I actually realized you openly state the 63xx series works fine ;) The FSF hard line stance is a good thing, which gets us stuff like TALOS 2/POWER9 which is 100% owner controlled including microcode (check it out) But in this case I say the faster cpu is worth it for video games. If you wanted a 62xx you could get a 6287SE which is almost as fast as a 6386SE, whereas the 6284SE is a tick slower. By the way, I also finally managed to compile the Coreboot .rom file yesterday, with the help of the wiki (https://www.coreboot.org/Build_HOWTO). It was just for testing purposes, and I didn't really change much during the setup. I simply chose the ASUS KGPE-D16 mainboard and compiled it as a i386 ROM (AMD chipset). Basically like this: 1. $ make menuconfig (ASUS KGPE-D16, PS/2 init, SeaBios) 2. $ make crossgcc-i386 CPUS=8 3. $ make Sounds ok. Is that all it takes to compile the .rom correctly ? Does SeaBios work out-of-the-box with Qubes ? Also, would it be best to simply clone the latest working config for the KGPE-D16 from the Coreboot website (https://www.coreboot.org/Supported_Motherboards), which can be downloaded here for example: - https://review.coreboot.org/cgit/coreboot.git/commit/?id=3f09b0ffef990286ecca344cf73023b35be42406 - https://review.coreboot.org/cgit/board-status.git/tree/asus/kgpe-d16/4.6-1125-g3f09b0f/2017-08-21T04_40_02Z/config.txt That should be what was included, no need to do that. Regarding Coreboot, IOMMU and security : On your wiki page it says "The 63xx "Piledriver" series processors require microcode updates to enable IOMMU (Errata) and may require microcode updates for safe operation due to the 2016 gain-root-via-NMI exploit." I found some details about the 63xx microcode security updates on the Debian mailing list, but I'm not really sure if the same manual update procedure applies to our use case (Qubes/Xen/Coreboot) since dom0 is based on Fedora. (Source: https://lists.debian.org/debian-user/2016/03/msg01044.html) Would you generally agree, that "Microcode update" is just a fancy name for fetching + installing a certain AMD package from a repository that patches the security vulnerability in the CPU? Or what is the approach I need to follow to enable IOMMU and fix the security vulnerability when running a 63xx CPU under Qubes/Xen? You need it in the firmware to enable IOMMU and avoid the NMI issue, by default coreboot includes it as I said so no worries. (check just to make sure of course) Get a 63xx/43xx, they're slightly faster. Yes definitely. PS: I will also switch off Google very soon, I didn't know they were doing such advanced things in regards to tracking.. They are truly the worlds most powerful corporation, they are even putting cameras and mics around urban centers now to help with their AI research and of course advertising. Yes it's really crazy and a bit alarming how much data they gather :/ That's also the main reason why I want to keep my browsing in different VMs (work, banking, music/streaming, etc). That doesn't do anything if you use an identical browser fingerprint. I mean know one knows, what they will really do with all the personal data in the future. Being denied a job because your politics differ from your bosses - removing 50% of job options. Having creepy people scan your face in public and then harrass you for whatever reas
Re: [qubes-users] Coreboot VS Libreboot :: Which is better for Qubes OS ?
On 11/06/2017 01:28 AM, 'Marek Jenkins' via qubes-users wrote: 63xx/43xx is fine as long as you include a microcode update, you need to use coreboot for those but it will do it automatically by default. Is that only the case with Coreboot BIOS or also with the stock BIOS ? Coreboot, not sure about the stock BIOS (it differs based on board revision) I just told Holger I probably would postpone the installation of Coreboot, because I have issues with compiling the ROM. As long as you have the prerequisites installed it should work with the default config. I know that I won't have problems with flashing the BIOS chip myself - my main problem is getting the settings right in the Coreboot config console (i am using "$ make nconfig" to compile). But I am overwhelmed by all the settings. E.g. which payload (Seabios, GRUB2,etc) to use and which other settings for the KGPE-D16 ? SeaBIOS for beginners, other then that you don't need to mess with anything the default settings are fine. So if that would be solved, I might definitely consider to use Coreboot in the near future. Hi, I just saw you pretty much answered all questions I had regarding Coreboot and its setup for KGPE-D16. I didn't see you already posted here at the time of writing my reply in the other thread. So in other words, you don't really need to go into great detail again in the other thread - I think I am good ! Maybe I get back to you in case I want to add any security features (AEM) to Coreboot. You would need to enable TPM support in menuconfig and buy a compatible TPM module. But for now, I will start to test it with basic settings. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c7a27204-4ed5-245c-5c88-136881acef77%40gmx.com. For more options, visit https://groups.google.com/d/optout.
