On Tuesday, May 2, 2017 at 4:36:16 PM UTC-4, Reg Tiangha wrote:
> On 05/02/2017 02:27 PM, cooloutac wrote:
> > I never even looked a a cryptography section man tyvm!  yes would be very 
> > awesome to know which ones to disable. very interesting. and what hardware 
> > etc of course,  and we can then just copy our config over when building the 
> > next one.  I think that is always the part that kills people but 20-40 mins 
> > aint bad.  
> >
> > I wouldn't mind compiling a kernel myself with good instructions.  I'm just 
> > weary because I have tried in debian template and can't get the gui.  It 
> > goes green and then to yellow on boot, can connect from terminal to it. I 
> > probably didn't do it the Qubes way properly.  I think because of a missing 
> > module Marmarek said once so I tried to modprobe it not sure which one or 
> > how.  
> >
> > But ya if some expert can make a guide to compile kernel that would be 
> > awesome.
> >
> > and thats right doh we do it all in a vm on Qubes!
> 
> Exactly! All of this research to find a generic, slimmed down kernel
> configuration (for dom0 and/or maybe for VMs too) that can run on a
> variety of Qubes machines would only need to be done once. Once done, it
> could just be reused for every kernel update in that branch, and would
> only need to be revisited whenever there's a major kernel update to
> figure out which new features to integrate or reject. And ditto for a
> personal kernel too that's tailored only to your hardware. That's how I
> do it for my machines.
> 
> It's worthwhile doing, regardless, if only to save on disk space and
> maybe RAM (I still can't believe I cut my personal kernel down to 1/4
> the size of the stock kernel). I am interested in the Cryptography
> stuff, though, because by default, *all* of the ciphers are enabled, and
> I wonder if it's possible if an attacker could somehow downgrade the
> encryption cipher in a VM or dom0 used by various operations to make
> things easier to exploit, in which case, you could mitigate some of that
> at the kernel level by taking out the weaker ciphers or those that Qubes
> doesn't explicitly use. I don't know if that's a valid attack vector,
> but if I thought of it, maybe someone smarter than me has too, and also
> knows how to pull it off.

ya of course.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/34a2f817-a7d4-427f-a234-57d6a64a34a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to