Re: [qubes-devel] R4.0-rc4 installation image considerations

[Peter Todd]

On Sat, Jan 20, 2018 at 11:54:11AM +, Andrew Clausen wrote:
> Hi all,
> 
> On 20 January 2018 at 09:28, Ivan Mitev  wrote:
> 
> > +1
> >
> > Other people in the thread disagree and still use regular DVDs - which as
> > a readonly media is great for security - but how may people from Qubes'
> > user base still have and use an optical reader ? I haven't seen any recent
> > laptop (like in the past 3-4 years) with a CD/DVD reader and nowadays
> > desktop workstations usually don't include one either.
> >
> 
> I buy a fresh USB DVD device with every secure laptop I buy.  I don't reuse
> them, because I don't want a mistake made with one of them to contaminate
> another laptop.  So I've got lots of them lying around the house!

What exactly is your threat model there?

Why not just use disposable USB keys, written on a secure system, then used
only with the target system?

> At some point DVDs + DVD equipment might become impossible to buy (or with
> only very few suppliers, all of whom could be interdicted).  I'm not sure
> what I will do then!

Note that flash drives with physical write protect switches are available, such
as the Kanguru FlashBlu30 line.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
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 post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/20180122073320.GA2934%40savin.petertodd.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018

[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

-- 
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 post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/5b060131-fe51-4164-77c5-c85f00e7feb6%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018

['Tom Zander' via qubes-devel]

On Sunday, 21 January 2018 22:19:37 CET bowa...@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.

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


-- 
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 post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/1760547.14VRJzhR2e%40mail.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018

[bowabos]

On Sunday, 21 January 2018 12:33:59 UTC, Tom Zander  wrote:
> On Saturday, 20 January 2018 15:03:38 CET bowa...@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 :)

> 
> 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.
> -- 
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel

-- 
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 post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/8f421198-6d4f-4e19-9b7f-3f8a67138c4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018

['Tom Zander' via qubes-devel]

On Saturday, 20 January 2018 15:03:38 CET bowa...@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.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


-- 
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 post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/1708765.rJ20DFuX3g%40mail.
For more options, visit https://groups.google.com/d/optout.