date:20180113

No expert, but try:

sudo yum remove qubes-template-whonix-ws

then

sudo qubes-dom0-update --enablerepo=qubes-templates-community \
   qubes-template-whonix-ws

You might have tried this but I had to do the whonix reinstall myself

Source:
https://www.qubes-os.org/doc/templates/
https://www.qubes-os.org/doc/remove-vm-manually/
https://www.qubes-os.org/doc/reinstall-template/

I hope this helps you...

V

-- 
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/c764184a-bca2-49f4-8cd1-e0c013dd75fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: how to reinstall template? (i think it's not enabled by repo)

2018-01-13 Thread Kevin Martinsen

Do you just want a fresh copy of whonix? If so I would recommend deleting the 
old copy (qvm-remove) and then installing it 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/90938638-87b5-4927-bf59-221f44ca27e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Just installed AEM(Anti-Evil-Made)...see an error:(

I have been running Qubes for a few months now, numerous 3.2 installs, most 
recent install was a month or so ago on the the same PC.

I just installed AEM for the first time.

Everything still works, however in my BIOS I had "enabled" the ability to see 
notes/alerts during boot.

Before I enabled AEM, I hadn't seen an error, however after enabling AEM I now 
see the following error during booting:

"[   6.387306] tpm tpm0: A TPM error (6) occurred attempting to read a pcr 
value"

It boots and everything is working so far as I can see.

Is this a concern I should be worried about?

Thanks
V

-- 
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/f62c5c15-059c-437f-bad1-df12d7afa3b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Basic setup verification tests for correct setup? VT-d? Other?

Thank you awokd and Yethal...learned a lot!

-- 
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/b7c9d444-1857-4ab1-be46-d5baffd83ba3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] how to reinstall template? (i think it's not enabled by repo)

2018-01-13 Thread jerry57

the template is whonix-ws
when running command
sudo qubes-dom0-update --action=reinstall qubes-template-package-name

it says no support for --downloadonly
only 'install' and 'upgrade'

i tried replacing reinstall with upgrade, says usage: yumdownloader, etc..

what do i write in command
sudo qubes-dom0-update --enablerepo=qubes-templates-community 
--action=reinstall qubes-template-whonix-ws

do i replace templates-community with something else?

-- 
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/ee742cfe3423e741894e02a6a2f77d53%40disroot.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

2018-01-13 Thread Doug M

On Saturday, January 13, 2018 at 10:50:11 AM UTC-8, Vít Šesták wrote:
> I have one more idea: The Vixen patch could be useful for VMs with PCI 
> devices. Memory balooning is not supported there anyway. QEMU in dom0 looks 
> ugly, but this case is a bit different: AFAIU, the attacker can directly talk 
> to QEMU if and only if she has escaped from PV. Maybe it is not nice, but it 
> is not that bad either.
> 
> With Qubes 3.2, I believe this can be a clean win. Compared to the proposal 
> (focusing on VMs with PCI devices only):
> 
> * It fixes the Meltdown. The proposal does not address it for those VMs.
> * Attacker can try to break out from both PV and then from HVM or (more 
> likely) from PV and then pwn QEMU. This is arguably harder than breaking 
> directly from PV.
> 
> With Qubes 4.0 (still focusing on VMs with PCI devices only), it is still 
> probably an improvement:
> * If attacker can pwn QEMU (but not PV), she can with the current proposal 
> read the whole memory using Meltdown. With Vixen, QEMU vulnerability is 
> probably not enough for Meltdown.
> * If attacker can escape from PV (but not QEMU), she can do pretty nothing. 
> Well, with Vixen, she can read the content of the container, but I don't 
> think this is a serious issue.
> * If attacker can both escape from PV and attack QEMU, you are doomed in 
> either case.
> * Theoretically: If attacker can escape from HVM, you are better protected 
> with Vixen (because attacker needs to escape from PV first).
> * If there are some vulnerabilities that do not allow full VM escape, you are 
> probably still better protected with Vixen. Qemu in dom0 runs as an ordinary 
> process (so attacks like buffer overread have quite limited impact) and it is 
> the same case for PV.
> 
> Have I missed something?
> 
> I don't say that Qubes should go this way. Maybe there are better ways to 
> achieve some goals (especially for 4.0+). I am just saying that QEMU in dom0 
> – however horrible it looks – might be acceptable in this special case.
> 
> Regards,
> Vít Šesták 'v6ak'

Would using a 32-bit PV provide any additional protection for Xen?

-- 
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/19b6e545-01ba-4851-be9e-3361341a0ae2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: No more boot after update

Le samedi 13 janvier 2018 20:10:39 UTC+1, Bertrand Lec a écrit :
> Le samedi 13 janvier 2018 19:44:54 UTC+1, cooloutac a écrit :
> > On Saturday, January 13, 2018 at 1:37:57 PM UTC-5, Bertrand Lec wrote:
> > > Hello,
> > > 
> > > I'm fresh installing Qubes R3.2 on my desktop PC, aside from Ubuntu.
> > > The PC is configured with UEFI. 
> > > 
> > > The installation goes well. At that time, I can reboot directly to Qubes.
> > > 
> > > However, after I update dom0, Qubes refuse to reboot. The boot is done to 
> > > Ubuntu. Even when I choose to boot Qubes in the BIOS, Ubuntu will boot.
> > > 
> > > Result of efibootmgr command is:
> > > BootCurrent: 
> > > Timeout: 1 seconds
> > > BootOrder: 0002,,0005,0001,0007
> > > Boot* ubuntu
> > > Boot0001* Hard Drive
> > > Boot0002* Qubes
> > > Boot0005* CD/DVD Drive
> > > Boot0007* Removable Drive
> > > 
> > > From my understanding, it says that Qubes is the first one to be booted 
> > > but the currently booted is ubuntu (which is true :) )
> > > 
> > > Do you have any idea for me?
> > > 
> > > Thanks
> > > Bertrand
> > 
> > you have to add qubes to the ubuntu grub.
> 
> With the way the BIOS is configured, it should only boot Qubes, and it's what 
> it did with several reboots done before the dom0 upgrade. 
> 
> By the way, I have just seen that there is no *cfg file in Qubes' /boot. Is 
> it normal...?
> 
> However, if a modification of Ubuntu's grub could be the solution, I'll take 
> it, but I don't see what I could put there.
> 
> Bertrand


Some additional information:
When the system boots, I can see those three lines at the top of the black 
screen:
-
Xen 4.6.6 (c/s ) EFI loader
Using configuration file 'xen.cfg'
vmlinuz-4.9.56-21.pvops.qubes.x86_64: 0x0-0x000...
-
The hexa numbers at the end of the last line were long and it was not really 
possible to read them.
Just a few milisecond after this is displayed, either the system gets back to 
the BIOS or boots Ubuntu, depending on how I was booting.

Hope this will give you some ideas...

Bertrand

-- 
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/a63b0b17-fd2e-47b1-8cc5-9d6c55223246%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: No more boot after update

Le samedi 13 janvier 2018 20:10:39 UTC+1, Bertrand Lec a écrit :
> Le samedi 13 janvier 2018 19:44:54 UTC+1, cooloutac a écrit :
> > On Saturday, January 13, 2018 at 1:37:57 PM UTC-5, Bertrand Lec wrote:
> > > Hello,
> > > 
> > > I'm fresh installing Qubes R3.2 on my desktop PC, aside from Ubuntu.
> > > The PC is configured with UEFI. 
> > > 
> > > The installation goes well. At that time, I can reboot directly to Qubes.
> > > 
> > > However, after I update dom0, Qubes refuse to reboot. The boot is done to 
> > > Ubuntu. Even when I choose to boot Qubes in the BIOS, Ubuntu will boot.
> > > 
> > > Result of efibootmgr command is:
> > > BootCurrent: 
> > > Timeout: 1 seconds
> > > BootOrder: 0002,,0005,0001,0007
> > > Boot* ubuntu
> > > Boot0001* Hard Drive
> > > Boot0002* Qubes
> > > Boot0005* CD/DVD Drive
> > > Boot0007* Removable Drive
> > > 
> > > From my understanding, it says that Qubes is the first one to be booted 
> > > but the currently booted is ubuntu (which is true :) )
> > > 
> > > Do you have any idea for me?
> > > 
> > > Thanks
> > > Bertrand
> > 
> > you have to add qubes to the ubuntu grub.
> 
> With the way the BIOS is configured, it should only boot Qubes, and it's what 
> it did with several reboots done before the dom0 upgrade. 
> 
> By the way, I have just seen that there is no *cfg file in Qubes' /boot. Is 
> it normal...?
> 
> However, if a modification of Ubuntu's grub could be the solution, I'll take 
> it, but I don't see what I could put there.
> 
> Bertrand


