AEM with Linux 4.4 causes hard reboot (cont... Trying to resolve issue)

[Chris Laprise]

On 07/15/2016 09:33 AM, Chris Laprise wrote:

> On 07/13/2016 11:15 AM, Chris Laprise wrote:
>>
>> I am able to get 4.4.* to boot now! The trick was to add
>> 'min_ram=0x2000000' to the tboot options like I used to do--the AEM
>> README describes how.
>>
>> But now I cannot get AEM to seal the secret. Nothing at all about AEM
>> is displayed during startup, even though rd.antievilmaid is on the
>> kernel options line.
>>
>> Chris
>>
>
> For the record, AEM is now working on my system. The other thing that
> was required was to update the anti-evil-maid package to version 3.0.3.
>
> Chris
>

@Andrew, Todd Lasman...

Could one/both of you try this out ...please? :D Especially the tboot
workaround; It only requires pressing 'e' at the grub prompt and adding
the parameter to the multiboot tboot line (then press Ctrl-x to boot).

It would be good to see if this works on other machines before either
closing the issue[1] or inquiring upstream.

Thanks,
Chris

1. https://github.com/QubesOS/qubes-issues/issues/2155

[Todd Lasman]

Will do, Chris. Thanks for working this out. May take a few days to get to this, though. I'll report back.
By the way, where did you get the aem 3.0.3 package? I've only got 3.0.2 available.

Todd

[Chris Laprise]

Cool. Try this:

sudo qubes-dom0-update anti-evil-maid --enablerepo=qubes*testing

Chris

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Thanks for all of your work on this, Chris. I might have some time to help
test this soon.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXigsXAAoJENtN07w5UDAwMtcP/2xmFvUTZ8k94RWPEcRi2jOv
q2R/paTkjlXApVtcA5cGW6MSlgRyWhJi8XmpVk/tCIhCfgT26J6zIkDRDlP4SgTo
jW+KDYweaz3+G1bk2FsJuVZ9WvOQ0Gl127+dYexNeshCMIuGfvmeN8npmL1Bb+Ec
m8jWlKC0RleDjHK4jL7brke/GTWtSkMLrjjqPaj2C7X5lZr4x1NJ9neEOdI1n6Sx
SvI4Ewbi2xChLAaP9oj2hjqleH38YeAgjAwFt7R3/nU7xjJaLricbW3rao3QXpzK
PpMSnjkhbp5ZgUrDEoOXpNhBwYiUgZbVkrJD9UEqcur4AiivlWqItk20H7Vr7W48
krqcCnJXJKvta4TD7s+0apiz8kZ/dDwN7FP5G7XhhXBjILBwD3DACkKdjKlMWMo8
hTZKJmUhG5LXkpb+6CFekji2VaufMMGzZUaRCEtxF7ETiZAjK13B66YvUD1N3r28
7KveQvtFSZ8iCNvp/uG5li/3T4017hTxzfH0aKf1yKXNwrfnBssId5pkPsWl7dP4
c1Dalw5MbTCbhhq8Q/t8hf+VAND33l4dD/pRmR8HBVLACvuvdiywafXxvX92SOZT
DIKnGj8F3baVQ31MzA3+7Z3it2UQ/lx4kmZXwNqTfREQRV5eCLZ+DVpqd4eW88Bb
Y5usXNK+ixh7TDPPcUXR
=2jQO
-----END PGP SIGNATURE-----

[tel]

Sorry for the delay, Chris. I was waiting for 3.2-rc2, which I just installed. It seems to come with the latest AEM package, so I didn't have to install that package myself.

I added the parameter to the tboot line. It didn't reboot, but it hung before asking for the password with "Waiting for /dev/disk/by-label/aem* to be connected..."

Not sure where to go from here.

Todd

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Do you use also USB VM? In that case, dom0 has no access to USB
controllers...

But you can re-enable it just for boot time by editing /etc/default/grub
and removing the line with "hide_all_usb" (or just comment it out). Then
rerun `grub2-mkconfig -o /boot/grub2/grub.cfg`.
It will expose dom0 for all connected USB devices for a short time
during system startup.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXnSGKAAoJENuP0xzK19cs7RcH/RhZFl+xIBsMF5csO2SR91DT
zx4iUbXPEbHbuWBjnvTbE6CbBNHlFrc3YcPHEmoxFc5sU2sLc71V3YRwCeKOr42S
9b4YpmD/u11Cr53Zf/qrivzyE+I4K/nFjNfOTjCJ3LPo6kSqZGYcf7+BtVYU3lRf
kHnl/RopqZVrp6tAEzWaaaUDKxaR+LO54BFTOBfJbgNOwTYF42htdLQ2r9kkrXuQ
6DbVPMTYngGp0YFJQaCw2f1s0S5ifgbEEwJZFmNFqIVy87/vOGWUoNS2bzvZUBDx
T5MyQd4P1MFNq89fl+9lN6YTDWEh2iP+kIqKqaBJruQ/MD7Oi4+5+oHKZyGjcM0=
=/J3q
-----END PGP SIGNATURE-----

