Invitation to submit ideas for Google Summer of Code (GSoC) 2018

[Andrew David Wong]

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

In preparation for Google Summer of Code (GSoC) 2018 [1], we invite
the Qubes community to contribute ideas to the Qubes ideas list. [2]
You can find our 2017 ideas list here:

https://www.qubes-os.org/gsoc/

(This page will be updated for GSoC 2018.)

Please feel free to submit pull requests against that page or send
replies to this thread.


[1] https://summerofcode.withgoogle.com/
[2] https://summerofcode.withgoogle.com/rules/

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpVeyAACgkQ203TvDlQ
MDDLqhAAveoDz1WmjU8zQc/D9ZvFV02V9c49dGi5uRS61505daSizdXERNW/KeF2
jhEh8to/aJvqRSwPJLrJtC6FArArNVMwjm0ezuJN1nZwAzhntPr5aH+Pz1wwb6e4
AfdKjplZhUErBfqVnLMslZez/rKNjXMf9qtlHNxdjo+BPBtwtM7nhm0CCjcxb+2P
GcujFSPzphH/QvEqZij43Vy7DcMoFF4fwlOCcTukgnEFx2zkRt07yLZQ3N3k/J3Z
K1KesXkA4ZNvyxBCR69s6GhNNbUrDtFrdWJWmOJlbiPUqXQx4rxrTC9U6T4zZ7ZV
AlrH6XnyrKZ8o8aAIC2JMyupJjR5JRptxH3CQ3g0Bpc8OK6FOuVvxLfl734+tmfp
KzelTLbeqtLf2LffynB+m3h11MyhtiEaWKtxF8eQsXZW5D6LVYAh53da1+98mEEN
djBh+s/LZwRnoGKeByzWL/3vLO58y75OSZ8epHbA1XIJpIB7bSDOnS99zp0blyYW
dMOo66C6LXHgGYn3Lw2HoGPoZh5123FVjS7fb8TJ7/4nbfLQWW5lpsRz1wSN8qEh
O/XhGVThQftWn03zluLhwjPkIWx8LiU8J1nUyuwgoq9quVzIuyX7SosARYLBOAJ5
XrOIt2Ei8HRqKvlEbLJcsd9KEdCH4GGRXOov1UxgRbsJZ23L87c=
=KipJ
-----END PGP SIGNATURE-----

[Andrew David Wong]

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

On 2018-01-09 20:32, Andrew David Wong wrote:
> In preparation for Google Summer of Code (GSoC) 2018 [1], we
> invite the Qubes community to contribute ideas to the Qubes ideas
> list. [2] You can find our 2017 ideas list here:
>
> https://www.qubes-os.org/gsoc/
>
> (This page will be updated for GSoC 2018.)
>
> Please feel free to submit pull requests against that page or send
> replies to this thread.
>

You should also feel free to start a new thread for your idea,
especially if your proposal is a long one, or you'd like to keep the
discussion organized in its own thread.

>
> [1] https://summerofcode.withgoogle.com/ [2]
> https://summerofcode.withgoogle.com/rules/
>

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpVe9gACgkQ203TvDlQ
MDAwBQ//cKI++BRNChtSz6fTOSHm9+e75cVDCiePDETaNIAHvxlpBdrG72VZXVXr
UqyO3eUgZAxj3Gq6r7aXL9NUXjyxJlJ/88LPuG9xuc+DI6zruFFLQfhW0TkZEuXn
QIyQxTuwHNBqxvRL5m/38rlSThHMkiKMxQN1o/ORzx8OjD4Aty3ndo3IiJuFo3HC
PlMHX5zFsGvjJPtBxpoUh4GnYzFIOy/H5ku1xcjru9wItiHz6Ke3zHwhETfqMAWr
xjTiNWEygir6Sopskile/9FkBAuR1YkZAF5mSQ7KhIXrSSmrx7pE2kzobIM4Jiwe
1bcqVk2niZ7376T3VIT0vk/8dFlUrDBoVil/CPwT+L9WJcLowdl9QyCj4nPfA+jP
yi+TZQxsHllwHa++Dto+Hr44yZ+hge8984b8UHa8+FOkcrPuBfdOYncVnPuZtR45
Evdb96s8NsW4/bff2or+aNV8S/D0TL6GdAEpOVUEeyn75uFGPdE0spBb6VanhBJx
C92R5nXKrQOqY/RqqTsNwoiqhrScx9mNcvKAG4ySgMxTstrf7H19VMh+L4jI7Thp
t/dNr9a6k9VSmUT/sfonrR0soTCB0pWJCYEQvoLz3dpyXdipiy+QfDTmlnb/nGqx
kzRK+sqAknV2qAlTQz/bv/yUYgzzfYoMPPJwWqUvg2tUSOSmEKk=
=SL5u
-----END PGP SIGNATURE-----

[Blacklight447]

I might have some ideas,

How about intergrating a dispvm as usb qube. The situation now is (to my knowledge, correct me if I am wrong) that if a usb infects the usb qube, it means all future usb`s may become infected too once they connect to sys-usb. By using a dispvm, all traces of malware should be gone the next time it reboots(or atleast raise the bar of difficulty to make persitent malware)

I can think of several ways this can be implemented but the question will be when the usb qube should be rebooted. Everytime a usb disconnects, maybe everytime the computer reboots? These would be some things to figure out.

My next idea would be to have an option during installation to use a mirage os unikernel for sys-net or sys-firewall. This would give us severel advantages over the current fedora sys-nets.

Number one would be ofcourse security, a unikernel has alot less attack surface because it uses alot less code, this also makes it easier to audit. Furtermore, less memory useage might be an advantage as well, since you can run a mirage vm with a mere 30mb of ram(good for users with low end machines). Another advantage would be faster boot up and shutdown times, booting a mirage vm on my old thinkpad takes roughly 1/2 seconds.

Anyway these are my ideas of how we could improve qubes. These are all speculations based of my current knowledge and understanding of qubes, so please feel free to correct me if I was wrong somewhere. So, what do you think?


Cheers,
Blacklight447

[Marek Marczykowski-Górecki]

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

On Wed, Jan 10, 2018 at 03:19:39AM -0500, Blacklight447 wrote:
> I might have some ideas,
>
> How about intergrating a dispvm as usb qube. The situation now is (to my knowledge, correct me if I am wrong) that if a usb infects the usb qube, it means all future usb`s may become infected too once they connect to sys-usb. By using a dispvm, all traces of malware should be gone the next time it reboots(or atleast raise the bar of difficulty to make persitent malware)
>
> I can think of several ways this can be implemented but the question will be when the usb qube should be rebooted. Everytime a usb disconnects, maybe everytime the computer reboots? These would be some things to figure out.

Well, as for "everytime the computer reboots", it should be trivial in
Qubes 4.0, simply create sys-usb with a "DispVM" class and you're good.

Please remember that GSoC idea should be a base for "3 months project".

If we want more frequent sys-usb restarts (with sensible security), it
would require USB controller supporting reset (FLR or similar). Which on
current Intel hardware isn't the case :(

But, something similar - sys-net restart, could be better project. Many
network adapters either support FLR or are connected on separate PCI bus
- - which also allow resetting them. So, restarting it more often could be
an improvement. And there is definitely more work with this:
- solve https://github.com/QubesOS/qubes-issues/issues/1426 (which
itself may be 1 month of work or so)
- design and implement mechanism to safely store network access
credentials (so, DispVM based sys-net couldn't use it for persistent
compromise)
- add some automation for easily use this feature