Some additional information:
When the system tries to boot, I can see 3 lines written at the top of the 
black screen:

-- 
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/e77c11a8-a7bb-4bc4-a25b-cf81aa985c3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Basic setup verification tests for correct setup? VT-d? Other?

2018-01-13 Thread 'awokd' via qubes-users

On Sat, January 13, 2018 8:32 pm, vel...@tutamail.com wrote:
> Thank you, a lot quicker results...the results were:
>
>
> XEN Intel VT-d iommu 0 supported page sizes: 4kB
> XEN Intel VT-d iommu 1 supported page sizes: 4kB
> XEN Intel VT-d Snoop Control not enabled
> XEN Intel VT-d Dom0 DMA Passthrough not enabled
> XEN Intel VT-d Queued Invalidation enabled
> XEN Intel VT-d Interrupt Remapping enabled
> XEN Intel VT-d Shared EPT tables not enabled
>
>
> Does this mean my VT-d functionality is working?

Yes, and from your original message,

>> HVM: Active
>> I/O MMU: Active
>> HAP/SLAT: Yes
>> TPM: Device present
>> Remapping: Yes

These are all what you want to see to confirm it's working. TPM isn't
related to virtualization, but nice to have available for Anti Evil Maid.

-- 
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/be76bc0151d3248fe2e2f3a09932cc17.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Basic setup verification tests for correct setup? VT-d? Other?