[Todd Lasman]

On 07/30/2016 02:52 PM, Marek Marczykowski-Górecki wrote:

On Sat, Jul 30, 2016 at 02:44:24PM -0700, tel wrote:
> Sorry for the delay, Chris. I was waiting for 3.2-rc2, which I just installed. It seems to come with the latest AEM package, so I didn't have to install that package myself.

> I added the parameter to the tboot line. It didn't reboot, but it hung before asking for the password with "Waiting for /dev/disk/by-label/aem* to be connected..."

> Not sure where to go from here.

Do you use also USB VM? In that case, dom0 has no access to USB
controllers...

But you can re-enable it just for boot time by editing /etc/default/grub
and removing the line with "hide_all_usb" (or just comment it out). Then
rerun `grub2-mkconfig -o /boot/grub2/grub.cfg`.
It will expose dom0 for all connected USB devices for a short time
during system startup.

>

Yep. That's the ticket.

I can confirm that Chris' method works, and I now have a working anti-evil-maid! Thanks Chris and Marek!

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Thanks, Chris and Marek for fixing this, and Todd for testing and confirming!

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXnTXAAAoJENtN07w5UDAw3WYP/i05q3ShBfK8RJV9IRfM+2kT
69Np4tId2p2ZrLJQRcZU9LZZG07OcvsnJzieMlGzIdQsWr8nCFhfqkKgugzweC+x
G4in0U6xQhgGcP8yg8mXMSeQvZviVyiZTF5xQENqsawFyXODDCGNvRb8qSIZzq64
1ntTiu88GcLMBl7Qp2fOEA+EBehsX9GzahaYTlIoxTOLlAqzS7qwv2bhEcjg8x+l
HVRRTyJPLyObL357Qelg25XUoV7INPfXSiYx3aRG5P+iye0CCfSkQjIr439ttoGo
XfgL5uhQ5bdbS46doT3th0zlrboyj7IIDqfWc9rcSsm98NHGV5kSQF7R7q8o/FZy
rmjMcWa/aBbvv+897O8wadGMmPHopCtanMvjTQp0Qb+ehBqk0ofFw/tQ5a/Y6u4K
t/FvkCWlqpo/1CIHr+Ww86wimwBczuGOgN9JlJGKs77gDljZgGQOtuX5jls+XxLu
tN59qXiPY3vKrqqj8/oANmLNGLMqiA4ujOZdD5M33qg9oBm3KfOgw0kLTr7jFglW
w8VsC0Ezo6Hdb260BR/YpwAuI/yDUc3v0H7kAdygm858cLOKZ7sH9W4nubBJizG/
zS00t9kAQf54ZZ01jHjbfOBX2goXpS3qVHyoc/wdtqu+K/H9SV75wrAEor6kx6cp
x/h/cEzQRSBAw3MO4SYh
=OVEw
-----END PGP SIGNATURE-----

[donoban]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/30/2016 11:52 PM, Marek Marczykowski-Górecki wrote:
> On Sat, Jul 30, 2016 at 02:44:24PM -0700, tel wrote:
>> Sorry for the delay, Chris. I was waiting for 3.2-rc2, which I
>> just installed. It seems to come with the latest AEM package, so
>> I didn't have to install that package myself.
>
>> I added the parameter to the tboot line. It didn't reboot, but it
>> hung before asking for the password with "Waiting for
>> /dev/disk/by-label/aem* to be connected..."
>
>> Not sure where to go from here.
>
> Do you use also USB VM? In that case, dom0 has no access to USB
> controllers...
>
> But you can re-enable it just for boot time by editing
> /etc/default/grub and removing the line with "hide_all_usb" (or
> just comment it out). Then rerun `grub2-mkconfig -o
> /boot/grub2/grub.cfg`. It will expose dom0 for all connected USB
> devices for a short time during system startup.
>
>

Nice, this should be added to:
https://www.qubes-os.org/doc/usb/#tocAnchor-1-1-4

With some warning: "Caution! Enabling usb-vm with LUKS encryption and
a USB keyboard could stop you from booting your system"