> My next idea would be to have an option during installation to use a mirage os unikernel for sys-net or sys-firewall. This would give us severel advantages over the current fedora sys-nets.

Not sure about sys-net (you need device drivers there, and I don't think
there are many for mirage os), but sys-firewall is a good idea. There is
already implementation of static firewall approach there. We already
have this project on the list:

https://www.qubes-os.org/gsoc/#unikernel-based-firewallvm-with-qubes-firewall-settings-support

> Number one would be ofcourse security, a unikernel has alot less attack surface because it uses alot less code, this also makes it easier to audit. Furtermore, less memory useage might be an advantage as well, since you can run a mirage vm with a mere 30mb of ram(good for users with low end machines). Another advantage would be faster boot up and shutdown times, booting a mirage vm on my old thinkpad takes roughly 1/2 seconds.

Another project could be MirageOS based split gpg. I've seen on 34c3
someone with very interesting unikernel-based projects, including
ssh-agent, some basic GUI support and more.

- --
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/THMrX1ywFAlpWE+wACgkQ24/THMrX
1ywguQgAiySs4lj0M31OiZouvJBvC1nQ47WL7wr+JXrt1NXtspXlzm4X4uwucmdF
SJHdkwITXxnEIzfiYTblWAM6Z3ApJbBym59tbmLvoQfyo8YrTQreIid8Iv+X9mnQ
qAqGIWPknKiSxZzmc0up7XosqGULv0gmCjIA9l4rwRAmRuZoEZ1aDFzZJyHdlKfz
0CcZ+NAEUC172NBHSoTQQkBWpLKmYO8wvPMvIkMGyeyaEQ+v8a/uDs8v1xK5Mme5
xhmEWvDMDq7dJ3ZGqHEjnXuFm4F6mqM0TeTo5zljeKNH1gy1mwN42X3ZB03Hk3zm
oFBbOYGnP3+/tfOjoUbqTW5C0KcXcg==
=x8jM
-----END PGP SIGNATURE-----

[Grzesiek Chodzicki]

Easier management of inter-VM networking. Currently in order to enable outside access to a service running within a qube the user needs to code a separate iptables rule for sys-net, sys-firewall, the target qube and a vpn qube if the user happens to use one. Being able to just select a qube and just input the required port number/range with all iptables-stuff happening automagically would be a blessing. Same goes for allowing inter-vm networking. Being able to do that via GUI or with a simple command would make things so much easier.

[Andrew Clausen]

Hi all,

I propose a GSOC project to implement more converters (like the Qubes PDF converter).  For instance, converts for

 * documents (such as Word) with pandoc

 * video files with ffmpeg

 * audio files with sox

 * archive files (such as zip) -- perhaps this should work recursively?

 * other formats, such as spreadsheets, databases, web browser bookmarks, ...

Cheers,
Andrew

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/e8ef9142-778a-a0a2-8312-7dc2570d43d7%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[Tom Zander]

On Wednesday, 10 January 2018 02:32:02 GMT Andrew David Wong wrote:
> In preparation for Google Summer of Code (GSoC) 2018 [1], we invite
> the Qubes community to contribute ideas to the Qubes ideas list. [2]
> You can find our 2017 ideas list here:

Here is a suggestion that may be fun, it will certainly be useful.
Not specifically aimed at GSOC, just an idea I had some weeks ago, something
that needs to be done one way or another :-)


# Modernize painting pipeline

The Qubes design is that each virtual machine runs its own xorg server and
applications running on that VM paint into a specially crafted device
driver.
Changes are sent as pixmaps to the actual user-visible xorg server creating
the illusion of all applications running on one desktop.

Since the rise of GPUs available for everyone, the design of painting in a
pixel-buffer is outdated and modern GUI toolkits are severely slowed down in
the Qubes pipeline as it is today.
A Graphics Processing Unit (GPU) is dedicated hardware for updating your
screen, most CPUs ship with a GPU on-board today. The actual operations that
modern toolkits give in order to create their graphical windows is
dramatically different on such systems and as a result it is sub-optimal to
force them through a pixmap causing slow refreshes.

The task is to research a way to build an xorg driver (using open source
libraries like mesa) which can be used inside of an embedded virtual machine
for applications to draw into.
The information (does not have to be pixels!) gained from that should be
possible to send over a connection to our GUI virtual machine (currently
dom0) for display where the scene should be rendered using opengl based
instructions.

A bit of background to explain the actual problem;
Imagine a list of an address-book. A picture and some text and some lines.
In the old style painting the GUI would be drawn using 1 thread, into a
pixel buffer. It would loop over each person in the address book and draw
the picture, then the text then the decorations.
This is how Qubes operates now.

Using a GPU this can be sped up immensely by realizing that starting a
stream of instructions is what takes the time on such hardware, executing
the instructions happens totally inside of the GPU.
The toolkit would first paint all the backgrounds. Then it would set a
different pen and paint all things in that color, which in our case would be
the decorations.
Notice that we no longer loop over each address-book item, they are all done
at the same time.
The border around a picture is drawn by drawing a black square and last the
images of the users are drawn on top of that.

The main thing to notice is that this new way of doing things has as a side-
effect that many pixels are overwritten many times. This is not a downside
if it happens completely in the GPU, but you do notice this effect in the
Qubes pipeline.

This new approach allows modern toolkits to update their GUI and reach a 30-
frames-per-second update strategly, even on modest hardware. So it really
works, and the goal is to build on top of that and make Qubes GUIs much more
perform ants as well.


Expected results:

* A proof of concept application which uses two xorg servers and running an
opengl aware app (Any Qt5 application) in one will show its window in the
other while sending mostly opengl instructions and a minimum of bitmaps over
the connection.


Knowledge prerequisite:

* Programming in C
* opengl and xorg experience are highly useful

--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

[Marek Marczykowski-Górecki]

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

Yes, this is interesting direction for research. I'd throw wayland into
that picture - it may make things much easier.
The key point here is to keep it simple and secure. For example allowing
VM to send commands directly to GPU could be very bad idea, because such
VM could steal whole screen content. Intel GVT-g[1] (formerly Xen-GT) could
be interesting here, but also needs to be properly evaluated.

Related ticket:
https://github.com/QubesOS/qubes-issues/issues/3366

[1] https://01.org/igvt-g

- --
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/THMrX1ywFAlpYHTsACgkQ24/THMrX
1ywcnQf/bk9i7IVanLQjQ1jPE239fT7CeA1204PAfBVnG8pWkwebv494WY2PoLI6
C1I6JLH4PBqrqiO40z85O3ivNN5VP1AP9PCbJzH+KGNzpsahdvt98QJQMqyH0gU2
bki6yN/IaIeVBsu4w/DD8+X9zMaFqOe3k3sxZaQ/Sjp8I7sNXRwIHyDSvRX8jNLi
zACXfyIvRDoGtlgBtJv7aQ00uL3Hw51WbSjHOQIFfowCEgZcshLJil8tey+XCUrj
Gdm7xqEfzmnwGRUChnywQN8ZxVvpT5UPhNkOZ5GVAVhkCWxJM6pfqm6oxbl31PLl
1hip9q6mj0Dh6LT8vW01XsJt6L2k8w==
=v2zK
-----END PGP SIGNATURE-----

[Blacklight447]