Thank you, a lot quicker results...the results were:

XEN Intel VT-d iommu 0 supported page sizes: 4kB
XEN Intel VT-d iommu 1 supported page sizes: 4kB
XEN Intel VT-d Snoop Control not enabled
XEN Intel VT-d Dom0 DMA Passthrough not enabled
XEN Intel VT-d Queued Invalidation enabled
XEN Intel VT-d Interrupt Remapping enabled
XEN Intel VT-d Shared EPT tables not enabled

Does this mean my VT-d functionality is working?

-- 
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/575b25db-b804-4ac6-9b76-03f7b6163c0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Basic setup verification tests for correct setup? VT-d? Other?

2018-01-13 Thread Yethal

W dniu sobota, 13 stycznia 2018 20:52:44 UTC+1 użytkownik vel...@tutamail.com 
napisał:
> I am hoping some folks can help me with some basic tests and commands to 
> verify my Qubes 3.2 is set up correctly:
> 
> I ran a qubes command in Dom0 to verify if VT-d is 
> working(https://www.qubes-os.org/doc/security-guidelines/): 
> 
> qubes-hcl-report AppVM  (Name of "AppVM" I was running)
> 
> The results were as follows:
> 
> It listed my computer, BIOS, XEN version, etc...
> 
> It also stated:
> HVM: Active
> I/O MMU: Active
> HAP/SLAT: Yes
> TPM: Device present
> Remapping: Yes
> 
> Per some googling:  "Alternatively, in dom0 (under Qubes OS or Xen more 
> generally) you could grep for "virtualisation" or "VT-d".  You should either 
> see "I/O virtualisation enabled" or "I/O virtualisation disabled"...:
> 
> In Dom0 I ran the command: 
> 
> grep "VT-d"
> grep "virtualisation"
> 
> Nothing really happened after waiting 10 minutes...so I closed the terminal.
> 
> 
> My concerns are:
> I have VT-d and VT-x enabled in my BIOSam I actually using this feature?
> Any other commands or checks I can do to confirm my installation is done 
> correctly?
> 
> Thanks again and happy new years Qube group...thank you again for all you do!
> 
> V

sudo xl dmesg|grep VT-d

-- 
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/5882144a-60c2-41a2-b31c-3f8611e4c9f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Basic setup verification tests for correct setup? VT-d? Other?

I am hoping some folks can help me with some basic tests and commands to verify
my Qubes 3.2 is set up correctly:

I ran a qubes command in Dom0 to verify if VT-d is
working(https://www.qubes-os.org/doc/security-guidelines/):

qubes-hcl-report AppVM (Name of "AppVM" I was running)

The results were as follows:

It listed my computer, BIOS, XEN version, etc...

It also stated:
HVM: Active
I/O MMU: Active
HAP/SLAT: Yes
TPM: Device present
Remapping: Yes

Per some googling: "Alternatively, in dom0 (under Qubes OS or Xen more
generally) you could grep for "virtualisation" or "VT-d". You should either
see "I/O virtualisation enabled" or "I/O virtualisation disabled"...:

In Dom0 I ran the command:

grep "VT-d"
grep "virtualisation"

Nothing really happened after waiting 10 minutes...so I closed the terminal.

My concerns are:
I have VT-d and VT-x enabled in my BIOSam I actually using this feature?
Any other commands or checks I can do to confirm my installation is done
correctly?

Thanks again and happy new years Qube group...thank you again for all you do!

--
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/6bc22877-3b4b-4c23-a59b-84f917f262eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: No more boot after update

Le samedi 13 janvier 2018 19:44:54 UTC+1, cooloutac a écrit :
> On Saturday, January 13, 2018 at 1:37:57 PM UTC-5, Bertrand Lec wrote:
> > Hello,
> > 
> > I'm fresh installing Qubes R3.2 on my desktop PC, aside from Ubuntu.
> > The PC is configured with UEFI. 
> > 
> > The installation goes well. At that time, I can reboot directly to Qubes.
> > 
> > However, after I update dom0, Qubes refuse to reboot. The boot is done to 
> > Ubuntu. Even when I choose to boot Qubes in the BIOS, Ubuntu will boot.
> > 
> > Result of efibootmgr command is:
> > BootCurrent: 
> > Timeout: 1 seconds
> > BootOrder: 0002,,0005,0001,0007
> > Boot* ubuntu
> > Boot0001* Hard Drive
> > Boot0002* Qubes
> > Boot0005* CD/DVD Drive
> > Boot0007* Removable Drive
> > 
> > From my understanding, it says that Qubes is the first one to be booted but 
> > the currently booted is ubuntu (which is true :) )
> > 
> > Do you have any idea for me?
> > 
> > Thanks
> > Bertrand
> 
> you have to add qubes to the ubuntu grub.

With the way the BIOS is configured, it should only boot Qubes, and it's what 
it did with several reboots done before the dom0 upgrade. 

By the way, I have just seen that there is no *cfg file in Qubes' /boot. Is it 
normal...?

However, if a modification of Ubuntu's grub could be the solution, I'll take 
it, but I don't see what I could put there.

Bertrand


-- 
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/5f3d54f5-4c5f-4e4d-ace8-78da77445011%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

On Saturday, January 13, 2018 at 1:19:18 PM UTC+1, Vincent Adultman wrote:
> IIUC this still seems fairly awful from a usability perspective if we think 
> of the added cognitive load of watching what is running when and remembering 
> or making choices on what to close / restart when (I'm reading between the 
> lines and guessing this has had something to do with decision on 
> reintroduction of Qubes manager?).

It is just temporary countermeasure. Actually, Qubes was not designed with 
Meldown in mind. In fact, no OS was. The countermeasures are rather the best we 
can do until it gets fixed than something that shoul be smooth and user 
friendly.

IMHO it is just a coincidence that Qubes Manager was reintroduced those days.

Regards,
Vít Šesták 'v6ak'

-- 
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/70f0d6e1-39bc-4a33-9d74-cac9fd4da1e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

I have one more idea: The Vixen patch could be useful for VMs with PCI devices.
Memory balooning is not supported there anyway. QEMU in dom0 looks ugly, but
this case is a bit different: AFAIU, the attacker can directly talk to QEMU if
and only if she has escaped from PV. Maybe it is not nice, but it is not that
bad either.

With Qubes 3.2, I believe this can be a clean win. Compared to the proposal
(focusing on VMs with PCI devices only):

* It fixes the Meltdown. The proposal does not address it for those VMs.
* Attacker can try to break out from both PV and then from HVM or (more likely)
from PV and then pwn QEMU. This is arguably harder than breaking directly from
PV.