:)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXnjhcAAoJEBQTENjj7Qilj+kP/2x7HDB3szCBsdd2fvywlRNc
mSULDpcl5PI+R3xcmlCs+8EHRJOxpaCCcmJWxtTuGQPSJz68Otnms4gTJ2k3t88z
0WuWufkuxg4/W9Y2VGm2NXghp3N4hQDB9rCxrYjBaprdAiJgr5JRwNG1yVFJgo3A
jKP9dGy/TIutjj9vj9LQ95k9Epf9yQFFcEOz26GE/0IeQLJnmM9Y4k+Fw3i5R+RY
Prq4ABX7H27H2sp4C7QNWgK74rktmqblgUfg4+svXdNhr1i9BoC1ql2hEO/MlcPu
eRCVAXiEQuJQaLNZTFJx4frHswlJNKaouMbKC8sK3qSS66L0S6bUKCuCXjMJ5x99
sVceKcXIJmY08jUxn5bXHYTytWLExmYRPJ/m7VLsKqOnZqYoj/UjggVo2xRN+RBz
NmzJL8fjKs74iNHxrNMwsuiUpDjy5wGYmVzgiI9SeVlOFr+WJbnTex60Z+v2CybO
Hekl47ZVna3a2yzOdzPuRAidroUdLPA8DNSVpTXN8cKEsCEqaqS0GN5KWxHqTY1Q
bbMxHMp0NWhah6q89KaU6InZ/hnmmQa5Ceca9O8RAoX8qKWj62nsYAnHuRtdgKu0
QE5jECeu8y5pRittzowkHwj9cNnQEVDHGhfzsrpQuOHUF09Wf3TATvWX2cqBxMoM
Bv2bNVtwQfpUKjzAW/xF
=uKAd
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-07-31 10:41, donoban wrote:
> On 07/30/2016 11:52 PM, Marek Marczykowski-Górecki wrote:
>> On Sat, Jul 30, 2016 at 02:44:24PM -0700, tel wrote:
>>> Sorry for the delay, Chris. I was waiting for 3.2-rc2, which I just
>>> installed. It seems to come with the latest AEM package, so I didn't
>>> have to install that package myself.
>
>>> I added the parameter to the tboot line. It didn't reboot, but it hung
>>> before asking for the password with "Waiting for
>>> /dev/disk/by-label/aem* to be connected..."
>
>>> Not sure where to go from here.
>
>> Do you use also USB VM? In that case, dom0 has no access to USB
>> controllers...
>
>> But you can re-enable it just for boot time by editing /etc/default/grub
>> and removing the line with "hide_all_usb" (or just comment it out). Then
>> rerun `grub2-mkconfig -o /boot/grub2/grub.cfg`. It will expose dom0 for
>> all connected USB devices for a short time during system startup.
>
>
>
> Nice, this should be added to:
> https://www.qubes-os.org/doc/usb/#tocAnchor-1-1-4
>
> With some warning: "Caution! Enabling usb-vm with LUKS encryption and a USB
> keyboard could stop you from booting your system"
>
> :)
>

If a USB keyboard is detected, the installer does not allow the option of
creating a USB qube, so it should not be possible for a user to accidentally
get him- or herself into this predicament.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXnl/wAAoJENtN07w5UDAwcRYQAI5gXyvdOcqpvOQLjsBKlgoQ
q+jILUwZ8I042kRlVIaMpgNauRix2xUmm6b6w5ExbI7kMp8xl3OkPy+d4yqUKwhe
RJ5b0cgwKjpyZppkT3ZxI4OM7ndBDt878sz2gTiAehAxJoxD3//MzL+Fks79yQEO
RqosmeVAi9kgPbHg43hcfFxq7y4hgXaWUdmW0vtZt3YuX7My7W/EUQNW5upIoSXv
8kQpXmr+fB73avOQI0yFpyN1yHqvgn/Jm+rS5mi88qQWja5FH6YjScERts9bL/9e
hiSG2CUmvjWHNNR15lhpPMS0v3Ut6hzivfIm/6AcRdbQdhw5DTfQSIT+zdMOFfDG
hA+4izKUGyzrpzjEqu/Y1IuOwr/DJuQ9guITtmT70HHai9GpkttBiQMiHzxfQAxb
1iCRiT9I1DTgFYVA5EqGaEe3L37nTZuWugUtkg6La45PCrOVdVUPia083RLWKimW
wUpA6QqyLrMee3mQjg1yAuFVMjvEe9QJKjUrE29ebG+nDBuSNtzxjIKg0x7E9Xqd
bje8FHuxKNdwormmd6cehUC6LfVaSaF4bOoxwYNuBWCO11lP4zmvd9h0zP90LpK/
+TyYeyoQdvV6m4gPIDWVvxyKMKjrMsr//+RWu7nKIZsUCXZ4aFlgB3qoJmrApyhw
d+DG5OzmhBtJAKHuw372
=ptkz
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

