Re: [qubes-users] WWAN/LTE Card stopped working
On Sat, April 14, 2018 7:57 am, 799 wrote: > Hello, > > > I have applied Updates to my Templates and also flashed Coreboot ony > X230. > I haven't used my internal WWAN Card for a while as I was using WiFi. > The WWAN Card was working before (default template/Stock ROM) without a > problem, now it doesn't. > > I can pass the WWAN per sys-usb to my sys-net and I can see that it it > present there (lsusb). But I can't use Gnome Network Manager anymore to us > it. > > I have also tried to pass the whole PCI Controller which includes the > WWAN > Card as USB device to take sys-usb out of the equation, but I get the same > result. > > Do you have any idea where to start troubleshooting? This might be a coreboot item. I noticed on the T420 (I think it was), coreboot didn't support the WWAN slot. -- 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/48c3aafa009748d075c589118423a9ec.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Unable to resize VM Template disk size
On Saturday, April 14, 2018 at 8:33:22 PM UTC-4, awokd wrote: > On Sat, April 14, 2018 10:12 pm, chipperXXX wrote: > > Hello, > > I am fairly new to QUBES, as I have only just installed QUBES 4.0 and have > > been learning the OS. I initally installed QUBES 3.x (last RC), and > > immediately installed QUBES 4.0. I have had several problems. > > > > My motherboard is a supermicro X8DAL-3, (2) XEON L5638 with 48 Gb of RAM. > > 250GB SSD hard drive. > > > > > > I have attempted to run the command: qvm-volume extend personal:root > > 300 in the template VM Fedora-26. > > > > > > The error I receive is "Command not found" > > > > > > I've had similar errors when trying to install packages to the template > > VMs. > > > > > > Request some guidance in achieving success in re sizing disk space in the > > personal VM - > > > > Thank you in advance for any help / guidance. > > Right command, but maybe running it in the wrong place. See > https://www.qubes-os.org/doc/resize-disk-image/. You want to do those > qvm-volume commands from dom0 terminal with the VM/template shut down > instead of inside a template. You can also go to VM Settings on the VM you > want to resize and increase it using the GUI. Awokd, I followed your guidance, had one other minor issue (of my own doing) and was able to get past the hiccup. I really appreciate your assistance. Thank you - My goal is to become comfortable with QUBES and its functionality before implementing it completely. Baby steps. Next I will be working on installing software into the templates so it is available in the VMs. Then implementing a VPN, Then I will be creating a Windows 7 VM. Baby steps... Have a Great Day!! Chip -- 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/357a39c6-0ffd-4a91-908a-3a36a08f8eb0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Thinkpad X230T trackpoint and trackpoint buttons did not work on fresh Qubes R4.0
Just in case this might benefit someone else.
The installation of Qubes OS proceeded without any hiccups, and the Trackpoint
along with its hardware buttons actually worked during the installation.
But when Qubes OS itself started, the Trackpoint and its hardware buttons did
not respond. The mousepad still worked, although clicking required
hard-pressing ("touch"-clicking on the mousepad did not work).
Playing around with the "Mouse and Touchpad" settings in System Tools had no
effect.
I found a published work-around in a previous thread on this forum which has
fixed the trackpoint and its hardware buttons. But "touch"-clicking on the
mousepad is still an isue.
https://groups.google.com/d/msg/qubes-users/qmLogolyUdU/4D7vyINLBgAJ
Created the file /etc/X11/xorg.conf.d/11-trackpoint.conf with these contents:
Section "InputClass"
Identifier "trackpoint catchall"
MatchIsPointer "true"
MatchProduct "TrackPoint|DualPoint Stick"
MatchDevicePath "/dev/input/event*"
Option "Emulate3Buttons" "true"
Option "EmulateWheel" "true"
Option "EmulateWheelButton" "2"
Option "XAxisMapping" "6 7"
Option "YAxisMapping" "4 5"
EndSection
If anyone knows of a way to get the mousepad to also register touches, that
would be great.
--
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/aaa62d5c-cdd2-401d-b0de-25470d7d684c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Thinkpad X230T trackpoint and trackpoint buttons did not work on fresh Qubes R4.0
On Sunday, April 15, 2018 at 3:25:24 PM UTC+2, Taha Ahmed wrote:
> Just in case this might benefit someone else.
>
> The installation of Qubes OS proceeded without any hiccups, and the
> Trackpoint along with its hardware buttons actually worked during the
> installation.
>
> But when Qubes OS itself started, the Trackpoint and its hardware buttons did
> not respond. The mousepad still worked, although clicking required
> hard-pressing ("touch"-clicking on the mousepad did not work).
>
> Playing around with the "Mouse and Touchpad" settings in System Tools had no
> effect.
STRIKE THAT. Tapping to click actually works out of the box.
>
> I found a published work-around in a previous thread on this forum which has
> fixed the trackpoint and its hardware buttons. But "touch"-clicking on the
> mousepad is still an isue.
> https://groups.google.com/d/msg/qubes-users/qmLogolyUdU/4D7vyINLBgAJ
>
> Created the file /etc/X11/xorg.conf.d/11-trackpoint.conf with these contents:
>
> Section "InputClass"
> Identifier "trackpoint catchall"
> MatchIsPointer "true"
> MatchProduct "TrackPoint|DualPoint Stick"
> MatchDevicePath "/dev/input/event*"
> Option "Emulate3Buttons" "true"
> Option "EmulateWheel" "true"
> Option "EmulateWheelButton" "2"
> Option "XAxisMapping" "6 7"
> Option "YAxisMapping" "4 5"
> EndSection
>
> If anyone knows of a way to get the mousepad to also register touches, that
> would be great.
I was too fast to post. The mousepad "touch" to click operation works by simply
enabling it in Settings (I must have missed the second tab).
Issue solved then.
--
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/a2d5fcf9-f4a3-4ebd-b28f-cf627b0fd9db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] how to transfer 3.2 vpn vm to 4.0?
On 2018-04-15 10:07, Chris Laprise wrote: On 04/14/2018 10:03 PM, Stumpy wrote: I had a really hard time getting a vpnvm to work in 3.2 but finally got it and it more or less ran great for months. In one of the 4 RCs (3 I think) I was able to restore that vpnvm to 4.0 rc3. Now I can't seem to do that, and am really hoping there is some way I can at least back up (tar?) the settings/changes on the 3.2 vpnvm and restore (untar?) then on a 4.0 vm. Thoughts? Depends on how you setup the original VPN VM. If you used the Qubes VPN doc, you can try tar-ing the /rw/config folder and transfer the contents to the new proxyVM (to the same folder). When tar-ing, use sudo. OTOH, installing from scratch with Qubes-vpn-support is fairly easy: https://github.com/tasket/Qubes-vpn-support -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 Thanks! I will try tar'ing the config folder first, if no luck there will give the github option a try. Cheers -- 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/bc34a08bd3624b9ecc14b29b4094c049%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [Qubes 4.0] - How to adjust the disk storage space for Windows 7 HVM?
On Wednesday, April 11, 2018 at 4:44:11 AM UTC-7, awokd wrote: > On Wed, April 11, 2018 12:25 am, lsofxp via qubes-users wrote: > > On Tue, Apr 10, 2018 at 7:24 AM, 'awokd' via qubes-users > > >>> Did you increase "system max storage size" while the VM was off? Do > >>> that, then look in Disk Manager to see if you can extend. -- > > > >> Yep,yep... would have needed to restart in order for changes made to a > >> running VM to take effect, so I just did it (changed it to ~20 Mb, > >> which was safe, considering that I’d just created a second HVM and then > >> deleted it, testing against lack of space issues) during the first > >> shutdown/restart involved to a typical Windows install. It’s gotta be > >> something that the user can control, I just don’t know enough yet. > > So it is working now? > > >> Appreciate your help, awokd... on other threads, you’ve taught me a > >> lot... > > No problem, glad to help! Nope, still not working... Qube sera, sera... lsofxp! -- 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/d7b04124-ed02-48f6-b682-043284840cc5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] How can I build a domU kernel module?
How can I build a kernel module for an AppVM? I would like to write some simple kernel modules, but I cannot figure out how to build them. I get: make[1]: *** No rule to make target 'tools/objtool/objtool', needed by '/home/user/kernel/wierd.o'. Stop. make: *** [Makefile:1507: _module_/home/user/kernel] Error 2 make: Leaving directory '/usr/lib/modules/4.14.18-1.pvops.qubes.x86_64/build' make: *** [Makefile:5: default] Error 2 Makefile: obj-m := wierd.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) default: make $(MAKE) -c $(KDIR) SUBDIRS=$(PWD) help modules Adding sudo to the inner make command has no effect. -- 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/92691c41-9dca-6f31-aa6c-91cfb3930426%40gmail.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
[qubes-users] USB Device Question
I have the following setup: Qubes 3.2, xfce4 interface sys-usb I want to be able to connect my Android phone to a vm and rsync its contents. I can connect the phone and "qvm-usb -a" it to the VM, and it appears available under the File Manager application as "mtp://[usb:002,004]/" but I cannot locate a mount point to use for rsync. It does not appear under /run/user/[uid]/gvfs. Any idea where it mounts so I can use rsync to reference it? Thanks in advance... Stuart -- 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/20180415153420.3eb2a6fc%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes VM Hardening v0.8.2 Released!
Leverage Qubes template non-persistence to fend off malware. Lock-down, quarantine and check contents of /rw private storage that affect the VM execution environment. vm-boot-protect.service: * Acts at VM startup before private volume /rw mounts * User: Protect /home desktop & shell startup executables * Root: Quarantine all /rw configs & scripts, with whitelisting * Re-deploy custom or default files to /rw on each boot * SHA256 hash checking against unwanted changes * Provides rescue shell on error or request * Works with template-based AppVMs, sys-net and sys-vpn Also included is the 'configure-sudo-prompt' tool which restores authorization for sudo on Debian. vm-boot-protect isn't effective with "passwordless sudo" Qubes default -- this tool restores VM internal security using a dom0 yes/no prompt in place of passwords. Project link: https://github.com/tasket/Qubes-VM-hardening -- 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/8f5524fd-2dc3-ccda-c864-fa80c50c37b3%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes VM Hardening v0.8.2 Released!
On 04/15/2018 03:51 PM, Chris Laprise wrote: Project link: https://github.com/tasket/Qubes-VM-hardening TL;dr : This closes the obvious loopholes that malware can use in Qubes AppVMs to escalate privileges, impersonal real apps (to steal credentials), and persist after shutdown/restart. VMs' own internal security has a chance to work and even shake-off rootkits and other malware when VMs are restarted or the template receives security updates. -- 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/97a0b9aa-f97e-e008-c650-31742efd5348%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes VM Hardening v0.8.2 Released!
On 2018-04-16 01:05, Chris Laprise wrote: On 04/15/2018 03:51 PM, Chris Laprise wrote: Project link: https://github.com/tasket/Qubes-VM-hardening TL;dr : This closes the obvious loopholes that malware can use in Qubes AppVMs to escalate privileges, impersonal real apps (to steal credentials), and persist after shutdown/restart. VMs' own internal security has a chance to work and even shake-off rootkits and other malware when VMs are restarted or the template receives security updates. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 Awesome! Can't wait till I have some time to try this out. Thanks Chris!!! -- 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/24460ed9cbee3be985c4470636a31956%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes VM Hardening v0.8.2 Released!
On 04/15/2018 04:05 PM, Chris Laprise wrote: On 04/15/2018 03:51 PM, Chris Laprise wrote: Project link: https://github.com/tasket/Qubes-VM-hardening TL;dr : This closes the obvious loopholes that malware can use in Qubes AppVMs to escalate privileges, _impersonate_ real apps (to steal credentials), and persist after shutdown/restart. ^FIXED :) VMs' own internal security has a chance to work and even shake-off rootkits and other malware when VMs are restarted or the template receives security updates. -- 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/f4fd3621-47dd-af94-e20a-777ebae504c4%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Shaving N seconds off VM startup
On 04/13/18 07:19, Chris Laprise wrote: I've done some experimenting to get my Debian VMs to boot faster. So far I've reduced the start time significantly by disabling these services in the template: apt-daily.service apt-daily.timer apt-daily-upgrade.service apt-daily-upgrade.timer pppd-dns lvm2-monitor Disabling the last two may have consequences, e.g. if you use VMs to access LVM storage. But that lvm2-monitor does consume a whopping 4+ seconds according to systemd-analyze. YMMV. And note that my criteria for picking these is just a cursory glance at unit start times. Ultimately, a good solution may be getting some of these units to start 10-20 seconds later. I think that makes sense in the case of lvm2-monitor. Some other time-consuming services like qubes-update-check already start later and don't seem to impact VM start times and responsiveness. FWIW, Ubuntu has announced that boot times have worsened a lot and they'll make an effort to reduce them (again). Not sure to what extent that reflects on Debian. Could be my imagination but in my ASRock Z170 UEFI (as another post on qubes-user suggested) *turning off the Intel speed stepping seems to have fixed everything: (I've no idea pros and cons of what this feature is; though I seem to have a EFI install, I turned back some sub-settings in the UEFI EFI choices to "legacy", no idea what those were/are either) boot time, Fed-26 VM starts , qvm-run etc; Issue I seem to have is qvm-shutdown often completes and has failed (maybe there is a timeout for shutdown as well as start-up ?); so I'm having to qvm-kill most/many of the AppVMs .. :) -- 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/f8101787-a32a-e5e3-c35a-99aa39a02764%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [Qubes 4.0] - How to adjust the disk storage space for Windows 7 HVM?
On Sun, April 15, 2018 5:41 pm, lso...@gmail.com wrote: > On Wednesday, April 11, 2018 at 4:44:11 AM UTC-7, awokd wrote: > >> On Wed, April 11, 2018 12:25 am, lsofxp via qubes-users wrote: >> >>> On Tue, Apr 10, 2018 at 7:24 AM, 'awokd' via qubes-users >>> >> > Did you increase "system max storage size" while the VM was off? > Do > that, then look in Disk Manager to see if you can extend. -- > Nope, still not working... Qube sera, sera... At which step?: 1- shutdown win 7 2- increase root size to 20GB 3- start win 7 4- review in disk manager -- 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/165b566f5b9619211b1cc3d78c57a8cf.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How can I build a domU kernel module?
On Sun, April 15, 2018 6:36 pm, Demi M. Obenour wrote: > How can I build a kernel module for an AppVM? I would like to write > some simple kernel modules, but I cannot figure out how to build them. I > get: > > > make[1]: *** No rule to make target 'tools/objtool/objtool', needed by > '/home/user/kernel/wierd.o'. Stop. Try doing a full kernel build first. There's probably a more elegant solution. -- 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/8acf55ca9fa1bfbfa9b36ab67133ff25.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Errors on booting 4.0 and time is off? Otherwise working great!
I am getting ACPI errors when I boot, everything works, or at least I haven't seen a functionaility issue. I am however concerned and trying to understand implications from a functonal and security perspective. The errors are: [ 1.] ACPI Error: [\_PR_.CPU0._CST] Namespace lookup failure, AE_NOT_FOUND (###/pspargs-364) [ 1.] ACPI Error: Method parse/execution failed \_PR_.CPU3._CST] , AE_NOT_FOUND (###/psparse-550) [ 1.] ACPI Error: Method parse/execution failed \_PR_.CPU._CST] , AE_NOT_FOUND (###/psparse-550) Not sure this is related but my time is off by 5 hours in Qubes. My BIOS time is set correctlyalways seems to be 5 hour difference. My functionaility seems to be great Any thoughts on how I can get rid of the errors or if I should be worried about the errors? Thank you again -- 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/1ef594d2-37ad-4116-a78a-7785b66fd877%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Errors on booting 4.0 and time is off? Otherwise working great!
On Sun, April 15, 2018 10:24 pm, vel...@tutamail.com wrote: > I am getting ACPI errors when I boot, everything works, or at least I > haven't seen a functionaility issue. I see some as well, with no obvious impact. > Not sure this is related but my time is off by 5 hours in Qubes. My BIOS > time is set correctlyalways seems to be 5 hour difference. Assuming you set your timezone correctly when you installed Qubes, this is because it assumes the hardware clock is in UTC. So if you or another OS is changing it to local time, that will make Qubes seem like it's off. > Any thoughts on how I can get rid of the errors or if I should be worried > about the errors? Not sure either, but doesn't seem to hurt anything as far as I can tell! -- 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/6bb27f0b7dc9c703bb3bf92b8c3092a7.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes VM Hardening v0.8.2 Released!
On Sun, April 15, 2018 8:41 pm, Chris Laprise wrote: > On 04/15/2018 04:05 PM, Chris Laprise wrote: > >> On 04/15/2018 03:51 PM, Chris Laprise wrote: >> >>> Project link: https://github.com/tasket/Qubes-VM-hardening >>> >> >> TL;dr : This closes the obvious loopholes that malware can use in Qubes >> AppVMs to escalate privileges, _impersonate_ real apps (to steal >> credentials), and persist after shutdown/restart. > > ^FIXED :) > > >> >> VMs' own internal security has a chance to work and even shake-off >> rootkits and other malware when VMs are restarted or the template >> receives security updates. Thanks, tasket! -- 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/e0fb6f8b28e55bbde18824f44c1a57a9.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] The best compromise for a Laptop (Balance security with reality of implementation)?
I am exploring the best Qubes laptop based on the following criteria: 1) Secure/Privacy 2) Usability and maintenance for the layman in need of security 3) Price 4) New laptop Based on my research the most secure would be: Older laptops: G505 x220 T420 W520/W530 Pro: -price/value -Coreboot Cons: -only available as used/refurbished For a new, currently available on the market(a positive HCL report just came up): Lenovo - T480 I am sure other Lenovo work well...my experience has been good. Other products I have looked at include: Carbon 5/Developers - Recalled...potentially good in the future refurbished market. Huge value in the fact the Qubes developers use this laptop. A little expensive Purism - Libre or coreboot? with proprietery software in BIOs System 76 - Gaming PC primarily Thinpenguin - Libre or coreboot? with proprietery software in BIOs, manufacturer unsure of 4.0 compatability Talos2 - expensive(desktop only?) My specific questions are: 1) A lot of custom gaming laptop makers in the USA...any companies flashing Coreboot or Libre on new or refurbished laptops commercially for Linux? 2) My wish list would be able to crack open a laptop and flash coreboot(orLibre) but I am concerned this is just too techy. Is it hard to do? Is it hard to maintain? Hard to repeat? 3) How risky are the proprietery BIOS? Is this Nation state, Lenovo threats only? While I like my privacy I likely have bigger issues if they want access. How risky are "stock" BIOs from say a Lenovo...realistically/practically speaking. 4) Is Qubes still better then a Mac or PC even with proprietery BIOS? I am an open source purist(wannabe) but I need to balance usability/practicality. I am trying to understand and quantify the benefit of OSS BIOS and the security benefit balanced with ease of maintaining/implementing. While its frustrating the hardware compatability challenges, I like the hard stance Qubes makes on hardware "certification" Any feedback or dialogue is welcome. (PS Thanks for the forum members for prior posts and helping with the info above) -- 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/118c3bcc-88c2-40a3-bfc5-902718a2636c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] The best compromise for a Laptop (Balance security with reality of implementation)?
On Sun, April 15, 2018 11:01 pm, vel...@tutamail.com wrote: > I am exploring the best Qubes laptop based on the following criteria: > > > 1) Secure/Privacy > 2) Usability and maintenance for the layman in need of security > 3) Price > 4) New laptop I wrote a selection guide here: https://github.com/Qubes-Community/Contents/blob/master/docs/hardware/hardware-selection.md It might be a biased example of the logic that led me to choosing G505s, but the links in there could help you make up your own mind too. > Purism - Libre or coreboot? with proprietery software in BIOs > > > System 76 - Gaming PC primarily > > > Thinpenguin - Libre or coreboot? with proprietery software in BIOs, > manufacturer unsure of 4.0 compatability If I was forced to buy something new for Qubes, I'd look at the above. Search this mailing list (and HCL) for reports, though. > Talos2 - expensive(desktop only?) Great hardware but not compatible with Qubes yet. > My specific questions are: > 1) A lot of custom gaming laptop makers in the USA...any companies > flashing Coreboot or Libre on new or refurbished laptops commercially for > Linux? > 2) My wish list would be able to crack open a laptop and flash > coreboot(orLibre) but I am concerned this is just too techy. Is it hard > to do? Is it hard to maintain? Hard to repeat? It's hard to do the first time, and some motherboard designs even need you to desolder the flash chip in order to accomplish it (G505s doesn't). Once you get core/libreboot on there, you can reflash updated versions using the internal flasher so you don't have to open it up any more. 3) How risky are the > proprietery BIOS? Is this Nation state, Lenovo threats only? While I like > my privacy I likely have bigger issues if they want access. How risky are > "stock" BIOs from say a Lenovo...realistically/practically speaking. Judgement call; I enjoy seeing how secure I can make my systems while still being usable, but have no reason to suspect a targeted nation-state attack (unless they are targeting everyone running Qubes in which case they need their budget reduced to help them focus on real threats...) > 4) Is Qubes still better then a Mac or PC even with proprietery BIOS? Of course! -- 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/8ab589c3ad25b126cf0599b3ab392439.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] 4.0 not updating dom0 nor fedora?
One small caveat, whonix-ws updated, everything else says there are no updates? While this is possible I am thinking its unlikely? I tried to update dom0 from the terminal sudo qubes-dom0-update and got /usr/lib/qubes/qubes-rpc-multiplexer: 14: /etc/profile.d/20_power_savings_disable_in_vms.sh shopt: not found /usr/lib/qubes/qubes-rpc-multiplexer: 14: /etc/profile.d/20_power_savings_disable_in_vms.sh shopt: not found No new updates available No updates available For what its worth, none of them, not even whonix-ws would update until I set whonix-gw as the NetVMs, even though I had selected the option for appvms to update via tor. I did open a terminal for each template and managed to do updates using apt-get for debian and whonix but not for fedora nor dom0, and not via the qubes manager "update qube" option For fedora it gave the error Error: Failed to synchronize cache for repo qubes-vm-r4.0-current Thoughts? -- 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/d90024f50dea8584f2fa5819f7a2140b%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Q4 Laptops...
"Their objective is good." Talking about Purism here, not Intel :) Le dim. 15 avr. 2018 08:52, Thierry Laurion a écrit : > To Taiidan and all others complaining about Purism lies and consumer being > misled. > > I keep reading stuff about purism lying about deactivating/disabling ME > being impossible, lying about the future of Intel removing ME, etc. I think > THIS is misleading. > > First, its me_cleaner job to do the cleaning. > The ME hack itself won't remove ME, but can remove modules by stripping > them. There is a big semantic difference between the words removing, > disabling and deactivating, I agree. Me_cleaner won't remove ME, that is > true. But all this ranting is not factual. > > See here: > https://github.com/corna/me_cleaner/wiki/HAP-AltMeDisable-bit > > From > https://github.com/corna/me_cleaner/blob/master/README.md: > > "For pre-Skylake firmware (ME version < 11) this tool removes almost > everything, leaving only the two fundamental modules needed for the correct > boot, ROMP and BUP. The code size is reduced from 1.5 MB (non-AMT firmware) > or 5 MB (AMT firmware) to ~90 kB of compressed code. > > Starting from Skylake (ME version >= 11) the ME subsystem and the firmware > structure have changed, requiring substantial changes in me_cleaner. The > fundamental modules required for the correct boot are now four (rbe, > kernel, syslib and bup) and the minimum code size is ~300 kB of compressed > code (from the 2 MB of the non-AMT firmware and the 7 MB of the AMT one)." > > To have Intel without ME ( but also without vt-d2, meaning no IOMMU) one > will need to choose old hardware, like the x200, which will not have more > then 8gb ram and won't support hardware isolation, so no real advantage of > using Qubes. > > x230 and x220 and others will boot with deactivated ME, booting with ROMP > and BUP present, true, but without kernel and no other modules. > > The rest of what you say, I agree. But oversimplifying things doesn't > fulfill the goal of making people aware of what is needed now and in the > future. Maybe Intel will change their way of fusing keys into the CPU when > they realise a lot of money is going out of their pocket to privacy > defending manufacturers. Maybe not. Time only will let us know. Their > objective is good. They might now success against Goliath, but really > trying their best for actual possibilities. ( IOMMU, minimal ME footprint, > disabling ME the same way it is done for three letters agencies laptops). > > > Until brand new laptops can fulfill IOMMU needs for certain threat models, > there is few alternatives now. > > Tl;dr: > Used laptops: > Having IOMMU without ME/PSP (Qubes): Lenovo g505s. > Removed ME, without IOMMU: x200. > Disabled ME with IOMMU (Qubes): x230/x220. > > New laptops: > Deactivated ME, with IOMMU (Qubes): Purism Librems. > > Desktop/Servers: > Used: > With IOMMU (Qubes), no ME/PSP: kgpe-d16, kcma-d8 > New: > With IOMMU (no Qubes): Talos II. > > Let's start a real debate aimed at improving stuff and building proper > arguments. > Pressure against manufacturers will build with market laws, and energy > should be put where things can evolve in the meantime. > > For my part, I wouldn't recommend using a x200 other then for amnesic > laptops. > G505s are not powerful and tough enough to run Qubes as a daily driver. > > ME is a really nasty piece of shit to deal with, agreed. But things needs > to move forward. Hiding in a cave waiting for things to magically happen is > not enough. > > Thierry > > > > > Le mer. 11 avr. 2018 16:57, taii...@gmx.com a écrit : > >> On 04/11/2018 03:14 AM, Drew White wrote: >> >> > On Wednesday, 11 April 2018 16:55:48 UTC+10, tai...@gmx.com wrote: >> >> What you ask for is impossible, it simply isn't made - no one has a >> >> laptop with 64GB RAM and 12 threads let alone one that is old enough to >> >> not have UEFI. >> > I know that they exist, and I would have one if I had enough money. But >> they do exist. As for UEFI (Microsofts shit invention) if I can disable it >> or else just replace it with an actual REAL BIOS, then I will. >> You can't do that unless the computer supports coreboot and the new >> stuff doesn't. >> >> The best you will get is a W520 or W530 where you can install coreboot >> >> (open hw init + nerfed ME) and have 32GB RAM. >> > Can the CPU be upgraded in those though? >> Yeah its socketed. >> >> I suggest buying a W520 and installing the best ivybridge CPU you can, >> then you get the better non-chiclet keyboard and it is also better >> supported in coreboot the port for the W530 was never upstreamed. >> >> Purism is not libre - their "open source firmware" has hardware >> >> initiation done entirely via binary blobs and their ME is certainly not >> >> disabled as the kernel still runs along with any hypothetical backdoor. >> >> Their marketing is incredibly dishonest and I simply don't understand >> >> why they get so much air time. >> > lol, then the only way I can get around it is to d
Re: [qubes-users] Q4 Laptops...
To Taiidan and all others complaining about Purism lies and consumer being misled. I keep reading stuff about purism lying about deactivating/disabling ME being impossible, lying about the future of Intel removing ME, etc. I think THIS is misleading. First, its me_cleaner job to do the cleaning. The ME hack itself won't remove ME, but can remove modules by stripping them. There is a big semantic difference between the words removing, disabling and deactivating, I agree. Me_cleaner won't remove ME, that is true. But all this ranting is not factual. See here: https://github.com/corna/me_cleaner/wiki/HAP-AltMeDisable-bit From https://github.com/corna/me_cleaner/blob/master/README.md: "For pre-Skylake firmware (ME version < 11) this tool removes almost everything, leaving only the two fundamental modules needed for the correct boot, ROMP and BUP. The code size is reduced from 1.5 MB (non-AMT firmware) or 5 MB (AMT firmware) to ~90 kB of compressed code. Starting from Skylake (ME version >= 11) the ME subsystem and the firmware structure have changed, requiring substantial changes in me_cleaner. The fundamental modules required for the correct boot are now four (rbe, kernel, syslib and bup) and the minimum code size is ~300 kB of compressed code (from the 2 MB of the non-AMT firmware and the 7 MB of the AMT one)." To have Intel without ME ( but also without vt-d2, meaning no IOMMU) one will need to choose old hardware, like the x200, which will not have more then 8gb ram and won't support hardware isolation, so no real advantage of using Qubes. x230 and x220 and others will boot with deactivated ME, booting with ROMP and BUP present, true, but without kernel and no other modules. The rest of what you say, I agree. But oversimplifying things doesn't fulfill the goal of making people aware of what is needed now and in the future. Maybe Intel will change their way of fusing keys into the CPU when they realise a lot of money is going out of their pocket to privacy defending manufacturers. Maybe not. Time only will let us know. Their objective is good. They might now success against Goliath, but really trying their best for actual possibilities. ( IOMMU, minimal ME footprint, disabling ME the same way it is done for three letters agencies laptops). Until brand new laptops can fulfill IOMMU needs for certain threat models, there is few alternatives now. Tl;dr: Used laptops: Having IOMMU without ME/PSP (Qubes): Lenovo g505s. Removed ME, without IOMMU: x200. Disabled ME with IOMMU (Qubes): x230/x220. New laptops: Deactivated ME, with IOMMU (Qubes): Purism Librems. Desktop/Servers: Used: With IOMMU (Qubes), no ME/PSP: kgpe-d16, kcma-d8 New: With IOMMU (no Qubes): Talos II. Let's start a real debate aimed at improving stuff and building proper arguments. Pressure against manufacturers will build with market laws, and energy should be put where things can evolve in the meantime. For my part, I wouldn't recommend using a x200 other then for amnesic laptops. G505s are not powerful and tough enough to run Qubes as a daily driver. ME is a really nasty piece of shit to deal with, agreed. But things needs to move forward. Hiding in a cave waiting for things to magically happen is not enough. Thierry Le mer. 11 avr. 2018 16:57, taii...@gmx.com a écrit : > On 04/11/2018 03:14 AM, Drew White wrote: > > > On Wednesday, 11 April 2018 16:55:48 UTC+10, tai...@gmx.com wrote: > >> What you ask for is impossible, it simply isn't made - no one has a > >> laptop with 64GB RAM and 12 threads let alone one that is old enough to > >> not have UEFI. > > I know that they exist, and I would have one if I had enough money. But > they do exist. As for UEFI (Microsofts shit invention) if I can disable it > or else just replace it with an actual REAL BIOS, then I will. > You can't do that unless the computer supports coreboot and the new > stuff doesn't. > >> The best you will get is a W520 or W530 where you can install coreboot > >> (open hw init + nerfed ME) and have 32GB RAM. > > Can the CPU be upgraded in those though? > Yeah its socketed. > > I suggest buying a W520 and installing the best ivybridge CPU you can, > then you get the better non-chiclet keyboard and it is also better > supported in coreboot the port for the W530 was never upstreamed. > >> Purism is not libre - their "open source firmware" has hardware > >> initiation done entirely via binary blobs and their ME is certainly not > >> disabled as the kernel still runs along with any hypothetical backdoor. > >> Their marketing is incredibly dishonest and I simply don't understand > >> why they get so much air time. > > lol, then the only way I can get around it is to disable it myself by > editing the CPU firmware? Or is there something else that controls that? > (I'll have to look into it.) > Disabling ME/PSP is impossible, it simply can't be done without > intervention from intel/amd. > The puridiots claim they will eventually be able to convince intel to do