With Qubes 4.0 (still focusing on VMs with PCI devices only), it is still
probably an improvement:
* If attacker can pwn QEMU (but not PV), she can with the current proposal read
the whole memory using Meltdown. With Vixen, QEMU vulnerability is probably not
enough for Meltdown.
* If attacker can escape from PV (but not QEMU), she can do pretty nothing.
Well, with Vixen, she can read the content of the container, but I don't think
this is a serious issue.
* If attacker can both escape from PV and attack QEMU, you are doomed in either
case.
* Theoretically: If attacker can escape from HVM, you are better protected with
Vixen (because attacker needs to escape from PV first).
* If there are some vulnerabilities that do not allow full VM escape, you are
probably still better protected with Vixen. Qemu in dom0 runs as an ordinary
process (so attacks like buffer overread have quite limited impact) and it is
the same case for PV.

Have I missed something?

I don't say that Qubes should go this way. Maybe there are better ways to
achieve some goals (especially for 4.0+). I am just saying that QEMU in dom0 –
however horrible it looks – might be acceptable in this special case.

Regards,
Vít Šesták 'v6ak'

--
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/f51baeff-52eb-4d65-bfb7-7c15a3a0e102%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: No more boot after update

2018-01-13 Thread cooloutac

On Saturday, January 13, 2018 at 1:37:57 PM UTC-5, Bertrand Lec wrote:
> Hello,
> 
> I'm fresh installing Qubes R3.2 on my desktop PC, aside from Ubuntu.
> The PC is configured with UEFI. 
> 
> The installation goes well. At that time, I can reboot directly to Qubes.
> 
> However, after I update dom0, Qubes refuse to reboot. The boot is done to 
> Ubuntu. Even when I choose to boot Qubes in the BIOS, Ubuntu will boot.
> 
> Result of efibootmgr command is:
> BootCurrent: 
> Timeout: 1 seconds
> BootOrder: 0002,,0005,0001,0007
> Boot* ubuntu
> Boot0001* Hard Drive
> Boot0002* Qubes
> Boot0005* CD/DVD Drive
> Boot0007* Removable Drive
> 
> From my understanding, it says that Qubes is the first one to be booted but 
> the currently booted is ubuntu (which is true :) )
> 
> Do you have any idea for me?
> 
> Thanks
> Bertrand

you have to add qubes to the ubuntu grub.

-- 
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/a139e3f2-c0bb-499e-86ab-b644cd732f8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes Kernel with Retpoline and IBRS Patches included

2018-01-13 Thread Reg Tiangha

Hey everyone,

I posted this on qubes-devel, but forgot to post it here. Anyway, I
managed to get the Retpoline and IBRS kernel patches off the LKML
working on Qubes (I also included the Linux-Hardened Project patches in
there too), so I figured I'd share my work. I have a branch here for
anyone that wants to play around with it:

https://github.com/rtiangha/qubes-linux-kernel/tree/devel-4.14-hard

I also included instructions on how to backport a Retpoline-enabled gcc
version to Fedora 25, but it should build fine using the standard Fedora
25 toolchain as well. Tested on R3.2 only since I don't have access to a
machine that has R4.0 installed.

For now, the Retpoline patches are at version 6, and the IBRS patches
are at version 3. There is a version 8 of the Retpoline patches, but it
patches against and relies on a few functions that are only present in
the 4.15 branch at the moment, so I wasn't comfortable in trying to
backport things, especially if that functionality will eventually appear
in a future version of 4.14.

I'm just providing it as-is with no guarantees of support as things may
no longer be compatible as kernel versions increase and I don't have
much volunteer time to work on this and troubleshoot if things break.
But if I do find updated working combinations, I'll update the branch
accordingly (this is mainly for myself so I'm the guinea pig).

- Reg

-- 
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/p3djlb%24lfm%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] No more boot after update

Hello,

I'm fresh installing Qubes R3.2 on my desktop PC, aside from Ubuntu.
The PC is configured with UEFI. 

The installation goes well. At that time, I can reboot directly to Qubes.

However, after I update dom0, Qubes refuse to reboot. The boot is done to 
Ubuntu. Even when I choose to boot Qubes in the BIOS, Ubuntu will boot.

Result of efibootmgr command is:
BootCurrent: 
Timeout: 1 seconds
BootOrder: 0002,,0005,0001,0007
Boot* ubuntu
Boot0001* Hard Drive
Boot0002* Qubes
Boot0005* CD/DVD Drive
Boot0007* Removable Drive