But using USB qube will not stop you from creating AEM usb stick (or the
other way around).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXnmHNAAoJENuP0xzK19csSesIAIxxM6ZbGfVlgiC9GZXzCfma
Pi4zBSbtScnae9wSlpDWNuOBCs3sUZNPXTWhrhViY0Vbb59e+4vF2zJ3e1YH9LE3
UlILPNMDbAXzUO9nbchbbIXvMrZXVyBXgDRsFeblCZyE6HUzKMijVfm1sm37u1nH
IXPH6XxT/hzIeH/03N4eNkJBd4oCLAK25UtWIHNns3Rplhkr0ogzVTWxNG3E/nno
nVXNtK8VdRyeX22zl40UAXJkirHO7JHxxNtJIKYrqY9wAuKjqCPd+5rU5TiWr+gC
quzxtZ9VUD60yMCblYHheJasYT1l9vl++Waf3RRT0pJnbhGZmlp/8BUOKjPBfo0=
=GHy8
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

So, the problem is that if rd.qubes.hide_all_usb is added to grub.cfg when the
USB qube is created, but the user later decides to create an AEM USB stick,
then the user must be told to remove rd.qubes.hide_all_usb, or else it will
not work. Is that correct?

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXnmLMAAoJENtN07w5UDAw1H8P/if8V4KAF7/QR+jNEiJkg7sN
STv9tLfVxk08HmTUTVRGK4GjezZakUjhtEGOGyF/mKPs39uJ1NOzIY4QtO21M7nH
A8M3yNNUuFbfdykvs4yP1c3gkLmkJcVdsLIGMFHye9VP51TBjsEmHT8s3DltmG1l
7HRzvhTvWcWmP6n3ZGBUEdNEiWt68CuK6lKWOaTWRFIDfHEeCJJymw4r5yA/81Oy
vQcOBCdBZR/8yU9veHrQeTvAfttJTBUO/uiudO1q006eCK7LHmcrEQ5M39LZk5H8
X5mycno2p7kGwDSrcgEnsakqcSJlPu9untfw1bdVQwxvPP2Lnkk03zwTu/fh+n+B
hNKdNwW+8NzqlyRP2cguk4qJjtV3VIB1STNulhNMMspoO+e6T44JvpYWCCGiYSXn
SLSrkzTHzFjr956dXPMGg2jZJaEEaixYAAxTeQMae9YLIjVFMIsyu/ttNrOmI5Y6
gN7GL7B7bj1zmHlHykvrGi8fIoQWXLQ/23RvqtGzqY5OXCsJ46nuMLn+qpqiSehB
/3s7hL2pNk/lEacfVfpa0X/EdATFzQS3CK5Bds+rqtVH0hTE8Y+R6wz7BoD2wQQ1
seJN7aiIOdTKOeQ3yR90VXyLffnjwOzdirYmfbJDgG6xRiWegc0fu2Pi6ANWPPxR
g8cJxWORzkmZCp4ECH2G
=WHkx
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

(And, as you said, the converse: If a user creates an AEM USB stick, then
later decides to create a USB qube, they should be warned not to add
rd.qubes.hide_all_usb to grub.cfg.)

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXnmNKAAoJENtN07w5UDAwnj0P/2uVn7FhDYbF8Zus0kx8MZKo
A1h6LBqepzZjpesfWifQ3sbgX5FnjADOgrWsFPWQyEtGxrw1Bb2UtJl3cPcqIBGG
4KQVWLL9bGmdS9d9VdZVL0snRKIHlr4z5R4A/1UDoKUhbGs/OtP7iN3w0zAUD8/3
DY1FLejTFCSu7jhTpd3pwAOe8b18g8PKnfBHuY4J2nXMxcHLhLjZiPYNvmXEFgnb
nXEChbBHshg/DtwuK8cx6oYZyK7Y3v2yr6ZGACv4ZGSfNThNZXpPralblBB7FPFT
fvAIjKzPZ0yUOjBVeAEqwO1h+P5+ruZPWsKo/CLJwG7h9ZuPXiNHCVGy1LTmHBRe
dvYQF9hl1WCwjbicmWRg/UqgbKA1lHMKqK/Ty/90SNbMpvqio6+g0GINf+c8Qw6Y
uYYmsHkTjr+N77xf1994jtk4aMTPu3NovAGj6jFOBrfuq+6z+GWQ99aqzo8bARdV
e83SDowqMv21XmV19gEVN36O8fJG/Lds1KUIqOVF/ZS6gysnWKqiEb7jSH5KZG3g
BBuduYca0JKGW0Vdeqt/MlDa8VShpX2LfvsLkRvocGxDor8fbWZXEKT3mFOyFpFi
27E0Paya6SiBwFU2N9pKS17XAfVfbW/grFgTLZ+Nh6ko0kVkGOkKExceVcP4MTSp
x8rVryXIsEqs2s0MfJwU
=cat0
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ok, added a new section to the USB documentation explaining hiding USB devices
from dom0:

https://github.com/QubesOS/qubes-doc/commit/15d418b778a8879323091c79fdc1084d
ecb890cb

And a pull request to the AEM README with a warning about using an AEM USB
device with a USB qube:

https://github.com/QubesOS/qubes-antievilmaid/pull/15

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXnnGCAAoJENtN07w5UDAwAXwP/jk/ikAjiWs+k4abrUzfyKdJ
kPsgmyKKXTuj5YWbLI+OgAgrlcqsZee1M1riTren2khpQOZOMe6MgQiKZ17kJ5Gw
4HzX615zJZCqRH/0YqDKfhdgS0VXmSutvTtAT+TX6/zHVTSNYBQWO8L/Dg6Hpuqt
01x2JgJuhAp97dMLfS3y66McwZK/KDM6teTVp7RgF14yWJCqLdSnUd0VhHAgcXAm
whBictNSdk169BtirC5jhUnNt0pIonVWVIOTwRaXV2kVxAWD74a04JNqKfLED11I
XhjY89+AkK+NGo+1piKCNztyB4x44IOab5AEb5W2ScInXOsh6oA5ZY7fwd3zUbPY
C2wgw7+7T9XhVlN/jrK58qsEZmXBws4jUSn7KqPon80sS7hz4uF21DCFexsFuxoG
Amum3d0zpZ5wjCTa1Y1CdaltV+Wq7vDZI5O3e8TUQpgHKxKZ0Iox1S4pP5Cn+MJM
b1aeR8bQce6zQswV7o5sH/2wC93bcdcWFlxoQYcwxZN55VAASqVW0FcE6RQzQ8ds
CMrqbI/FQOU6LasapdNUppEEglqhoAGiqmyZcL/ZjrobCFSPRk9WIY4Nhr2iAK3A
HhoXVMEeXRKzG+UkeWVesNQNJXC9b/sBXIccGA8Z5O4uAAdNCZIAOFLogFtwJj6D
m1t9f2ghBFUvuwQUM1ER
=j+oe
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Thanks!

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXnoZVAAoJENuP0xzK19csQYQH/jU8vL8JPtg0cBe2fXxtfLr9
mZPclxrW1qctpsHDcgxWz5guWMEcwhTC2YwOHgI5RYnzc5Q68QWGIIu/G/JjYybt
oyBVi6WXvL1ZFKjMXASn7u9Xx4/FdFi4OHw9Kob7DMiFiH2QAn9shfTzyEPoffLu
dYDi2QiMsyQVsotH54/W28qUqdZ8ibnKJiksoCqLMCoueRQCOV4IxF8aYblQ16wz
PpXFd9F59OKnTiV+Q1qiIWV502kOqbUMbE1dGRNgx4JTH/pMB8tUXOWxz7y+tHwX
YfhRaxBAkcoveqmwnc/idlENwR6Lb+egLvvQzkflTGJ4TW/n2epX/qNDJ4xOzic=
=iolQ
-----END PGP SIGNATURE-----

[donoban]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/31/2016 11:45 PM, Andrew David Wong wrote:
> On 2016-07-31 13:45, Andrew David Wong wrote:
>> On 2016-07-31 13:42, Andrew David Wong wrote:
>>> On 2016-07-31 13:38, Marek Marczykowski-Górecki wrote:
>>>> On Sun, Jul 31, 2016 at 01:30:42PM -0700, Andrew David Wong
>>>> wrote:
>>>>> On 2016-07-31 10:41, donoban wrote:
>>>>>> Nice, this should be added to:
>>>>>> https://www.qubes-os.org/doc/usb/#tocAnchor-1-1-4
>>>>>>
>>>>>> With some warning: "Caution! Enabling usb-vm with LUKS
>>>>>> encryption and a USB keyboard could stop you from booting
>>>>>> your system"
>>>>>>
>>>>>> :)
>>>>>>
>
>>>>> If a USB keyboard is detected, the installer does not allow
>>>>> the option of creating a USB qube, so it should not be
>>>>> possible for a user to accidentally get him- or herself
>>>>> into this predicament.

Yes, but if some user is reading USB Qubes doc, it's very likely he
will try to do a sys-usb himself.


I have some problems related to sys-usb. I did the installation of
Qubes 3.2 on my parents house with a Logitech keyboard. When I
returned to my house, after two or three tries before discovering this
thread, my Microsoft keyboard didn't work.

Fortunately, I have another Logitech keyboard here (also USB) and I
could boot my system. I guess the problem was the initramfs, it was
generated with the logitech keyboard connected so It doesn't load
modules for Microsoft.

This could cause hilarious scenarios, you go with your cool ultra
secure computer to show a friend how nice is Qubes and you end being
unable to boot your computer. I think initramfs should include most
keyboard drivers as possible...