Yes, this is interesting direction for research. I'd throw wayland into that picture - it may make things much easier. The key point here is to keep it simple and secure. For example allowing VM to send commands directly to GPU could be very bad idea, because such VM could steal whole screen content. Intel GVT-g[1] (formerly Xen-GT) could be interesting here, but also needs to be properly evaluated. Related ticket: https://github.com/QubesOS/qubes-issues/issues/3366 [1] https://01.org/igvt-g - -- 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/THMrX1ywFAlpYHTsACgkQ24/THMrX 1ywcnQf/bk9i7IVanLQjQ1jPE239fT7CeA1204PAfBVnG8pWkwebv494WY2PoLI6 C1I6JLH4PBqrqiO40z85O3ivNN5VP1AP9PCbJzH+KGNzpsahdvt98QJQMqyH0gU2 bki6yN/IaIeVBsu4w/DD8+X9zMaFqOe3k3sxZaQ/Sjp8I7sNXRwIHyDSvRX8jNLi zACXfyIvRDoGtlgBtJv7aQ00uL3Hw51WbSjHOQIFfowCEgZcshLJil8tey+XCUrj Gdm7xqEfzmnwGRUChnywQN8ZxVvpT5UPhNkOZ5GVAVhkCWxJM6pfqm6oxbl31PLl 1hip9q6mj0Dh6LT8vW01XsJt6L2k8w== =v2zK -----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...@googlegroups.com. To post to this group, send email to qubes...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180112022811.GI2653%40mail-itl. For more options, visit https://groups.google.com/d/optout.



Wouldn't wayland also increase the security of the screenlocker in dom0?

[Tom Zander]

On Wednesday, 10 January 2018 02:32:02 GMT Andrew David Wong wrote:

> Please feel free to submit pull requests against that page or send
> replies to this thread.

I have an idea for a standalone project that should be easy enough to setup,
but for a student it may be challenging enough to last a couple of months.

The problem we want to solve;

since v4.0 each and every VM has their own homedir. This is great for
security, but it is not so great for usability.
The main issue is that configurations in user configs (from .bashrc to your
favourite text editor config settings and Firefox bookmarks) are not shared
between qubes.
In various cases this is intentional. Some VMs just need to work
differently. In many others it is just annoying to have to re-apply a change
in config, or not have available that bookmark in all qubes.

The beauty of Linux is that practically all config files are plain-text. As
such we can make sure with only minimal effort that if we were to auto-copy
config files between qubes that we do not introduce any security issues.

The task;
create a setup where each VM has a hidden directory with a git repository
that we will be copying the config files into. Add a new qube which runs a git
server like gitolite. On the server side you need some checks in a git push-
hook that rejects any changes that could be a security issue. Executable
files, non-text files etc.

Then as a 3rd component each participating qube needs an application to look
for the default locations for config files. Typically ~/.config, and allow the
user to configure which ones they want to share between qubes.

Communication between qubes and the central gitolite server can happen over
qrexec, or maybe over a mapping in the firewall.

The result should be that changes in a known set of config files can be shared
automatically between qubes, fully automated.

Stretch goal may be to have the application that looks for changes in config
files use Linux features that notify you of any changes made in monitored
directories. This avoids using CPU periodically to check for changes.


Required knowledge;
git and some programming language (python or something else, depends on
what the mentor accepts).
You need a Qubes computer set up.

[awokd]

On Fri, January 12, 2018 11:10 am, 'Tom Zander' via qubes-devel wrote:
> The beauty of Linux is that practically all config files are plain-text.
> As
> such we can make sure with only minimal effort that if we were to
> auto-copy config files between qubes that we do not introduce any security
> issues.
>
> The task;
> create a setup where each VM has a hidden directory with a git repository
> that we will be copying the config files into. Add a new qube which runs
> a git server like gitolite. On the server side you need some checks in a
> git push- hook that rejects any changes that could be a security issue.
> Executable
> files, non-text files etc.

Securing this sounds hard, but could the existing update proxy system be
utilized for this?

[Tom Zander]

On Friday, 12 January 2018 11:21:27 GMT 'awokd' via qubes-devel wrote:
> Securing this sounds hard,

My thinking is that using something like git controls setting files
executables bits, serverside. So you can't magically get a new executable
scripts in your homedir.
Next its pretty easy to write a convert app that scans config files for non-
ASCII content and maybe something like pointing to non-local paths (HTTP
etc).

As such I figured this seals off any attack vector as the *only* thing you
will let in are plain-text files with non-executable payload.

Do you see any other attack vectors?

> but could the existing update proxy system be
> utilized for this?

Possibly, at minimum the qrexec communication channel should be the same and
the reason I suggested gitolite is because there is no reason to try and re-
invent all the tech that already exists.
Specifically; synchronizing n editable copies of a file (where n > 2) is non-
trivial and git solved it. Why not use that. :-)

[awokd]

On Fri, January 12, 2018 1:12 pm, 'Tom Zander' via qubes-devel wrote:
> On Friday, 12 January 2018 11:21:27 GMT 'awokd' via qubes-devel wrote:
>
>> Securing this sounds hard,
>>
>
> My thinking is that using something like git controls setting files
> executables bits, serverside. So you can't magically get a new executable
> scripts in your homedir. Next its pretty easy to write a convert app that
> scans config files for non- ASCII content and maybe something like
> pointing to non-local paths (HTTP etc).
>
> As such I figured this seals off any attack vector as the *only* thing
> you will let in are plain-text files with non-executable payload.
>
> Do you see any other attack vectors?

I was thinking of some type of Shellshock exploit but nevermind, I think
as long as those plaintext configs are sanitized somehow it should be OK.

[Marek Marczykowski-Górecki]

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

Well, such sanitization would need to be application specific, and would
be *very* fragile element. For example .bashrc is a plain ASCII file, not
executable (as of permissions), but allow you to execute any command
placed in there. There are a lot more such places.
I don't believe it would be possible to write working, generic enough,
verifier for such config files.

The problem here is verification of potentially malicious change sent by
untrusted VM. But if we could avoid the "untrusted" part, it would be
better. For example have a single VM (template?) used to configure
applications, and have some mechanism to selectively share those files
with different VMs. For new VMs, you can use /etc/skel - it is used to
initialize home of newly created VMs.

One thing that comes to my mind is salt management stack, which have
exactly this purpose - manage configuration. See here for some
documentation and examples:

https://www.qubes-os.org/doc/salt/
https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html

The issue with salt for broad usage is that it require some skills to
write such configuration. So, maybe a tool to help with that could be
useful? Like generate it automatically? Or provide ready to use
snippets?

- --
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/THMrX1ywFAlpY0c8ACgkQ24/THMrX
1yzTZgf8Cpb5uQX4PwEcJLPL4oBr52nGoD7am6U9b26UlkPKytnCudhr5lGJUhLa
clQ/TAHlHX40er0YMDGE1t7nfsfrY/FsLjZ1BtJCD+T6K77vfwdlQ15HGdkDS/mK
A5Ja7TUxoQZi7l1lMmvi3AQAtW6A2yaHaKI54vETndbqgLzSUldQ3zc5/I5MzBl5
ea2hmnw8XWnPReTnrZH0qmlHyVQl5JME6aCduGxoPaZdE3d7JNKtSnrl49iQiTQv
Zmdm4iha43p55u+17HTuFkLoXLiiYI77lZ2PNXB2547QgjLxv10k3CyMR5Ndlj+e
jMIPlTJq89IZVoXf5WqsZu+NUXXmkQ==
=qWzh
-----END PGP SIGNATURE-----

[Tom Zander]

On Friday, 12 January 2018 15:18:39 GMT Marek Marczykowski-Górecki wrote:
> Well, such sanitization would need to be application specific, and would
> be *very* fragile element. For example .bashrc is a plain ASCII file, not
> executable (as of permissions), but allow you to execute any command
> placed in there. There are a lot more such places.