>From my understanding, it says that Qubes is the first one to be booted but 
>the currently booted is ubuntu (which is true :) )

Do you have any idea for me?

Thanks
Bertrand

-- 
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/db4ea5cb-6cba-4e5a-b285-62b7bdc5fb07%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

2018-01-13 Thread cooloutac

On Friday, January 12, 2018 at 5:24:25 AM UTC-5, haaber wrote:
> >>
> >> so people saying the intel meltdown bios patch slows performance.  I got 
> >> an increase in performance lmao.  probably depends on os though.
> > 
> > but also in my particular case they also addressed other bugs,   but intel 
> > pushed the bios patch for meltdown,  so worth a check from your boards 
> > manufacturer site.
> > 
> When I download the (in my case with HP a win exe) BIOS update file, it
> contains the "real" bios update (the .BIN file) and some other crap. The
> only way to avoid tampered downloads seems to download it several times,
> via tor and some other independent sources & to compare them. I guess
> you all do that?
> 
> HP does not seem to deliver pgp signatures afaik. But they do ship some
> signature files. Is someone aware of how checking these manually? Bernhard

comparing with tor is all I do too.  

You can also update the HP bios from a usb without using windows if you prefer. 
 https://support.hp.com/us-en/document/c00042629

-- 
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/a466d935-9c00-4cd3-806c-65953caa79bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 3.2 UEFI install media

2018-01-13 Thread tani . langfingaz

On Tuesday, 11 July 2017 10:49:20 UTC+2, Stephan Marwedel  wrote:
> I was able to determine the cause of the problem. After having changed 
> the label by editing xen.cfg as described the following needs to be done 
> in addition before the media can be used on an UEFI system to install Qubes:
> 
> 5. Unmount the USB media, but leave it connected to the machine. 
> Assuming that the USB device is named /dev/xvdi, execute the following 
> command:
> 
> dosfslabel /dev/xvdi1 BOOT
> 
> This creates a label name that the UEFI bootloader uses to identify the 
> root image. Now the media can be used to install Qubes 3.2.
> 
> On 07/10/2017 06:46 PM, Stephan Marwedel wrote:
> > Thanks for this interesting hint. Following your detailed instructions I
> > was able to create a bootable media that correctly boots on my Thinkpad
> > in UEFI mode. However, when the kernel finished loading, an emergency
> > shell appears and the following messages are displayed:
> >
> > Starting Dracut Emergency Shell...
> >
> > Warning: /dev/root does not exist
> >
> > Entering emergency mode
> >
> > It seems that the kernels loads OK, but is unable to find a root
> > filesystem to mount. As I do not have Qubes currently installed on my
> > machine, I am unsure about how to specify a root filesystem. The only
> > valid root filesystem is the one on the installation media, but that
> > should be found automatically. Or is it necessary to specify it manually?
> >
> > Regards,
> > Stephan
> >
> > On 06/26/2017 08:29 AM, Dave C wrote:
> >> I recently had some success install Qubes 3.2 on a lenovo p51, booting
> >> UEFI.  I went through a lot of a trial and error in the process.  I'm
> >> hoping this post can save others some time.  I've seen in other
> >> threads some struggling to get Qubes working with UEFI firmware.
> >>
> >> I intended to save my command history to disk so that I could post
> >> step-by-step exactly what to do.  But I must have been in a dispvm at
> >> the time, because now I can't find that history.  So the following is
> >> from memory and not precise.
> >>
> >> I tried every trick I could find related to Qubes UEFI installation,
> >> and thinkpad troubleshooting.  What finally worked does not appear to
> >> be documented in any of the Qubes documentation.  Qubes uses Fedora's
> >> installer, Anaconda, and the following approach is documented on
> >> Fedora's wiki.
> >>
> >> 1. Follow Qubes install guide up to the `dd` command.  Don't write to
> >> usb with `dd`.
> >> https://www.qubes-os.org/doc/installation-guide/
> >>
> >> 2. Instead, use Fedora's `livecd-iso-to-disk` tool.  You'll need the
> >> `livecd-tools` package.  See
> >> https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB#Command_line_method:_Using_the_livecd-iso-to-disk_tool_.28Fedora_only.2C_non-graphical.2C_both_non-destructive_and_destructive_methods_available.29
> >>
> >>
> >> I don't recall for certain exactly what I passed to
> >> `livecd-iso-to-disk`.  Try this:
> >>
> >>  sudo livecd-iso-to-disk --efi --format Qubes-R3.2-x86_64.iso
> >> /dev/xvdi
> >>
> >> The media as written will not quite boot, yet.  Qubes EFI boot is
> >> configured to find a label "Qubes-R3.2-x86_64", but the media written
> >> by the livecd tool is labelled "BOOT" (and the filesystem does not
> >> support the longer label, so the --label option would not help).
> >>
> >> 3. Mount the usb media (/dev/xvdi in the example above)
> >>
> >> 4. Edit xen.cfg.  If I recall correctly, `/EFI/BOOT/xen.cfg`.
> >>
> >> In this file, replace every occurrence of `LABEL=Qubes-R3.2-x86_64`
> >> with `LABEL=BOOT`
> >>
> >> You should now have install media that work on UEFI firmware!
> >>
> >>
> >> After install, I recommend upgrading kernel version for recent
> >> hardware.  I.e. with
> >>
> >>  sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel
> >> kernel-qubes-vm
> >>
> >>
> >

