Re: [qubes-devel] NVIDIA RTX 20XX
well, trying to test it but I'm actually hanging at... how the hell do I add your repo without modifying my qubes-dom0.repo manually any way? if not, your repo does not contain thiy metalink stuff Am Montag, 27. Januar 2020 01:02:32 UTC+1 schrieb Frédéric Pierret: > > Hi, > > We debugged this problem with Marek and found a simple temporary > workaround: > https://mirror.notset.fr/qubes/repo/notset/yum/r4.0/unstable/dom0/fc25/rpm/ > > If you want to try and tell us it solves the problem on your side too, > you can find the built kernel with this path on my mirror: > https://mirror.notset.fr/qubes/repo/notset/yum/r4.0/unstable/dom0/fc25/rpm/ > signed with my bot signature > https://mirror.notset.fr/qubes/repo/notset/RPM-GPG-KEY-notset > > Best, > > Frédéric > > On 2020-01-25 00:30, Frédéric Pierret wrote: > > > Hi, > > > > Thank you for your feedback. I just tested under R4.1 in development and > > I succeeded to have a kernel log thanks to Marek and few hacks in dom0. > > > > Here is the bug report: > https://bugzilla.kernel.org/show_bug.cgi?id=206299 > > > > FYI, I tried few months ago to build NVIDIA module under Qubes but I hit > > a problem of allocating buffers. It was the same problem than a one > > reported on NVIDIA dev forum by another person using Xen as a desktop > > machine (not Qubes). > > > > Best, > > > > Frédéric > > > > On 2020-01-24 17:22, Ralph Alexander Bariz wrote: > >> Have the same problem with a rtx 2070. My temporary solution is to put > a cheap gpu into my pc(nvidia geforce 710) into the second pci port and cut > of the power of the 2070 when using qubes. > >> the problem is simple. The included nouveau driver does not support it. > You could install the properitary one whats a security problem. > >> my attemp to solve it, when I've got time, will be to compile the > newest nouveau driver in a fedora 25 qubes and install it to dom0. > >> For sure its necessary to ensure cube nit getting compromised in the > process. > >> > >> BR > >> > > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/33a2570d-18e7-4c69-85b3-da83d7d244f5%40googlegroups.com.
Re: [qubes-devel] NVIDIA RTX 20XX
for manual installation of the rpm packages I lack the information of which are the ones to install Am Samstag, 8. Februar 2020 17:35:56 UTC+1 schrieb Ralph Alexander Bariz: > > sorry, if I'm acting stupid. coming from debian world, there I probably > would figure it out myself. also do not really find anything to that > > Am Samstag, 8. Februar 2020 17:26:05 UTC+1 schrieb Ralph Alexander Bariz: >> >> well, trying to test it but I'm actually hanging at... how the hell do I >> add your repo without modifying my qubes-dom0.repo manually >> any way? if not, your repo does not contain thiy metalink stuff >> >> Am Montag, 27. Januar 2020 01:02:32 UTC+1 schrieb Frédéric Pierret: >>> >>> Hi, >>> >>> We debugged this problem with Marek and found a simple temporary >>> workaround: >>> >>> https://mirror.notset.fr/qubes/repo/notset/yum/r4.0/unstable/dom0/fc25/rpm/ >>> >>> If you want to try and tell us it solves the problem on your side too, >>> you can find the built kernel with this path on my mirror: >>> >>> https://mirror.notset.fr/qubes/repo/notset/yum/r4.0/unstable/dom0/fc25/rpm/ >>> signed with my bot signature >>> https://mirror.notset.fr/qubes/repo/notset/RPM-GPG-KEY-notset >>> >>> Best, >>> >>> Frédéric >>> >>> On 2020-01-25 00:30, Frédéric Pierret wrote: >>> >>> > Hi, >>> > >>> > Thank you for your feedback. I just tested under R4.1 in development >>> and >>> > I succeeded to have a kernel log thanks to Marek and few hacks in >>> dom0. >>> > >>> > Here is the bug report: >>> https://bugzilla.kernel.org/show_bug.cgi?id=206299 >>> > >>> > FYI, I tried few months ago to build NVIDIA module under Qubes but I >>> hit >>> > a problem of allocating buffers. It was the same problem than a one >>> > reported on NVIDIA dev forum by another person using Xen as a desktop >>> > machine (not Qubes). >>> > >>> > Best, >>> > >>> > Frédéric >>> > >>> > On 2020-01-24 17:22, Ralph Alexander Bariz wrote: >>> >> Have the same problem with a rtx 2070. My temporary solution is to >>> put a cheap gpu into my pc(nvidia geforce 710) into the second pci port and >>> cut of the power of the 2070 when using qubes. >>> >> the problem is simple. The included nouveau driver does not support >>> it. You could install the properitary one whats a security problem. >>> >> my attemp to solve it, when I've got time, will be to compile the >>> newest nouveau driver in a fedora 25 qubes and install it to dom0. >>> >> For sure its necessary to ensure cube nit getting compromised in the >>> process. >>> >> >>> >> BR >>> >> >>> >>> -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/9f130186-a07f-4f9f-a890-85d9b33df11d%40googlegroups.com.
Re: [qubes-devel] NVIDIA RTX 20XX
sorry, if I'm acting stupid. coming from debian world, there I probably would figure it out myself. also do not really find anything to that Am Samstag, 8. Februar 2020 17:26:05 UTC+1 schrieb Ralph Alexander Bariz: > > well, trying to test it but I'm actually hanging at... how the hell do I > add your repo without modifying my qubes-dom0.repo manually > any way? if not, your repo does not contain thiy metalink stuff > > Am Montag, 27. Januar 2020 01:02:32 UTC+1 schrieb Frédéric Pierret: >> >> Hi, >> >> We debugged this problem with Marek and found a simple temporary >> workaround: >> >> https://mirror.notset.fr/qubes/repo/notset/yum/r4.0/unstable/dom0/fc25/rpm/ >> >> If you want to try and tell us it solves the problem on your side too, >> you can find the built kernel with this path on my mirror: >> >> https://mirror.notset.fr/qubes/repo/notset/yum/r4.0/unstable/dom0/fc25/rpm/ >> signed with my bot signature >> https://mirror.notset.fr/qubes/repo/notset/RPM-GPG-KEY-notset >> >> Best, >> >> Frédéric >> >> On 2020-01-25 00:30, Frédéric Pierret wrote: >> >> > Hi, >> > >> > Thank you for your feedback. I just tested under R4.1 in development >> and >> > I succeeded to have a kernel log thanks to Marek and few hacks in dom0. >> > >> > Here is the bug report: >> https://bugzilla.kernel.org/show_bug.cgi?id=206299 >> > >> > FYI, I tried few months ago to build NVIDIA module under Qubes but I >> hit >> > a problem of allocating buffers. It was the same problem than a one >> > reported on NVIDIA dev forum by another person using Xen as a desktop >> > machine (not Qubes). >> > >> > Best, >> > >> > Frédéric >> > >> > On 2020-01-24 17:22, Ralph Alexander Bariz wrote: >> >> Have the same problem with a rtx 2070. My temporary solution is to put >> a cheap gpu into my pc(nvidia geforce 710) into the second pci port and cut >> of the power of the 2070 when using qubes. >> >> the problem is simple. The included nouveau driver does not support >> it. You could install the properitary one whats a security problem. >> >> my attemp to solve it, when I've got time, will be to compile the >> newest nouveau driver in a fedora 25 qubes and install it to dom0. >> >> For sure its necessary to ensure cube nit getting compromised in the >> process. >> >> >> >> BR >> >> >> >> -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/a697c22d-7392-4141-9424-2fd2a3556fa8%40googlegroups.com.
[qubes-devel] NVIDIA RTX 20XX
Have the same problem with a rtx 2070. My temporary solution is to put a cheap gpu into my pc(nvidia geforce 710) into the second pci port and cut of the power of the 2070 when using qubes. the problem is simple. The included nouveau driver does not support it. You could install the properitary one whats a security problem. my attemp to solve it, when I've got time, will be to compile the newest nouveau driver in a fedora 25 qubes and install it to dom0. For sure its necessary to ensure cube nit getting compromised in the process. BR -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/128a459c-0a11-469d-b95f-e95e9b292748%40googlegroups.com.
[qubes-devel] Encrypted /boot using GRUB LUKS module (workaround for anti-evil maid tpm 1.2 limitation)
Hi, Since I've got a TPM 2.0 and cannot downgrade it to 1.2 I'm at risk for evil maid attacks. When using Arch or debian, I used an /boot contained in LUKS+btrfs and the GRUB LUKS module. For sure, I realize that also GRUB can get tempered with, BUT 1.) it gets unloaded when kernel takes over 2.) it can only communicate with kernel using specified interfaces (as far as I know it cannot make the kernel connect to anywhere and send stuff without injecting code) 3.) it could inject code into kernel or initramfs if it would know it exactly(what could somewhat get disarmed by using checksums at boot and halt system if they do not match) or it searches stuff, what would be recognized because of taking time. So basically the idea is not to prevent evil maid, but to make it harder by forcing attacker to access system a second time for key recovery unless attacker knows the system very well. In combination with rebuilding EFI partition and cleaning partition table and unused diskspace every time at boot, evil maid attacks might get somewhat pointless. So my question ist basically, is there anything preventing to do this as done with arch and debian? And if no, how to do that in a way whole community could benefit of? BR Ralph -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/10721ac8-7eb9-4b5a-a779-569c5a65aa39%40googlegroups.com.
[qubes-devel] sys-usb and usb hid devices
Hi, When setting up sys-usb and still using usb hid devices, I noted: * setting gets written to xen.cfg on efi partition... right? isn't this an invitation for an easy to do evil maid attack combined with a compromised usb device? If at least it would be part of initramfs so it is not that easy to temper with as starting an text editor. (for sure, it's meaningless if you add proper anti evil maid protection) * it seems you can not define which usb devices are allowed. So I really would appreciate if I would be able to pin hid down to a certain keyboard and a certain mouse. If one of both gets broken, I don't mind to offline boot from a live system mount root and change filter for using the new device if that increases security. again for sure this would not be an absolute protection but would make tempering with the system harder since you'd have to manipulate the keyboard/mouse instead of inserting an internal device into computer case. cloning the permitted ids would not work out well since the system then would find two devices using the same id as soons as you connect the hid devices what might be noted(also system could notify if usb hid's are used or not). then you can easily recognize a tempered with system by seeing that there is a hid used without you having one connected. BR Ralph -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/1cb9be2d-fa3e-436e-ac34-79bd17b25764%40googlegroups.com.
Re: [qubes-devel] Encrypted /boot using GRUB LUKS module (workaround for anti-evil maid tpm 1.2 limitation)
PS: a few thought to evila maid protection well, if you think thats a good idea... I'd probably take it as a nice side project having following acceptance criterias: * systems kernel is located on encrypted partition, decrypted either by grub luks module or by a preload kernel which then boots encrypted kernel * building a permutating module on bootloader install hard linking it into encrypted kernel * modifying system in a randomized unpredictible way only named module knows * at boot, module does a checksum of memory allocated by bootloader * when check is passed, modify system how defined at module build * system hangs up showing a nice red warning screen if correct modification was not done by kernel * optionally, module outputs also a checkcode user can compare to an expectation(from bootloader install time) for visual verification of booting kernel BR Ralph Am Mittwoch, 15. Januar 2020 21:16:12 UTC+1 schrieb Marek Marczykowski-Górecki: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Wed, Jan 15, 2020 at 02:34:04AM -0800, Ralph Alexander Bariz wrote: > > Hi, > > > > Since I've got a TPM 2.0 and cannot downgrade it to 1.2 I'm at risk for > > evil maid attacks. When using Arch or debian, I used an /boot contained > in > > LUKS+btrfs and the GRUB LUKS module. > > For sure, I realize that also GRUB can get tempered with, BUT > > 1.) it gets unloaded when kernel takes over > > 2.) it can only communicate with kernel using specified interfaces (as > far > > as I know it cannot make the kernel connect to anywhere and send stuff > > without injecting code) > > 3.) it could inject code into kernel or initramfs if it would know it > > exactly(what could somewhat get disarmed by using checksums at boot and > > halt system if they do not match) or it searches stuff, what would be > > recognized because of taking time. > > Well, code injection is easier than you think. First of all, attacker > probably knows exactly what binaries you'll load - can download them > from the distribution repository. But even if not, the modified > bootloader can simply load different Xen binary. The only issue is, it > needs to find a space for that, but it isn't really hard. If the point > is short-time attack, one can even override some data, hoping to not hit > some crucial system part of the thing to be extracted. > > > So basically the idea is not to prevent evil maid, but to make it harder > by > > forcing attacker to access system a second time for key recovery unless > > attacker knows the system very well. In combination with rebuilding EFI > > partition and cleaning partition table and unused diskspace every time > at > > boot, evil maid attacks might get somewhat pointless. > > The above indeed make evil maid somehow harder, but not as hard as it > may look. > > I think you'll be much better with simply moving bootloader and /boot > into some external device you keep with yourself. > Anyway, if you still want it as an exercise, why not. > > > So my question ist basically, is there anything preventing to do this as > > done with arch and debian? And if no, how to do that in a way whole > > community could benefit of? > > I think in principle there should be nothing specific to qubes in such > configuration, so any guide that would work on Fedora, should work on > Qubes dom0. Or with a little modifications, any other guide. For > example: > https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html > I think the main difference here is lack of update-grub tool and the > need to call grub2-mkconfig -o /boot/grub2/grub.cfg. > > - -- > 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- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl4fcwQACgkQ24/THMrX > 1yzOyAf8CXv6qWn12GnGslUxiGz3GeHBYI7hxlQKFlvmqihCtCfe38iUXD6o1/fM > f4UWGKwHpb/v1Wk+KRfhDDPcVCxdOhMtt70/sRf3XmafgNitzT9A4VGWi/YCgTz9 > uwerNQDutcp7xTnpsqY66GtB+6drPOfbxi0I6gmIOpxIYQIkfEBPcgzLbXCkzYCM > peFZKRWLfko64ahgqLGLuImZTC6a1h5gQcnFpN2oJFUEH1r+qXzKnyrtrz498Vp8 > px0VBjchUMLK/h+3g4ku/Wgd2TvMO4AmB/q7WMlpfXfnzELFS2TN3dHaolEDrE25 > RveUY61Yu/4EgJBjNIWBzV450dTKrA== > =zpX4 > -END PGP SIGNATURE- > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ecd155e3-f62a-45aa-a93c-cf42fb5cc90d%40googlegroups.com.
Re: [qubes-devel] Encrypted /boot using GRUB LUKS module (workaround for anti-evil maid tpm 1.2 limitation)
Hi, After reflecting about my needs and your answer I did it that way. Well almost. Since I want to have sys-usb vm I had to bend efi partition beeing an image file located in root. (Installed with efi on USB, after installation before restart switching to console, dding the efi partition to /efi.img and editing fstab. doing this then the sys-usb setup after reboot works out well. the only issue, you have to copy efi.img to a vm and flash it to usb key each time... probably you want to create an automatism for that, it avoids a tradeoff between evil maid protection and usb security) BR Am Mittwoch, 15. Januar 2020 21:16:12 UTC+1 schrieb Marek Marczykowski-Górecki: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Wed, Jan 15, 2020 at 02:34:04AM -0800, Ralph Alexander Bariz wrote: > > Hi, > > > > Since I've got a TPM 2.0 and cannot downgrade it to 1.2 I'm at risk for > > evil maid attacks. When using Arch or debian, I used an /boot contained > in > > LUKS+btrfs and the GRUB LUKS module. > > For sure, I realize that also GRUB can get tempered with, BUT > > 1.) it gets unloaded when kernel takes over > > 2.) it can only communicate with kernel using specified interfaces (as > far > > as I know it cannot make the kernel connect to anywhere and send stuff > > without injecting code) > > 3.) it could inject code into kernel or initramfs if it would know it > > exactly(what could somewhat get disarmed by using checksums at boot and > > halt system if they do not match) or it searches stuff, what would be > > recognized because of taking time. > > Well, code injection is easier than you think. First of all, attacker > probably knows exactly what binaries you'll load - can download them > from the distribution repository. But even if not, the modified > bootloader can simply load different Xen binary. The only issue is, it > needs to find a space for that, but it isn't really hard. If the point > is short-time attack, one can even override some data, hoping to not hit > some crucial system part of the thing to be extracted. > > > So basically the idea is not to prevent evil maid, but to make it harder > by > > forcing attacker to access system a second time for key recovery unless > > attacker knows the system very well. In combination with rebuilding EFI > > partition and cleaning partition table and unused diskspace every time > at > > boot, evil maid attacks might get somewhat pointless. > > The above indeed make evil maid somehow harder, but not as hard as it > may look. > > I think you'll be much better with simply moving bootloader and /boot > into some external device you keep with yourself. > Anyway, if you still want it as an exercise, why not. > > > So my question ist basically, is there anything preventing to do this as > > done with arch and debian? And if no, how to do that in a way whole > > community could benefit of? > > I think in principle there should be nothing specific to qubes in such > configuration, so any guide that would work on Fedora, should work on > Qubes dom0. Or with a little modifications, any other guide. For > example: > https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html > I think the main difference here is lack of update-grub tool and the > need to call grub2-mkconfig -o /boot/grub2/grub.cfg. > > - -- > 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- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl4fcwQACgkQ24/THMrX > 1yzOyAf8CXv6qWn12GnGslUxiGz3GeHBYI7hxlQKFlvmqihCtCfe38iUXD6o1/fM > f4UWGKwHpb/v1Wk+KRfhDDPcVCxdOhMtt70/sRf3XmafgNitzT9A4VGWi/YCgTz9 > uwerNQDutcp7xTnpsqY66GtB+6drPOfbxi0I6gmIOpxIYQIkfEBPcgzLbXCkzYCM > peFZKRWLfko64ahgqLGLuImZTC6a1h5gQcnFpN2oJFUEH1r+qXzKnyrtrz498Vp8 > px0VBjchUMLK/h+3g4ku/Wgd2TvMO4AmB/q7WMlpfXfnzELFS2TN3dHaolEDrE25 > RveUY61Yu/4EgJBjNIWBzV450dTKrA== > =zpX4 > -END PGP SIGNATURE- > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/f1de07ed-62c2-4564-951e-802ffc72ef72%40googlegroups.com.