Bashrc isn't really a config file, it is literally executable code. I agree
that you don't want to leak that from a potentially exploited qube.

You say there are a lot of configuration files on your system that are
executables? I am a KDE user, and this is certainly not the case there. But
maybe my views are limited to the software I'm most familiar with. Would tou
be able to share your knowledge of applications that execute config files?

The idea is really mostly about "real" config files. In the truest sense of
the word. :-)
This is about many files in ~/.config dir.
Stuff I'd love to get synced are dolphinrc (file browser config), balloofilerc
(desktop-search, specifically turning it off), kcalcrc, okularrc (pdf
viewer), gwenviewrc (imag viewer), gtk-3.0/settings.ini, terminal
settings...

That was the goal, sorry for confusing stuff and making you think this is
about shell scripts. It is not.

> I don't believe it would be possible to write working, generic enough,
> verifier for such config files.

This is only if you want shell scripts and similar execuable code,
lets not call bashrc a config file.

Actual config files are lists of key/value pairs, nothing that will ever be
treated as "code".

> The problem here is verification of potentially malicious change sent by
> untrusted VM. But if we could avoid the "untrusted" part, it would be
> better. For example have a single VM (template?) used to configure
> applications, and have some mechanism to selectively share those files
> with different VMs. For new VMs, you can use /etc/skel - it is used to
> initialize home of newly created VMs.

Please be aware that /etc/skel is an extremely limited solution to the point
where I don't even consider it a "solution" for the situation that was
outlined in the original task.

Qubes is great in that it allows us to limit certain usages to certain
domains. You can end up with a dozen almost identical domains where the only
real difference is the data that is stored in it.
But with the addition of each individual qube you highten the mental load
and dumb maintainance work when it comes to configuring and using the tools
that you have and use in many of them.
This GSoC project is meant to take the brunt of that burden and allow users
to treat those file browsers and similar apps as
"configure once, run anywhere".

> One thing that comes to my mind is salt management stack, which have
> exactly this purpose - manage configuration. See here for some
> documentation and examples:
>
> https://www.qubes-os.org/doc/salt/
> https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html

The page you linked to makes me question how useful it would be;
From the qubes docs;

> Salt is a client-server model, where the server (called master) manages
> its clients (called minions). In typical situations, it is intended that
> the administrator interacts only with the master and keeps the
> configurations there. In Qubes, we don’t have a master. Instead we have
> one minion which resides in dom0 and manages domains from there.

Having exectly one minion on the entire system doesn't make it a management
stack.

The salt stuff is so unifinished and unusable that basing a GSoC on it sounds
very irresponsible to me.

[Tai...@gmx.com]

Perhaps a method to change the presented screen resolution in a VM to
make browser fingerprinting more difficult?

[Marek Marczykowski-Górecki]

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

On Sat, Jan 13, 2018 at 05:22:11PM +0000, Tom Zander wrote:
> On Friday, 12 January 2018 15:18:39 GMT Marek Marczykowski-Górecki wrote:
> > Well, such sanitization would need to be application specific, and would
> > be *very* fragile element. For example .bashrc is a plain ASCII file, not
> > executable (as of permissions), but allow you to execute any command
> > placed in there. There are a lot more such places.
>
> Bashrc isn't really a config file, it is literally executable code. I agree
> that you don't want to leak that from a potentially exploited qube.
>
> You say there are a lot of configuration files on your system that are
> executables? I am a KDE user, and this is certainly not the case there. But
> maybe my views are limited to the software I'm most familiar with. Would tou
> be able to share your knowledge of applications that execute config files?
>
> The idea is really mostly about "real" config files. In the truest sense of
> the word. :-)
> This is about many files in ~/.config dir.