After recreating the initramfs I could unlock my hard disk, but when I
went to the login screen, the keyboard didn't work! And the mouse
didn't work too! Well, I have a Dell monitor with USB ports. I have
both keyboard and mouse connected directly to the monitor. I
disconnected the keyboard from the monitor and connected it directly
to the computer and I could login into my xfce session. Few seconds
after login, the mouse started to work, I disconnected the keyboard
from the computer and reconnected to the monitor and it worked fine.
What could be happening? Is sys-usb supposed to wait for do something
after login?

Last problem (maybe should be posted in a new thread):

the main motivation for testing Qubes 3.2 for me was the USB
passtrough because it would nice for me to connect a WiFi dongle or a
Android smartphone with tethering. After install it (on my parent's
house), I tested the WiFi dongle. It was attached fine, but on the
dest VM it complained about unexpected errors and suggested a cable
problem. With the Android tethering it worked fine.

But now, when I try to attach it to a VM it says:
"ERROR: Device attach failed: Invalid speed recieved"

It also says when doing any qvm-usb command:
"Invalid 3-7 device desc in VM 'sys-usb'"

It's my Microsoft keyboard, but I think the error doesn't has relation
with the other error.


Any help is appreciated in advance, regards :)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXnwLEAAoJEBQTENjj7QilxDwP/2bi9MoNGJPgZlKmMSlW5as0
VB6xhi/qMHIOb4GxeQ5ANQKT7qhwoW7MXMEtBrfsNouPCml4wVgLjtCgoFa+q/BE
XNE8b1KMTZQ/YKV6aIb/iSO2+WOzAeLbVc86qKH6ir+osGAt8oee5qSlhCCizMV/
breYS9n+4Nr0uqQO73468tus/lunkviZTh9mvSuQBuMi+pdVbRY9gd56lbsS2eZj
cGAKW/S1vOMWF9txF3JIY1yaxWtCbYynb3EUiGWMixz9xbW1NDrE4nvHu/ZwCWVK
xqrVsTJXFDBXttg6qCoFo98Ue6k6n2xPH5tX59jyR30WXIqiFURBSpAUhrIUET5/
h/Sl9YYrwuEgMvq1tzy0lczt2/8Zh2yld4/bwzG03Ct9o0+ITXK9o97Jjm/bQ7nw
B2OWlWmjdflpAkI9xOavA9ADpYKlO2Ho7LQc6DDkozOrIy8ap5oxQIS1nkmB2XoN
lquVTIvCAWNH6ZkTJlVuHpU+8YCF0A23Aquh+Ls+XE58WUpAFZk5k60dlHCpmJ5Q
fHEFlpgDjy72z+exACucPABHQL4x0To29F9L4HihSiDrR00jfVD9GN03R0Mxnkce
KQbCTbv7Kr3/i19XkWNRUXIDmXxRoOJAHUriwRGdspscOCiM3Ft66VmGkTXft31H
2wwWg4mOTP5AR8XrVlGl
=HFfY
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

If you like to modify hardware, it's good idea to disable host-only mode
in /etc/dracut.conf. This will include most of the drivers.

Otherwise, I think it's actually a feature to have as little as possible
drivers in initramfs, as sys-usb nor sys-net are running yet.

> After recreating the initramfs I could unlock my hard disk, but when I
> went to the login screen, the keyboard didn't work! And the mouse
> didn't work too! Well, I have a Dell monitor with USB ports. I have
> both keyboard and mouse connected directly to the monitor. I
> disconnected the keyboard from the monitor and connected it directly
> to the computer and I could login into my xfce session. Few seconds
> after login, the mouse started to work, I disconnected the keyboard
> from the computer and reconnected to the monitor and it worked fine.
> What could be happening? Is sys-usb supposed to wait for do something
> after login?

It may be that the input proxy tried to start too early - which would be
a bug in service dependencies. Check logs with `journalctl` in sys-usb,
search for lines related to udev and/or input-proxy.

Anyway, in such a case, simply reconnecting the device (even to the same
port) should fix the issue.

> Last problem (maybe should be posted in a new thread):
>
> the main motivation for testing Qubes 3.2 for me was the USB
> passtrough because it would nice for me to connect a WiFi dongle or a
> Android smartphone with tethering. After install it (on my parent's
> house), I tested the WiFi dongle. It was attached fine, but on the
> dest VM it complained about unexpected errors and suggested a cable
> problem.

USB passthrough is quite tricky and unfortunately some devices may not
work. We just use USBIP driver, which according to our tests behaves the
best from available options.
You may have better luck asking on linu...@vger.kernel.org, for help
with USBIP driver. Include lsusb -v output for that device. If you
decide so, please cc me.

> With the Android tethering it worked fine.
>
> But now, when I try to attach it to a VM it says:
> "ERROR: Device attach failed: Invalid speed recieved"