Thanks a lot Dave C and Stephan Marwendel. By following both of your 
instructions I got the installation working on my Lenovo ThinkPad Yoga 460!

-- 
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/4fa06b44-5b2f-4c82-9fdf-1fbc56accdc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

2018-01-13 Thread 'Vincent Adultman' via qubes-users

>> Only running VMs are vulnerable
>>
>> Since Qubes OS is a memory-hungry system, it seems that an attacker
>> would only be able to steal secrets from VMs running concurrently with
>> the attacking VM. This is because any pages from shutdown VMs will
>> typically very quickly get allocated to other, running VMs and get wiped
>> as part of this procedure.

IIUC this still seems fairly awful from a usability perspective if we think of 
the added cognitive load of watching what is running when and remembering or 
making choices on what to close / restart when (I'm reading between the lines 
and guessing this has had something to do with decision on reintroduction of 
Qubes manager?).

sys-net is considered to be likely / easily compromised (such that there seems 
some real utility in making it a dispvm under 4). However, it will also be 
running for most users in most everyday cases for long periods.

A common use case for open at one time for me for internet banking might be at 
minimum sys-net, sys-firewall, sys-usb, vault and a dispvm (as shitty banks 
here often loading things off marketing or even advertising network domains 
changing fairly regularly). If we're saying that in an ideal situation, sys-net 
and sys-usb (if it has had any untrusted devices attached to it) are started 
clean else the secrets vault is at risk, that seems to remain a very serious 
problem. The other approach seems to be to store the banking secrets in a 
banking vm, and do the browsing as well from there. Some sensitive tasks can no 
doubt be done with sys-net shut down, but by no means all.

If we're considering that this will be the case for quite some time(?) due to 
Xen approach, do we need to offer some sort of recipe situation for vm-start 
(where I can ensure my "red" vms are shut down or cycled before my vault is 
started for example).

I try to pay my Qubes dues by offering assistance in IRC, and I'm anticipating 
here the sort of user willing to put effort into thinking about how they need 
to partition their domains, and maybe even write some custom rules / scripts 
but after that needs the system not to overly get in the way of day to day 
tasks / require constant tinkering.

Vince

-- 
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/y4JzRn90_0mDNiNrt3Hq_kPJY6KbTxstTz8z2KvR_8ORlcJ7thJC0zOZupxxEuewcc3TnhVx5Rrz400I1B6XLy9BYjNVHinu4kNHFRn7dIU%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Running Windows from Qubes VM ?

2018-01-13 Thread 'awokd' via qubes-users