Ok, lets start with ~/.config/xdg/autostart/*.desktop. "files with
key/value pairs", right? Those don't have executable bit either.

> Stuff I'd love to get synced are dolphinrc (file browser config), balloofilerc
> (desktop-search, specifically turning it off), kcalcrc, okularrc (pdf
> viewer), gwenviewrc (imag viewer), gtk-3.0/settings.ini, terminal
> settings...

Does ~/.local/share also counts? This is for example where "konsole"
keeps profile settings - you want to keep them, right? If so, lets see
what happens when you modify ~/.local/share/konsole/default.keytab and
add this line:

key Return : "\necho this is totally not a code execution\n"

I'm sure you can be more creative in making it stealth.

I see there is also an option to configure what applications are bound
to different file types (a place to put a command), various dolphin
plugins and such. This is just result of 5 min search, I'm sure there is
more.

Yes, such thing would need also some kind of synchronization, not only
one time provisioning.

> > One thing that comes to my mind is salt management stack, which have
> > exactly this purpose - manage configuration. See here for some
> > documentation and examples:
> >
> > https://www.qubes-os.org/doc/salt/
> > https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html
>
> The page you linked to makes me question how useful it would be;
> From the qubes docs;
>
> > Salt is a client-server model, where the server (called master) manages
> > its clients (called minions). In typical situations, it is intended that
> > the administrator interacts only with the master and keeps the
> > configurations there. In Qubes, we don’t have a master. Instead we have
> > one minion which resides in dom0 and manages domains from there.
>
> Having exectly one minion on the entire system doesn't make it a management
> stack.

Well, the above is about configuring dom0. Since Qubes 3.2 it is also
possible to configure VMs. From the user point of view, every VM looks
like a separate minion, controlled from a single master. So, you can
apply your favorite dolphinrc to a group of VMs.

> The salt stuff is so unifinished and unusable that basing a GSoC on it sounds
> very irresponsible to me.

Salt documentation indeed could use some improvements, at least...

- --
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/THMrX1ywFAlpbxvYACgkQ24/THMrX
1yzIPAf/fUT7UdB8u24jbd5vdmfvRwKZfVWgrdP2Wnv3CLaT0+8Y9Ojh3rInS9jB
N1YPWzpvI23MUU8758Y8GpEpaK/9d+V7Z9athpbFCqbG21YdAgoNND0+yzXdSzSD
S2iKUiUTRco1uj3k0FUAQV3x0r+gins+XxZw9ebNVB+39C/y/bkJMVdReWGUsSws
+0zQogIf/fMZ4OqAVFhhncbtCUe5qc1oDLrIGW9MO97FunWu+UmHtZS8UgboWPE1
pyzRdowBFWobmcDcvXQiMLHyq8lizqmcD4bXJ4m7QszRJCu5Jr6ZA2rk0K5AsV/q
Tiwld1TPO3MHZcY8jk87SoRCPhEiAA==
=DPHJ
-----END PGP SIGNATURE-----

[Tom Zander]

On Sunday, 14 January 2018 22:09:10 CET Marek Marczykowski-Górecki wrote:
> Ok, lets start with ~/.config/xdg/autostart/*.desktop. "files with
> key/value pairs", right? Those don't have executable bit either.

I'm not sure why you are trying really hard to misunderstand me :(

I wrote that this is a project about _config_ files. I wrote the _intention_
of those files and I even specifically wrote about how things that get
executed are _not_ to be copied.
.desktop files are not config files. Shell scripts are not config files.

I don't understand why you trying so hard to misunderstand the goal?

None of the items you bring up fall within the concept I presented as a
configuration.
Yet you bring them up like they are reasons to reject the idea for a GSoC
project...

Investigating which files are secure to (not) include should definitely be
part of the GSoC. Its a learning project for students, research is a useful
part of any GSoC project.

> > Having exectly one minion on the entire system doesn't make it a
> > management stack.
>
> Well, the above is about configuring dom0.

I think you misunderstood, nothing in the original proposal would ever need
touch anything in dom0.

[Marek Marczykowski-Górecki]

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

On Sun, Jan 14, 2018 at 11:54:38PM +0100, 'Tom Zander' via qubes-devel wrote:
> On Sunday, 14 January 2018 22:09:10 CET Marek Marczykowski-Górecki wrote:
> > Ok, lets start with ~/.config/xdg/autostart/*.desktop. "files with
> > key/value pairs", right? Those don't have executable bit either.
>
> I'm not sure why you are trying really hard to misunderstand me :(
>
> I wrote that this is a project about _config_ files. I wrote the _intention_
> of those files and I even specifically wrote about how things that get
> executed are _not_ to be copied.
> .desktop files are not config files. Shell scripts are not config files.
>
> I don't understand why you trying so hard to misunderstand the goal?
>
> None of the items you bring up fall within the concept I presented as a
> configuration.
> Yet you bring them up like they are reasons to reject the idea for a GSoC
> project...
>
> Investigating which files are secure to (not) include should definitely be
> part of the GSoC. Its a learning project for students, research is a useful
> part of any GSoC project.

I'm trying to show you how things one can consider a configuration, may
enable you to compromise a VM. Writing a tool that automatically verify
that given configuration is "safe" will be specific to each
configuration file and because of this, will scale poorly (you will end
up with a short list of supported applications). You can consider manual
verification (asking the user whether to propagate specific config
change), but you'll loose "fully automatic" property then.

> > > Having exectly one minion on the entire system doesn't make it a
> > > management stack.
> >
> > Well, the above is about configuring dom0.
>
> I think you misunderstood, nothing in the original proposal would ever need
> touch anything in dom0.

That's alternative approach to the same problem, which may co-exist with
something else. With salt you can have dom0 enforcing some particular
configuration in VMs.

- --
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/THMrX1ywFAlpb6EIACgkQ24/THMrX
1yywgQf+MmlzHi/P2tIv/BavRMfQYyFF4G/L5K7Buszb0Ietb528FZOj48HgeuBZ
ymuMIjduCdZCOplVtPZy8QrgJdprZjkokESpz3K1ZkMG32TnG5+IyjdSKmondUf8
E6LxwugRRIlbswd3YFyZSkE9tNx4EXz3NNYOWONAtCyVjZ1n6BLSKohHPzCGvs1G
k80VwO0VAFFfKIJBjdRsqAUbgvzsE8BknWb9aEzrQNpFyV89JBDRne1kBiCYEnt/
Y5nvVvZ11DGp4UUwDTy2/8XP4OE6Tmv9D4WetkeewXBHzC6DTwrc+76zzZBenOPV
QeoThc9VE5nPWSdb7L77rn6Jd/w7sA==
=P6DC
-----END PGP SIGNATURE-----

[Tom Zander]

On Monday, 15 January 2018 00:31:14 CET Marek Marczykowski-Górecki wrote:
> I'm trying to show you how things one can consider a configuration, may
> enable you to compromise a VM.

This may show the underlying reason for the mis-communication.

What is considered a configuration is not really open to discussion, it is
well documented and there are specifications on freedesktop.org and wikipedia
of most of this stuff.

So, I see why you are saying the above; you have been thinking about a lot
more file-types and I understand you feel uncomfortable about shell scripts
and many others.

Maybe just to get a better idea, I think if you limit yourself to
~/.config/*rc
you'll have a more specific set of the actual subject matter.

Hope that explains this better.
If you feel uncomfortable with it, it was just an GSoC project-idea, no harm
done if you ignore it.

[Joseph Taylor]

Building off of the work done on Anti-Evil Maid last year, it would be beneficial to upgrade AEM to use more up to date packages, in particular to support TPM2.0. It's extremely difficult to find a device that is new (important due to increased risk of persistent malware in used hardware), supports TPM1.2, supports all of the relevant hardware virtualisation features and is fully supported by Qubes. Meanwhile Microsoft mandates TPM2 support in all modern machines shipped with Windows, and increasing use of VT-d by Windows, increasing availability of VT-d on consumer chips and talk of Microsoft mandating VT-d support will likely make VT-d much more widespread on modern hardware, so TPM2 systems with the relevant hardware are easier to find and will only be easier still in the future. As an added bonus that moves us from SHA1 to SHA2 or potentially even SHA3 in the future, in addition to offering some more capabilities in the TPM.

 

Adding touchscreen support would be a good project too - by which I mean adding support to the GUI protocol such that VMs are aware of touchscreen events rather than emulated mouse events created by dom0 from touch events. Ideally this would allow, say, a full screen Windows VM to receive Wacom or Ntrig stylus events and do its own palm rejection, as well as appropriately triggering its own on screen keyboard. This would give Qubes sufficient touchscreen support for most use cases without requiring significant changes to dom0. Worthwhile noting is that the remainder of support would come for free with Gnome support (which is already on the agenda) - giving dom0 an onscreen keyboard, and what's left (e.g. triggering dom0 keyboard for guest VM text fields to make touch operation in seamless mode smoother) is probably an acceptable loss when considering the complexity (=security risk) of fully supporting those additional features.

Optimizing power consumption would be good too - this could include building on some of the community work on integrating power saving configurations into guests and reconfiguring Xen to operate more efficiently, to adding Qubes aware power saving features (e.g. auto-pausing inactive VMs, auto-resuming on re-focus, with a flag to prevent this behavior as needed for e.g. service VMs, for a potential idea). Combined with net and proxy VMs based on unikernels (which should also use less power) this could significantly improve Qubes battery life.

Beyond that, carrying forward untaken GSoC projects from the previous year, including Windows 10 support etc.

[bow...@gmail.com]

I have reviewed the list of existing ideas. One comment for Marek, I looked some time back at GPU path-through and dropped the sponge at the time as Xen was not providing the same level of isolation for a VM with GPU path-through (AFAIRemember it was possible to use Linux/Kerbel exploits to reach Dom0).

One idea (also might already be part of the DisposableVM for sys-net) was to have a VM initialization framework which would on boot copy Dom0:/.../VMName-rw to VMName:/rw, mount it... So that sys-net (or other dispVM static state could be loaded on boot (i.e. wifi password, iptables, etc...) while being protected from persistent attacks.
Benefit is that this config/code is not in the template and not visible to other VMs using this template. It is also not modifiable.

Other one: Head-less mode: You install Qubes on a server, with a PCI/NIC dedicated for the head and a VM with PCI-Bridge for that NIC. You have a second Qubes install, also with a dedicated NIC and VM. You can possibly safely connect your X server to the Qubes head-less server with a long wire between these 2 NICs. Physical security of the cable is assumed.

Other one: Proxy-VM. A number of Qubes users are decreasing the security of their system by installing packages/daemons in sys-firewall (tiny-proxy, dns-cache are good examples). If a proxy-VM was available with the correct iptables rules in sys-firewall to route egress/igress traffic. Users would not do stupid things.

Other one: to reach corporate, a pure "black box Windows install" would be required. By that I mean an install where, to the end user, Qubes looks like Windows 7. To the admin, a central git signed XML/json hierarchical policies server would manage the enterprise eco-system. Can't remember if the Windows licence allow for Disposable Windows VMs, LInux would be OK if again integration with Windows (i.e. Download automatically download to a Windows domain, etc...)

[bow...@gmail.com]

This is incorrect in the sense that are not looking at what Qubes does but the full pipeline. Qubes takes the approach that security flaws comes with complexity. It's principle is simple:
- The VM render it's UI (using whatever best method it has)
- Qubes copy the memory region which would have been displayed by the window manager of that VM and gives it to be displayed in a decorated window in Dom0 as an image.

This way the attack surface of Qubes code is very small. The copy operation of the array received which is not parsed on the receiving end.

A GPU is another computer in your computer attached with a bus. It has a firmware, run-time, memory, processor. Rootkits exists to attack the run-time and even to stay persistent in the GPU (not sure if these attacks are still possible on the persistence side)
Therefore Dom0 is the only OS that can have code running on it (until you have GPU hardware virtualization).

With systems with 2 GPU, you can have Dom0 using one (use the integrated one as you don't need the power for Dom0) and One single other VM (possible multiple in the same risk zone at different point in time) can use the other one. The output of that GPU going to another monitor.
Work could be done as part of Qubes to do the same and copy the memory area of the GPU that is the stream sent to the monitor (or a sub-region) and send it to Dom0 for rendering. You however have to do that without introducing too much latency and fast enough for that buffer to not have been refreshed to not drop frames. You also need enough BW on the bus to push the info across (so you won't be able to have 144Hz).

[Tom Zander]

On Saturday, 20 January 2018 10:14:00 CET bow...@gmail.com wrote:
> This way the attack surface of Qubes code is very small.

The proposal does not change the attack surface at all.
Reading on what you wrote below, I think you have misunderstood the proposal
to one of GPU passthrough.

> A GPU is another computer in your computer attached with a bus. It has a
> firmware, run-time, memory, processor. Rootkits exists to attack the
> run-time and even to stay persistent in the GPU (not sure if these
> attacks are still possible on the persistence side) Therefore Dom0 is the
> only OS that can have code running on it

Yes, I think you misunderstood the proposal, the GPU is not being shared or
made available to anyone but dom0 in the proposal. Making your worry
irreleavnt.
The proposal is made specifically to avoid needing to make the GPU available
for all Qubes.

[Tom Zander]

On Thursday, 11 January 2018 15:47:30 CET 'Tom Zander' via qubes-devel
wrote:
> # Modernize painting pipeline

A poster (Foppe de Haan) in the user mailinglist pointed out this project
called "Looking-glass" that is very similar to the (very naive) proposal I
made;

https://forum.level1techs.com/t/looking-glass-guides-help-and-support/122387

They seem to actually have a proof-of-concept post published last November
which shows that for GPU accelerated graphics this approach greatly speeds
up display without losing the benefits of speed over moving pixel-buffers.

Maybe the qubes-developers can check with them and see if they are doing
GSoC.

[bow...@gmail.com]

I don't think I have miss-understood. Your proposal is for the client VM to sent OpenGL instruction to the Dom0 GPU.
The attack surface is significantly larger (thousand times more lines of code and logic to verify, you would need formal verification).
I prefer to work a gaming PC on the side with a dedicated email address and credit card for my gaming/3d "life".

[Tom Zander]

On Saturday, 20 January 2018 15:03:38 CET bow...@gmail.com wrote:
> I don't think I have miss-understood. Your proposal is for the client VM
> to sent OpenGL instruction to the Dom0 GPU.

Your understanding isn't entire wrong, but you miss the subtleties.
Applying your description to webbrowsers javascript it is like you say it
allows code downloaded to be executed on your CPU.

Well, not wrong, but definitely not correct.

Like that javascript engine, you don't just execute any code anyone throws
at you on your privileged GPU. That would obviously be silly and completely
break the encapsulation xen provides.

The usecases I was talking about (hardware accelerated 2D rendering of
widgets and text etc) doesn't use shader applications, it certainly doesn't
freely program the GPU or give any sort of results back to the calling
application.
As we today render such screens using multi-threaded CPU based code into a
pixel-buffer with no visual artifacts (using mesa) you might follow my
thinking that taking the existing stack and replacing the part where it
renders into a pixel-buffer with forwarding commands to the GPU-using VM.

Due to the fact that such software rendering stacks exist, I postulate that
we have a very good chance of rejecting any unsafe GPU constructs.

This is why I went into the explanation of how painting currently works in a
hardware-accelerated toolkit doing its rendering. Because those simple
constructs are trivial to forward and much cheaper to transport from AppVM
to graphics-VM than pixels are.

Hope this makes it a bit clearer.

I won't have any time to work on this, I was hopeful some graphics savvy
people would be interested in making apps like Chromium and Qt5 based apps
again fast in Qubes. I know I would be very appreciative.

[bow...@gmail.com]

On Sunday, 21 January 2018 12:33:59 UTC, Tom Zander wrote:
> On Saturday, 20 January 2018 15:03:38 CET bow...@gmail.com wrote:
> > I don't think I have miss-understood. Your proposal is for the client VM
> > to sent OpenGL instruction to the Dom0 GPU.
>
> Your understanding isn't entire wrong, but you miss the subtleties.
> Applying your description to webbrowsers javascript it is like you say it
> allows code downloaded to be executed on your CPU.
>
> Well, not wrong, but definitely not correct.
>
> Like that javascript engine, you don't just execute any code anyone throws
> at you on your privileged GPU. That would obviously be silly and completely
> break the encapsulation xen provides.
>
> The usecases I was talking about (hardware accelerated 2D rendering of
> widgets and text etc) doesn't use shader applications, it certainly doesn't
> freely program the GPU or give any sort of results back to the calling
> application.
> As we today render such screens using multi-threaded CPU based code into a
> pixel-buffer with no visual artifacts (using mesa) you might follow my
> thinking that taking the existing stack and replacing the part where it
> renders into a pixel-buffer with forwarding commands to the GPU-using VM.

OK understood now (limit to 2D square/line/bitmap/... rendering, obivously fonts will have to stay out ;) ).

>
> Due to the fact that such software rendering stacks exist, I postulate that
> we have a very good chance of rejecting any unsafe GPU constructs.
>
> This is why I went into the explanation of how painting currently works in a
> hardware-accelerated toolkit doing its rendering. Because those simple
> constructs are trivial to forward and much cheaper to transport from AppVM
> to graphics-VM than pixels are.
>
> Hope this makes it a bit clearer.

Yes very much.

So with the correct understanding I completely agree that the level of risk if far lower.

However I am not convinced that we have a real problem to solve. The current solution is fast enough to stream youtube videos.
The only application I can see is image editing of big 2D SVG diagram/plan... as 3D is starting to reach the border line (also as the pipeline is probably functional/"immutable" it may be applicable).

I prefer the idea of limiting the number of VM that can do 3D to the number of extra video card you have and stream the rendered output to Dom0 and be confident with my simple security model. But probably some people would be interested as it is a nice idea (as long as the safe option is present by default).

I like current Qubes philosophy which is to decompose the problem and apply simple solutions on the right edges. sys-firewall is the same, also I would remove state management in the firewall (only source/dest port and get the sequence number checking to the VM that is being protected so the attack surface is even smaller and I am even more confident that I can trust it).

Look at SELinux and how the blotted beast does not inspire any confidence :)

[Tom Zander]

On Sunday, 21 January 2018 22:19:37 CET bow...@gmail.com wrote:
> OK understood now (limit to 2D square/line/bitmap/... rendering, obivously

> fonts will have to stay out ).

Agreed, which is not a problem :)

The way font rendering works in, for instance Qt (basing this on the first
version years ago) is that a pixmap is reserved in GPU memory and as text is
being rendered into it character by character (glyphs, really).
Then when this same character is again needed, the command is given to copy
a small section of that pixmap into the correct place.
Your text-document rendering then becomes a pure in-GPU-memory operation of
plotting small sections of a larger pixmap onto screen.
Its insanely fast.

> > Due to the fact that such software rendering stacks exist, I postulate
> > that we have a very good chance of rejecting any unsafe GPU constructs.
> >
> > This is why I went into the explanation of how painting currently works
> > in a hardware-accelerated toolkit doing its rendering. Because those
> > simple constructs are trivial to forward and much cheaper to transport
> > from AppVM to graphics-VM than pixels are.
> >
> > Hope this makes it a bit clearer.
>
> Yes very much.
>
> So with the correct understanding I completely agree that the level of
> risk if far lower.

Awesome :)

> However I am not convinced that we have a real problem to solve. The
> current solution is fast enough to stream youtube videos. The only
> application I can see is image editing of big 2D SVG diagram/plan... as
> 3D is starting to reach the border line (also as the pipeline is probably
> functional/"immutable" it may be applicable).

If you use KDE5 for a while, you may change your mind.
When I first started to use Qubes I had to use XFCE4 and GTK and it felt like
going back to the 1980s. The user interfaces are just soo.... shocking and
simple.

If you add or remove a file in dolphin (in icon-view) the view adjusts by
moving smoothly the other files. This is especially useful if a file is added
by you saving it from a different app. You can see immediately what changed.
Not just that *something* changed, but the primitive part of your brain
understands without thought exactly what changed.
This kind of little usability touch are all over the place. Little
animations, small kinds of shading. A fade-in instead of a brutal change.
Those things have been proven by researchers to actually help people use
computers because its much closer to how the real world works.

The hard part is; it has to be done in a smooth stable framerate to avoid
losing the entire positive effect.

If I run this simple 'move icon to the left' animation inside of an AppVM
(at pretty big icons) I get rather annoying looking tearing effects. :-(

Not to mention the fact that on battery-using devices it will use a
magnitude more power than the solution outlined in my proposal.

Based on this I disagree that it is unneeded.

> I prefer the idea of limiting the number of VM that can do 3D to the

This proposal is not about doing 3D, but using a (GPU based) hardware
painting pipeline which is almost entirely 2D based.

> I like current Qubes philosophy which is to decompose the problem and
> apply simple solutions on the right edges.

I would say this fits right in. It is indeed re-using the current idea of
Qubes forwarding bitmaps to the graphics-card and upgrading it to reflect
that today's computers come with newer hardware and the pipeline we have
available can lead to huge gains.

[Michael Carbone]

On 01/09/2018 09:32 PM, Andrew David Wong wrote:
> In preparation for Google Summer of Code (GSoC) 2018 [1], we invite
> the Qubes community to contribute ideas to the Qubes ideas list. [2]
> You can find our 2017 ideas list here:
>

> https://www.qubes-os.org/gsoc/
>
> (This page will be updated for GSoC 2018.)
>
> Please feel free to submit pull requests against that page or send
> replies to this thread.
>
>
> [1] https://summerofcode.withgoogle.com/
> [2] https://summerofcode.withgoogle.com/rules/

Hi all,

Now is the time to start submitting pull requests against the doc file
for projects. The template is here:

https://www.qubes-os.org/gsoc/#project-ideas

Also please remove any projects that are no longer relevant, or if a
mentor is no longer able to mentor those projects.

Should we remove the 2017 projects from last year "Qubes MIME Handlers"
and "Making AEM protection..."? Or keep them up for further work to be
done on them?

Michael

[Marek Marczykowski-Górecki]

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

On Sun, Jan 21, 2018 at 06:35:25PM -0500, Michael Carbone wrote:
> On 01/09/2018 09:32 PM, Andrew David Wong wrote:
> > In preparation for Google Summer of Code (GSoC) 2018 [1], we invite
> > the Qubes community to contribute ideas to the Qubes ideas list. [2]
> > You can find our 2017 ideas list here:
> >
> > https://www.qubes-os.org/gsoc/
> >
> > (This page will be updated for GSoC 2018.)
> >
> > Please feel free to submit pull requests against that page or send
> > replies to this thread.
> >
> >
> > [1] https://summerofcode.withgoogle.com/
> > [2] https://summerofcode.withgoogle.com/rules/
>
> Hi all,
>
> Now is the time to start submitting pull requests against the doc file
> for projects. The template is here:
>
> https://www.qubes-os.org/gsoc/#project-ideas
>
> Also please remove any projects that are no longer relevant, or if a
> mentor is no longer able to mentor those projects.

On the other hand, if someone want to be a mentor, please let us know!

> Should we remove the 2017 projects from last year "Qubes MIME Handlers"
> and "Making AEM protection..."? Or keep them up for further work to be
> done on them?

I'd remove them.

- --
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/THMrX1ywFAlpl2WUACgkQ24/THMrX
1yw0nwf8CIwUso89h8EecKiS2NtLuBj2GIA3nESXPFzLqy0p3cWRC+rgR3IcBeVe
0ApmN0xO3Fb0KlzLSR3bcZxfBNgoe3SqOzC1SnntcErqGckCir3tKoFdTaJjbEPh
bl/A5UirUxda5MVZ0kgMjHe5/PIub0C3HoEgHOQ+zr3fNM2wY3GzGquozlSEZEgO
9oepnLzVQS84DO57SikwoVevaBLFokFdlLw6dSttbHZymjFKz+4eTwEnDtt3+GOQ
xEYH2+5prJIADTx02A5bh19+OPOVjQfc+qzpEiLyeMl2YHJoUCP/hdkHsIcm7uP2
bnZ6F0257okuiCrE5h54omjI5cuvlQ==
=VfFJ
-----END PGP SIGNATURE-----

[Raffaele Florio]

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

Hi all :),
During past months I worked on idea [0]. Currently it's supported only by Firefox and Chrome. The repo is at [1] and the qubes-issue regarding contribution message is at [2]. It was assigned to the 4.1 milestone.

I've a question about if is acceptable (in term of performance, specifically latency) to have some form of signed USB input, from a usbvm. A lot of laptop (the majority?) has only an USB controller and without reset capabilities. The most susceptible device, IMHO, is USB keyboard. So if it's possible to put a proxy USB signer device (e.g. a rPi Zero) between the USB keyboard and the usbvm, Dom0 could verify that input come from the signer device.
However thanks the Qubes 4.0 flexibility this necessity could be suppressed by "Qubes Air". Unfortunately I cannot try Qubes 4.0-rcX. I hope that the 4.0-rc4 hasn't any major problem. So it became the stable release, <3.


[0] = https://www.qubes-os.org/gsoc/#thunderbird-firefox-and-chrome-extensions
[1] = https://github.com/raffaeleflorio/qubes-url-redirector
[2] = https://github.com/QubesOS/qubes-issues/issues/3152

Best Regards,
Raffaele.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE9bU8N8AgwMcjiC1xjTxG+6f1ce4FAlpzBJgACgkQjTxG+6f1
ce7qcRAA2PCmR/KM5lhNvpmd3P9vp0SC8whx7C2VdNhhgCd1yd9t6eVMHLHTk3ti
7hVZWNmsfwqaF2fdlaLoYkXdlgO2AiUWTWvVwobYZzsycHTZRC7U5dekstkJTsc9
zbYs4MtKNQRjvuXh77Vc5/Sh7c5kUA+ODaQyPn6FuIpI9o9CoWjbIGGU6ADidXUV
uD1ZIjHWto5sjLvzJbrMIZo5yPC7/Ybpye7Q8bwIiQQjmrli6otB2/9w6OFjeZA6
gDxwT+qJ2gje37usi2qfAC4J4gSb20FVhftswntiOsZFHfy4wqsDB/lclHGBKiqi
+3ilRDQ94ZfQw9MuUnOA6skKkkTdDSNmymY/6UQFH7RZNU507MMzufQlJpYRbOLM
unBXS+Kx86cDaZ/UpDHEI1mWKdAhZwwDPTL0lr3DYDKdJKOlSCGFPZmcsMRL7gS5
NrwsioJsKo0jjq4VaKEtmv0VXk0myFNByr2P1zIbKYRzCMVnlt7nF3gXB/gIkrQl
Ei2+wInrk6HSHUQKhfi1rK5SQymvCcVSqHymHnTlmxzlZrbTsVkgUy/Unes46c7n
4k+j+SjLmkuvlEIUrvkR7P62nvShpU5JRKOr6RDmRX/10Y7lEHHMMrF0BK4HbFE2
VXRzqzsW2n1q++1nYoAIdBuW03AqDUy5V3rUa73RmPMkjOa+R9E=
=+COA
-----END PGP SIGNATURE-----

[Michael Carbone]

On 02/01/2018 07:16 AM, Raffaele Florio wrote:
> Hi all :),
> During past months I worked on idea [0]. Currently it's supported only by Firefox and Chrome. The repo is at [1] and the qubes-issue regarding contribution message is at [2]. It was assigned to the 4.1 milestone.
>
> I've a question about if is acceptable (in term of performance, specifically latency) to have some form of signed USB input, from a usbvm. A lot of laptop (the majority?) has only an USB controller and without reset capabilities. The most susceptible device, IMHO, is USB keyboard. So if it's possible to put a proxy USB signer device (e.g. a rPi Zero) between the USB keyboard and the usbvm, Dom0 could verify that input come from the signer device.
> However thanks the Qubes 4.0 flexibility this necessity could be suppressed by "Qubes Air". Unfortunately I cannot try Qubes 4.0-rcX. I hope that the 4.0-rc4 hasn't any major problem. So it became the stable release, <3.
>
>
> [0] = https://www.qubes-os.org/gsoc/#thunderbird-firefox-and-chrome-extensions
> [1] = https://github.com/raffaeleflorio/qubes-url-redirector
> [2] = https://github.com/QubesOS/qubes-issues/issues/3152

great, I missed this development! Shall I remove the Firefox/Chrome
extensions from the GSoC 2018 list of prospective projects, and keep the
Thunderbird extension there for now?

Michael

[Raffaele Florio]

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

Hi, I can also work on the Thunderbird extension.
However I've just submitted the Firefox extension to Mozilla for their signing.

Best Regards,
Raffaele.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE9bU8N8AgwMcjiC1xjTxG+6f1ce4FAlp0ercACgkQjTxG+6f1
ce69aw//dGUEpn6rhLDF3Z7FP/gFyfXA4XKwZkhnCuNlkY69XAOHzFQitWhM9fT3
oySZJy4n+s+pR5RJptnhFZcxcwrsyXWvontGR9h+2b754+YzdiIDifVBk7lyvl6n
+wj2O2+R9dPCwGIFQnS0xI2g+X/Wu8b9+vD++zL6hIX7YAeKiD8LfDkcWY3ChHO7
tcZw41IcHpnlGs6B9AObAbSnssPMl98MczH2IFfX+VmaqUYUucZfNlAjVkfnunTc
qfI1nNd4eNuiCKzG7oM4Y4s5kBi+Z64xoSFF4GB1KF2ZaZnxXITXydeLxwScIh0T
Gxtc9vpTnAC5tCSG6/cqtl938RK3RS6SQVqUiKDBJZUvdp2JbiI5T/mWcb0B7u2E
mBo6qZIpnfDZi08NQ9b5PwOs8f9bk4OqtDWmb24gTVv0Qh2kAahvFqBle7R+NJ/j
1nVP+W4A1omOdRpRsCtasL4do+E9I/xcIcBcAucNIwLM26crKK4d4N6BP8BBaTIW
+IjRwd7Y2TsGA9EKBpn+UpKaUZEwn6MKqyF0MEFZT6yXyzZ6cn7SIFZQ0b6j3Wzs
fLRuR1i3SWQznp5Up8MQGQgs5KbGCYip44p2rUfiKdV9m6zrTuJvTE0an+bZWFBn
SJb8EwY/BVwetcku/N7QAJSrc2h1Rl/izPNHhj+8jk65BTR/Vl8=
=GSFa
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Thu, Feb 1, 2018 at 7:16 AM, 'Raffaele Florio' via qubes-devel
<qubes...@googlegroups.com> wrote:
> [...]

> I've a question about if is acceptable (in term of performance, specifically latency) to have some form of signed USB input, from a usbvm. A lot of laptop (the majority?) has only an USB controller and without reset capabilities. The most susceptible device, IMHO, is USB keyboard. So if it's possible to put a proxy USB signer device (e.g. a rPi Zero) between the USB keyboard and the usbvm, Dom0 could verify that input come from the signer device.
> However thanks the Qubes 4.0 flexibility this necessity could be suppressed by "Qubes Air". Unfortunately I cannot try Qubes 4.0-rcX. I hope that the 4.0-rc4 hasn't any major problem. So it became the stable release, <3.

See discussion in https://github.com/QubesOS/qubes-issues/issues/2518

[Raffaele Florio]

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

> See discussion in https://github.com/QubesOS/qubes-issues/issues/2518

Great, thanks!

Best Regards,
Raffaele.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE9bU8N8AgwMcjiC1xjTxG+6f1ce4FAlqFxWUACgkQjTxG+6f1
ce7VchAAiIaJTSR00JrO9oxaI0CDDSjDH0e+z8FuYUEuR6W5vx2omp0NcbTTCGj3
ycFDDvdNEWJozkX76+O8UNJ8uzsxcdb2PVyh0jqLM6gQFm1ReJ/zycqp8eAC5JPa
7Vrq0IUyDQ3NFVKQckiNgFofS2BfuYO68FuS5V2NHq/zCMCzIeN1OgeCV11BwO9m
o2m43FDBQL3KKi6pFeJNwY0nwd06Xx0OOu2Gsi52aUqtv3MucMx9lY4XXjwwxvms
ayRmzWNLQC6ncqarxRePfijVo+QUEZE7gRfy8Byc1Z57NkNQgVJaPgyC9ne/ZWUn
iTW4nmTjv4w9g88308q5kdtOZEm0+KusSF14tv/Qbk0e/+fMwmXqPytNOkSPpQez
gMvQrDGarIzXw4G5nndblf6Ox/04D8it5KLl1b1iTB2EoyiqqsdORlvCwwLbppJP
BNnckFCZgeSlzLR1WrZgpO7coB2oMpuD7M9+9ZeWiCLJZpxvgOvr0MUx+GalX5+M
WCvF1BYsubfA+u2bOLwfzZtlqF/P8UiwcCLs9IodurxXGOk0vln6nfqfLdjBiWwo
cGXYECncC9gosqKE8jB1StGs2yGYA3ve/d1V+x1OzV1aBE+bBkno4J+bEfJoksly
RJg4yG5Ekl63icU4aADxkD6m3UoN5gWDCQqjWzM6g/9CdXgXgJU=
=jwDF
-----END PGP SIGNATURE-----