I guess that "Invalid speed received" is actually nothing received at
all. It's probably some problem at sys-usb side, check logs there,
including ~user/.xsession-errors.

> It also says when doing any qvm-usb command:
> "Invalid 3-7 device desc in VM 'sys-usb'"
>
> It's my Microsoft keyboard, but I think the error doesn't has relation
> with the other error.

That's interesting. Can you post output of:

qubesdb-multiread /qubes-usb-devices/3-7

in sys-usb?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXn1ptAAoJENuP0xzK19csq1QH/juiYrAkbZUFacMw0A9wWg+d
pVUlJB65zGVHb7G7lbqp1iRggi1whESTp3Fbj4sP1XsQAXITkS1sd0Tgq2n73gXJ
Y/f2fFIZTEVkuqt6y2da1BCLC6U6sJcTLyose4FbgmN4da6jDnbVrOEeRpBXn3X8
Ha+dnULGUBd66aVrgJn0/IEsd4mnqykE/LstpnZsp0JeD9FtRKvRTqv8VyV92Gkw
dy+TJnW7M6c52NP3P09KGlTiX8oiCkF9B9pF6AnG77G42VDEkY68VYRBRgypu+nA
aw5r0MFtBZTz08QYxrxcZeBQC/chAOQVFeFyXkOjfu/Bwa0FcfFArdRn7tAaTo0=
=kY9l
-----END PGP SIGNATURE-----

[donoban]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/01/2016 04:19 PM, Marek Marczykowski-Górecki wrote:
> On Mon, Aug 01, 2016 at 10:05:24AM +0200, donoban wrote:
>> This could cause hilarious scenarios, you go with your cool
>> ultra secure computer to show a friend how nice is Qubes and you
>> end being unable to boot your computer. I think initramfs should
>> include most keyboard drivers as possible...
>
> If you like to modify hardware, it's good idea to disable host-only
> mode in /etc/dracut.conf. This will include most of the drivers.
>
> Otherwise, I think it's actually a feature to have as little as
> possible drivers in initramfs, as sys-usb nor sys-net are running
> yet.
>

I only want to unlock my hard disk if I'm using a different keyboard.
Adding most common keyboard/USB HID drivers should be enough. I will
look at it.

>> After recreating the initramfs I could unlock my hard disk, but
>> when I went to the login screen, the keyboard didn't work! And
>> the mouse didn't work too! Well, I have a Dell monitor with USB
>> ports. I have both keyboard and mouse connected directly to the
>> monitor. I disconnected the keyboard from the monitor and
>> connected it directly to the computer and I could login into my
>> xfce session. Few seconds after login, the mouse started to work,
>> I disconnected the keyboard from the computer and reconnected to
>> the monitor and it worked fine. What could be happening? Is
>> sys-usb supposed to wait for do something after login?
>
> It may be that the input proxy tried to start too early - which
> would be a bug in service dependencies. Check logs with
> `journalctl` in sys-usb, search for lines related to udev and/or
> input-proxy.
>
> Anyway, in such a case, simply reconnecting the device (even to the
> same port) should fix the issue.
>

I will check when I reboot because now my log is full of messages like
this:
sys-usb kernel: holtek_mouse 0003:04D9:A067.000C: control queue full

When it happens the keyboard gets stuck on some key and the mouse goes
very slow (50% of cpu usage on sys-usb), I need to disconnect and
reconnect the mouse. Maybe it's something related to the linux kernel,
I will investigate it.

>> Last problem (maybe should be posted in a new thread):
>
>> the main motivation for testing Qubes 3.2 for me was the USB
>> passtrough because it would nice for me to connect a WiFi dongle
>> or a Android smartphone with tethering. After install it (on my
>> parent's house), I tested the WiFi dongle. It was attached fine,
>> but on the dest VM it complained about unexpected errors and
>> suggested a cable problem.
>
> USB passthrough is quite tricky and unfortunately some devices may
> not work. We just use USBIP driver, which according to our tests
> behaves the best from available options. You may have better luck
> asking on linu...@vger.kernel.org, for help with USBIP driver.
> Include lsusb -v output for that device. If you decide so, please
> cc me.

Ok, I will consider when I stabilize other things :)

>> With the Android tethering it worked fine.
>
>> But now, when I try to attach it to a VM it says: "ERROR: Device
>> attach failed: Invalid speed recieved"
>
> I guess that "Invalid speed received" is actually nothing received
> at all. It's probably some problem at sys-usb side, check logs
> there, including ~user/.xsession-errors.
>
>> It also says when doing any qvm-usb command: "Invalid 3-7 device
>> desc in VM 'sys-usb'"
>
>> It's my Microsoft keyboard, but I think the error doesn't has
>> relation with the other error.
>
> That's interesting. Can you post output of:
>
> qubesdb-multiread /qubes-usb-devices/3-7
>
> in sys-usb?
>