On Sat, January 13, 2018 7:49 am, ThierryIT wrote:
> Hi,
> Seems to work better even if I am still not able to boot my windows.
> With "fdisk" I can see that my bootable HDD is "sdc1".
> From Dom0, when doing a : qvm-start vm-test --hddisk /dev/sdc1, I do have
> a popup from my Windows drive.
>
> Booting from CDROM  error code failaure 2
> Booting from Hard drive, failed no bootable disk 
>
>
> No bootable device ...
>
>
> Ideas ?
>
>
>
>
> Le vendredi 12 janvier 2018 17:43:56 UTC+2, awokd a écrit :
>
>> On Fri, January 12, 2018 2:53 pm, ThierryIT wrote:
>>
>>> Hello,
>>>
>>>
>>>
>>> I am not able to use "qvm-start" because the HVM I have created is
>>> "Empty".
>>> Dom0 is able to see my Windows 7 hard drive:
>>> /dev/sdc2 /run/media/user/32E...CCB type fuseblk
>>>
>>>
>>>
>>> From Dom0 I am able to have access to all my Window 7 files.
>>>
>>>
>>>
>>> Any ideas ?
>>>
>>>
>>>
>>> Thx
>>>
>>>
>>>
>>> Le vendredi 12 janvier 2018 13:59:56 UTC+2, awokd a écrit :
>>>
>>>
 On Fri, January 12, 2018 6:48 am, ThierryIT wrote:


> Hello,
>
>
>
>
> I have a laptop with two internal Hard Drives.
> One HD with Windows 7 the second Hard Drive with Qubes on it.
> Is it possible to run Windows 7 from a VM's Qubes instead of
> building a Win dows's VM ?
>

 You might be able to create a Win 7 HVM inside Qubes, then use
 qvm-start win7 --drive /dev/sdb5 (or wherever your Win7 bootable
 partition is located) to start it. Never tried it though.
>>
>> Can you provide the exact error message? Not sure why qvm-start would
>> care it's empty, it will still boot from a CDROM then too...

Maybe the boot sequence doesn't search hard drives attached like that, in
which case it won't work.



-- 
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/7ec59ad1b949d11baf1a7a319b7af1de.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: memory management in dom0 ?

> My dom0 has no swap, I didn't disable it, it just never had any.
> I guess thats because in the installer I didn't assign any swap partition.

Not optimal IMHO, but it simplifies this case.

> > * How much of memory does the AppVM use? 
> 
> I looked at it at the time I got repeated crashes, it had some 800MB 
> assigned to it.
> 
> > What is the memory limit for the
> > AppVM? See VM settings » Advanced » Initial memory.
> The settings are 1GB initial and 4GB max.
> 
> I "solved" it by closing some VMs and my chromium got more space assigned.

This looks like it should not have behaved this way.

> I start a compile (8 cores times 0.6GB of mem used) and maybe 10 seconds 
> later I get out-of-memory issues.
> To my annoyance xentop shows me that there is still >10 GB free, 
> unallocated.

Again, it should not behave this way, Qmemman polls in 0.1s and tries to give 
the VM 130 % of its requirements. And all the VMs have 1GiB of swap space, 
unless you have made something custom. So, even if it was not fast enough, it 
should be temporarily covered by swap.

What is the status of qubes-qmemman.service? Do those issues persist after 
Qmemman restart or even after system reboot?

Regards,
Vít Šesták 'v6ak'

-- 
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/7aabf3c3-4dc3-41af-b357-6fdd420fc194%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

AW: [qubes-users] Re: Qubes Manager is coming back in Qubes 4.0-rc4!

2018-01-13 Thread '[799]' via qubes-users

Andrew David Wong wrote:

> Specifically, it will not duplicate functionality
> that is already provided by the new 4.0
> widgets. Specific examples include attaching
> and detaching block devices, attaching and
> detaching the microphone, and VM CPU
> usage.

Great news that the Qubes Manager will come back. Linux has always be about 
free choice and as Qubes Manager will be an additional way to interact with 
Qubes the users who don't want, don't have to use it.

I am also voting for a Qubes Manager which has nearly full functionally, as I 
don't like to use different places to do stuff.
Maybe this can also be configured, so that you have "lean mode" and an "full 
mode" or something similar. As mentioned: choice is good.

The current user interface results in much more "mouse meters" compared to 
Qubes 3.2

Thanks to the Qubes Team that they're listening to the user base.

[799]

-- 
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/rXY2pHVr2yJByJ7mdrDFoCDBJ02dDONU0rKKipV8Qv-rvHeSzreelj0wFkX7pZauueBFTGd3ow1FR0kNx5pDp-0qsbPm-5HJhb1DH3mggYc%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)