Yes, it says:
user@sys-usb:~$ qubesdb-multiread /qubes-usb-devices/3-12_3
/desc = 045e:00db Microsoft_Natural\xc2\xae_Ergonomic_Keyboard_4000
/usb-ver = 2

Regards.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXn2I6AAoJEBQTENjj7QilW28P/ij8uEOVdmoeDRKfPAFdjkZ5
3zB4C2h53j97kiLTKhYyFQcxMKp/HnRSee7FQf+WVwuXTDcyfZ7JOTkSV+DNHNbz
FjEkoiRPT5eN+3K0y1vPS6IjA/S4W0pb0qkRWqofiUWAvehGpkI/aZu3zcaSAyWx
JUzjCmnQu164o45M8AOoLBq1LHYP6nF+7mYgx2hH+igj2C33zAmv5fY5236MLxRP
fxYqQk0QFtzgJ1I4QC+UKNFTJAQU18u5yxnWiG9tV4axQoEWX83502JfDwmxM3wX
JgPkOd6ky/K4qRe+fwTen0RForAEOKQVpNxqbNFjDSLVO3jPLMr9gfv0NQDqAfhF
gLvuse5pFz+4JpCThkWyh5qIo3BOqYdDZRMbQGNxn708t4BiQGGU/b3mBRIS4o51
UQINxicwFYBGL50etyxdNJvspCX6objqKuNkIWmc4adeSDaAbc7xfdbZ8nwt6k/z
LbGiKExy3RQ5tu8bxK440PYfgcR+wAYCsgjWR2PIXoTPvzLOzSPVRtrg0w8cV4Wc
WPmmVF+wJjRe2H1sseiSjmyu5KrcfDmFH3Gidu1ibp4jB4QYiEyqfsuJpResWX2C
DgsrjrWex7oPf9WXbFrP0GKAgt9m/EXzazNlTOkfckQJzhmr3aGfW3Y2so/Ax+BE
hkGJ1kotmkaLI1lGkFfB
=oZ3+
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Aug 01, 2016 at 04:52:42PM +0200, donoban wrote:
>
>
> On 08/01/2016 04:19 PM, Marek Marczykowski-Górecki wrote:
> > On Mon, Aug 01, 2016 at 10:05:24AM +0200, donoban wrote:
> >> This could cause hilarious scenarios, you go with your cool
> >> ultra secure computer to show a friend how nice is Qubes and you
> >> end being unable to boot your computer. I think initramfs should
> >> include most keyboard drivers as possible...
> >
> > If you like to modify hardware, it's good idea to disable host-only
> > mode in /etc/dracut.conf. This will include most of the drivers.
> >
> > Otherwise, I think it's actually a feature to have as little as
> > possible drivers in initramfs, as sys-usb nor sys-net are running
> > yet.
> >
>
> I only want to unlock my hard disk if I'm using a different keyboard.
> Adding most common keyboard/USB HID drivers should be enough. I will
> look at it.

Indeed it makes sense.

> >> It also says when doing any qvm-usb command: "Invalid 3-7 device
> >> desc in VM 'sys-usb'"
> >
> >> It's my Microsoft keyboard, but I think the error doesn't has
> >> relation with the other error.
> >
> > That's interesting. Can you post output of:
> >
> > qubesdb-multiread /qubes-usb-devices/3-7
> >
> > in sys-usb?
> >
>
> Yes, it says:
> user@sys-usb:~$ qubesdb-multiread /qubes-usb-devices/3-12_3
> /desc = 045e:00db Microsoft_Natural\xc2\xae_Ergonomic_Keyboard_4000
> /usb-ver = 2
>
> Regards.

It's probably because of ® character here...

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXn26/AAoJENuP0xzK19cs+bsH/0kpoFC7ZEuRqUZdjxoiyWlE
f6CVM4o8YnZ4XAo34WyjYS3g9LHaWhdpIWnuPiwAMh+6LcrU0jivBlfKyxnQbFec
pUVRHEITwuiLtQPVJspEqmVtj0s8wpcbjdQfF3k+528M/uk6C3h/pmil63328R4Y
mjCciaPhjkHOfelGgq3wKLui9HW9sjGzPmpacx1w2ILt7gE9JJilt/6xHfZrEIxj
s/OiMWs8N0feH/7b2+mFVb8YuNbGYJ99W+BO+IqOt0DQVoFQNg9mUffrtbKcj1HK
sL7vHVnbZbWMq+tSCQ+2kJMFISqfJOXInogTpR2ilZzvrtTKhko7tIEOCmp45c4=
=AFKa
-----END PGP SIGNATURE-----