Re: [qubes-users] Re: Recommended laptop?

[dhorf-hfref . 4a288f10]

On Sat, Jan 04, 2020 at 05:48:29AM -0800, gorked wrote:

> Privacy Beast.   I suspect that I might brick a Lenovo X230 trying to put 
> Core Boot on it.  I know the guys at a local computer shop are capable, but 

the main "trick" here is to have a solid unbricking strategy.
if you have an external flasher, or a device with a clever 
vendor firmware, the worst that will happen is you get to
curse and waste an hour of your time.
i wouldnt even recommend applying me_cleaner without _some_
strategy for recovering from a bad flash.


> My questions being, seems like there is some kind of thing about needing a 
> computer build before 2012 to work properly.   Is this true?

not sure what that means.
actualy, for chromebooks i would recommend "as new as possible". 
all chromebooks with enough oomph ship with coreboot.
any documentation referencing Lewis tooling is outdated.
if you just want to liberate a chromebook without doing own
work on the firmware, MrChromebox tooling is the current way to go.


> Anyone work with a specific Chrome Book?   One can have its RAM increase to 
> say 16 GB, and so on?   

i use qubes on two higher end chromebook models.
Acer CB713 (more pixels, smaller storage) and CB714 (fewer pixels, more
storage).
both have 16GB ram.
both are on the high end of the chromebook price range. 
both can be maddening with their (lack of) internal storage performance.

all modern chromebooks with usbc also support external debug+flash
through a suzyqable. 
very convenient if you want to explore custom firmware mods. 


-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200104141332.GD8973%40priv-mua.

[qubes-users] Re: Recommended laptop?

[gorked]

I was also interested in a higher security laptop.   I feel the guys who 
create the Insurgo Privacy Beast are doing a lot more than just flashing 
the BIOS.  I am on Social Security, so I can not afford their Insurgo 
Privacy Beast.   I suspect that I might brick a Lenovo X230 trying to put 
Core Boot on it.  I know the guys at a local computer shop are capable, but 
they are not free, and I would have to take the risk of it going bad.

The Librem laptops are not quite in my price range, and I notice the posts 
by the developer of Qubes who is somewhat not happy with some of the 
direction of Librem development.   I am guessing the individual could tweak 
up some of the security issues on the Librem.  And a Librem is  better than 
not doing anything, but still prohibitively expensive for me at this time. 
  

I guess I am getting off the point.   I was looking at Chrome Books to run 
Qubes, and notice, 
https://github.com/bibanon/Coreboot-ThinkPads/wiki/Chromebook-Coreboot-Installation

My questions being, seems like there is some kind of thing about needing a 
computer build before 2012 to work properly.   Is this true?

Anyone work with a specific Chrome Book?   One can have its RAM increase to 
say 16 GB, and so on?   

For now, I have to work with what I have.   I have a mid 2009 Mac Book Pro, 
and will put another spinning drive in it.  Install OS X, the dual book to 
some version of Linux.  (I guess everyone here knows that is what Apple 
calls "Boot Camp")   Yes, I did put an SSD in it and try to just install 
Linux.   Something about it does not seem to shut down properly, and then I 
can not get it to boot at all.   No doubt not a problem to Linux groupies 
here.   I feel a dual boot with Boot Camp would resolve that issue.   I 
guess that is training wheels.  That may seem overly detailed, but my last 
question is:  I know nearly any version of Linux should work in the Apple, 
and I may try several, just for fun. I had hoped for a solid Linux stub to 
run a virtual machine on top of.  But which version of Linux should give me 
Security?  I had thought of CentOS or its Oracle twin.  Parrot OS looks 
interesting.  None of those are just basic stubs.   Thanks for reading 
this.  and for replying.

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f2abf89d-61cb-441b-86e2-822e97d28fb1%40googlegroups.com.

Re: [qubes-users] Re: Recommended laptop?

[Chris Laprise]

On 1/2/20 2:51 PM, Thierry Laurion wrote:



Le jeudi 2 janvier 2020 00:10:09 UTC-5, Chris Laprise a écrit :

On 1/1/20 8:28 PM, Thierry Laurion wrote:
 >
 >
 > On Wed, Jan 1, 2020 at 4:12 PM Chris Laprise  > wrote:
 >
 >     On 1/1/20 1:36 PM, Thierry Laurion wrote:
 >      >
 >      >
 >      > Le mercredi 1 janvier 2020 13:32:00 UTC-5, Chris Laprise a
écrit :
 >      >
 >      >     On 1/1/20 5:43 AM, Lorenzo Lamas wrote:
 >      >      > Hello Thierry,
 >      >      >
 >      >      > Thanks for all that you are doing for the
community. Do
 >     you see a
 >      >      > possibility of a Qubes Certified Laptop with an AMD
CPU?
 >      >      > Intel is affected a lot more than AMD by the
sidechannel
 >      >     vulnerabilities
 >      >      > in the last years. The Privacy Beast has a 3rd gen
Intel
 >     CPU, Intel
 >      >      > stopped providing uCode updates for 1st gen in
2019, so
 >     this year is
 >      >      > probably the last year they will support 3rd gen.
More CPU
 >      >      > vulnerabilities will most certainly be discovered
in the
 >     coming
 >      >     years,
 >      >      > so there is a need for an AMD based certified
laptop, or
 >     at least a
 >      >      > newer generation Intel based laptop, even though
that may
 >     mean we're
 >      >      > stuck with PSP or ME.
 >      >
 >      >     As much as I like the Insurgo/Purism/System76
offerings, this
 >     issue has
 >      >     weighed on me to reconsider.
 >      >
 >      >     The massive amount of side-channel vulnerabilities
have shown
 >     Intel's
 >      >     engineering is reckless, and it gets worse. They're
still pushing
 >      >     fraudulent compiler code – detecting and de-optimizing
AMD –
 >     almost a
 >      >     decade after it was reported in the press. And they
outright
 >     refuse to
 >      >     pay government fines relating to their misconduct – which
 >     also included
 >      >     threatening PC vendors with retaliation if they sell "too
 >     many" AMD
 >      >     units.
 >      >
 >      >     Historically, when a behemoth like Intel goes renegade
its
 >     because they
 >      >     know their products are superior and the public will
accept the
 >      >     situation as a trade-off. But the only thing that's
 >     "superior" about
 >      >     Intel is their attitude and their ill-gotten revenue.
 >      >
 >      >     The biggest problem I see is peoples' willingness to
go along
 >     with what
 >      >     is becoming a tradition of anti-competition. Whatever
logical
 >     fallacies
 >      >     are put forward to make it seem palatable with CPUs
will also
 >     undermine
 >      >     user motivations in other areas.
 >      >
 >      > Completely agreeing. This is why this
 >      >
 >
>

 >
 >      > needs collaboration to have real solutions in the future.
 >
 >     The relative ease of using another x86 brand with better
implementation
 >     and ethics such as AMD makes it a clear choice in the
meantime, while
 >     the much more difficult and lengthy task of adopting open
hardware is
 >     pursued.
 >
 >     People can wait 18-36 months for a Qubes port to POWER
architecture...
 >     That is 18-36 months of being subject to maximum side-channel
(and
 >     probably other) risks and signalling a tacit acceptance of
Intel's
 >     engineering. And at the end of that period, we still won't
have laptops.
 >
 >     Only holding out for the perfect appears to be the enemy of
good in
 >     this
 >     case; it is the wrong mindset for adding alternatives. Under
these
 >     circumstances, there should be absolutely no hint that a
robust x86
 >     alternative is somehow passe... but that appears to be the
message
 >     coming from vendors.
 >
 > I am not aware of any AMD model to recommend on my end which
would have
 > the good mix of QubesOS well supported components to fit
requirements
 > and warned compatibility issues.
 >
 > If you have such model in mind to recommend, be part of the
solution and
 > let us know.
 >
 > Meanwhile, models that fitted the bill for workstation/server got
 > dropped by coreboot by lack of interest from the community (KGPE-D16
 >

Re: [qubes-users] Re: Recommended laptop?

[Thierry Laurion]

Le jeudi 2 janvier 2020 00:10:09 UTC-5, Chris Laprise a écrit :
>
> On 1/1/20 8:28 PM, Thierry Laurion wrote: 
> > 
> > 
> > On Wed, Jan 1, 2020 at 4:12 PM Chris Laprise   
> > > wrote: 
> > 
> > On 1/1/20 1:36 PM, Thierry Laurion wrote: 
> >  > 
> >  > 
> >  > Le mercredi 1 janvier 2020 13:32:00 UTC-5, Chris Laprise a 
> écrit : 
> >  > 
> >  > On 1/1/20 5:43 AM, Lorenzo Lamas wrote: 
> >  >  > Hello Thierry, 
> >  >  > 
> >  >  > Thanks for all that you are doing for the community. Do 
> > you see a 
> >  >  > possibility of a Qubes Certified Laptop with an AMD CPU? 
> >  >  > Intel is affected a lot more than AMD by the sidechannel 
> >  > vulnerabilities 
> >  >  > in the last years. The Privacy Beast has a 3rd gen Intel 
> > CPU, Intel 
> >  >  > stopped providing uCode updates for 1st gen in 2019, so 
> > this year is 
> >  >  > probably the last year they will support 3rd gen. More CPU 
> >  >  > vulnerabilities will most certainly be discovered in the 
> > coming 
> >  > years, 
> >  >  > so there is a need for an AMD based certified laptop, or 
> > at least a 
> >  >  > newer generation Intel based laptop, even though that may 
> > mean we're 
> >  >  > stuck with PSP or ME. 
> >  > 
> >  > As much as I like the Insurgo/Purism/System76 offerings, this 
> > issue has 
> >  > weighed on me to reconsider. 
> >  > 
> >  > The massive amount of side-channel vulnerabilities have shown 
> > Intel's 
> >  > engineering is reckless, and it gets worse. They're still 
> pushing 
> >  > fraudulent compiler code – detecting and de-optimizing AMD – 
> > almost a 
> >  > decade after it was reported in the press. And they outright 
> > refuse to 
> >  > pay government fines relating to their misconduct – which 
> > also included 
> >  > threatening PC vendors with retaliation if they sell "too 
> > many" AMD 
> >  > units. 
> >  > 
> >  > Historically, when a behemoth like Intel goes renegade its 
> > because they 
> >  > know their products are superior and the public will accept 
> the 
> >  > situation as a trade-off. But the only thing that's 
> > "superior" about 
> >  > Intel is their attitude and their ill-gotten revenue. 
> >  > 
> >  > The biggest problem I see is peoples' willingness to go along 
> > with what 
> >  > is becoming a tradition of anti-competition. Whatever logical 
> > fallacies 
> >  > are put forward to make it seem palatable with CPUs will also 
> > undermine 
> >  > user motivations in other areas. 
> >  > 
> >  > Completely agreeing. This is why this 
> >  > 
> > <
> https://github.com/QubesOS/qubes-issues/issues/4318#issuecomment-549986749> 
>
> > 
> >  > needs collaboration to have real solutions in the future. 
> > 
> > The relative ease of using another x86 brand with better 
> implementation 
> > and ethics such as AMD makes it a clear choice in the meantime, 
> while 
> > the much more difficult and lengthy task of adopting open hardware 
> is 
> > pursued. 
> > 
> > People can wait 18-36 months for a Qubes port to POWER 
> architecture... 
> > That is 18-36 months of being subject to maximum side-channel (and 
> > probably other) risks and signalling a tacit acceptance of Intel's 
> > engineering. And at the end of that period, we still won't have 
> laptops. 
> > 
> > Only holding out for the perfect appears to be the enemy of good in 
> > this 
> > case; it is the wrong mindset for adding alternatives. Under these 
> > circumstances, there should be absolutely no hint that a robust x86 
> > alternative is somehow passe... but that appears to be the message 
> > coming from vendors. 
> > 
> > I am not aware of any AMD model to recommend on my end which would have 
> > the good mix of QubesOS well supported components to fit requirements 
> > and warned compatibility issues. 
> > 
> > If you have such model in mind to recommend, be part of the solution and 
> > let us know. 
> > 
> > Meanwhile, models that fitted the bill for workstation/server got 
> > dropped by coreboot by lack of interest from the community (KGPE-D16 
> > ). 
> It 
> > might be brought back under grant work (TBD), but AFAIK, there is not 
> > such trust altogether from the community torward AMD, not really more 
> > trust torward their PSP (ME equivalent) and not so much known right now 
> > from attempts reversing  it. 
>
> Yes, this has as much to do with community attitudes as anything else. I 
> would still expect some vendor to be able 

[qubes-users] Re: Recommended laptop?

[Guerlan]

On Tuesday, December 24, 2019 at 7:43:08 AM UTC-2, Ondřej Šulák wrote:
>
> Hello pals,
> for the last release of Qubes, what laptop would you recommend? Is there 
> any cheaper option which does have HW compatibility with latest Qubes 
> (ideally with shipping from EU), than this one:
>
> https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/
>  
> ?
>
> Thanks for any tips!
>
> Ondrej
>


Im running on a Razer Blade Steatlh 4k + touchscreen 2016 16gb RAM 512gb 
SSD i7 ultra thin. *Everything* works wxcept for the lid closing and 
opening but I'm trying to find a solution. Qubes runs very good on this 
laptop, I'm very happy!

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/da6966c6-c4d8-4465-85a6-dc9a27cb4206%40googlegroups.com.

Re: [qubes-users] Re: Recommended laptop?

[Chris Laprise]

On 1/1/20 8:28 PM, Thierry Laurion wrote:



On Wed, Jan 1, 2020 at 4:12 PM Chris Laprise > wrote:


On 1/1/20 1:36 PM, Thierry Laurion wrote:
 >
 >
 > Le mercredi 1 janvier 2020 13:32:00 UTC-5, Chris Laprise a écrit :
 >
 >     On 1/1/20 5:43 AM, Lorenzo Lamas wrote:
 >      > Hello Thierry,
 >      >
 >      > Thanks for all that you are doing for the community. Do
you see a
 >      > possibility of a Qubes Certified Laptop with an AMD CPU?
 >      > Intel is affected a lot more than AMD by the sidechannel
 >     vulnerabilities
 >      > in the last years. The Privacy Beast has a 3rd gen Intel
CPU, Intel
 >      > stopped providing uCode updates for 1st gen in 2019, so
this year is
 >      > probably the last year they will support 3rd gen. More CPU
 >      > vulnerabilities will most certainly be discovered in the
coming
 >     years,
 >      > so there is a need for an AMD based certified laptop, or
at least a
 >      > newer generation Intel based laptop, even though that may
mean we're
 >      > stuck with PSP or ME.
 >
 >     As much as I like the Insurgo/Purism/System76 offerings, this
issue has
 >     weighed on me to reconsider.
 >
 >     The massive amount of side-channel vulnerabilities have shown
Intel's
 >     engineering is reckless, and it gets worse. They're still pushing
 >     fraudulent compiler code – detecting and de-optimizing AMD –
almost a
 >     decade after it was reported in the press. And they outright
refuse to
 >     pay government fines relating to their misconduct – which
also included
 >     threatening PC vendors with retaliation if they sell "too
many" AMD
 >     units.
 >
 >     Historically, when a behemoth like Intel goes renegade its
because they
 >     know their products are superior and the public will accept the
 >     situation as a trade-off. But the only thing that's
"superior" about
 >     Intel is their attitude and their ill-gotten revenue.
 >
 >     The biggest problem I see is peoples' willingness to go along
with what
 >     is becoming a tradition of anti-competition. Whatever logical
fallacies
 >     are put forward to make it seem palatable with CPUs will also
undermine
 >     user motivations in other areas.
 >
 > Completely agreeing. This is why this
 >


 > needs collaboration to have real solutions in the future.

The relative ease of using another x86 brand with better implementation
and ethics such as AMD makes it a clear choice in the meantime, while
the much more difficult and lengthy task of adopting open hardware is
pursued.

People can wait 18-36 months for a Qubes port to POWER architecture...
That is 18-36 months of being subject to maximum side-channel (and
probably other) risks and signalling a tacit acceptance of Intel's
engineering. And at the end of that period, we still won't have laptops.

Only holding out for the perfect appears to be the enemy of good in
this
case; it is the wrong mindset for adding alternatives. Under these
circumstances, there should be absolutely no hint that a robust x86
alternative is somehow passe... but that appears to be the message
coming from vendors.

I am not aware of any AMD model to recommend on my end which would have 
the good mix of QubesOS well supported components to fit requirements 
and warned compatibility issues.


If you have such model in mind to recommend, be part of the solution and 
let us know.


Meanwhile, models that fitted the bill for workstation/server got 
dropped by coreboot by lack of interest from the community (KGPE-D16 
). It 
might be brought back under grant work (TBD), but AFAIK, there is not 
such trust altogether from the community torward AMD, not really more 
trust torward their PSP (ME equivalent) and not so much known right now 
from attempts reversing  it.


Yes, this has as much to do with community attitudes as anything else. I 
would still expect some vendor to be able to put 2+2 together and market 
AMD-based systems based on their history and current strengths.


If there is public mistrust bc of PSP, then there should be some 
engagement from Coreboot and Libreboot to demonstrate that deactivation 
is plausible. OTOH, since Coreboot seems stuck in c.2012 with Intel Ivy 
Bridge processors, that could make the issue moot bc AMD units requiring 
no such deactivation (containing no PSP) are available that are also a 
year newer.


Regarding new hardware, which is important, I would rather take my 
chances with AMD PSP firmware properly deactivating 

Re: [qubes-users] Re: Recommended laptop?

[Thierry Laurion]

On Wed, Jan 1, 2020 at 4:12 PM Chris Laprise  wrote:

> On 1/1/20 1:36 PM, Thierry Laurion wrote:
> >
> >
> > Le mercredi 1 janvier 2020 13:32:00 UTC-5, Chris Laprise a écrit :
> >
> > On 1/1/20 5:43 AM, Lorenzo Lamas wrote:
> >  > Hello Thierry,
> >  >
> >  > Thanks for all that you are doing for the community. Do you see a
> >  > possibility of a Qubes Certified Laptop with an AMD CPU?
> >  > Intel is affected a lot more than AMD by the sidechannel
> > vulnerabilities
> >  > in the last years. The Privacy Beast has a 3rd gen Intel CPU,
> Intel
> >  > stopped providing uCode updates for 1st gen in 2019, so this year
> is
> >  > probably the last year they will support 3rd gen. More CPU
> >  > vulnerabilities will most certainly be discovered in the coming
> > years,
> >  > so there is a need for an AMD based certified laptop, or at least
> a
> >  > newer generation Intel based laptop, even though that may mean
> we're
> >  > stuck with PSP or ME.
> >
> > As much as I like the Insurgo/Purism/System76 offerings, this issue
> has
> > weighed on me to reconsider.
> >
> > The massive amount of side-channel vulnerabilities have shown Intel's
> > engineering is reckless, and it gets worse. They're still pushing
> > fraudulent compiler code – detecting and de-optimizing AMD – almost a
> > decade after it was reported in the press. And they outright refuse
> to
> > pay government fines relating to their misconduct – which also
> included
> > threatening PC vendors with retaliation if they sell "too many" AMD
> > units.
> >
> > Historically, when a behemoth like Intel goes renegade its because
> they
> > know their products are superior and the public will accept the
> > situation as a trade-off. But the only thing that's "superior" about
> > Intel is their attitude and their ill-gotten revenue.
> >
> > The biggest problem I see is peoples' willingness to go along with
> what
> > is becoming a tradition of anti-competition. Whatever logical
> fallacies
> > are put forward to make it seem palatable with CPUs will also
> undermine
> > user motivations in other areas.
> >
> > Completely agreeing. This is why this
> > <
> https://github.com/QubesOS/qubes-issues/issues/4318#issuecomment-549986749>
>
> > needs collaboration to have real solutions in the future.
>
> The relative ease of using another x86 brand with better implementation
> and ethics such as AMD makes it a clear choice in the meantime, while
> the much more difficult and lengthy task of adopting open hardware is
> pursued.
>
> People can wait 18-36 months for a Qubes port to POWER architecture...
> That is 18-36 months of being subject to maximum side-channel (and
> probably other) risks and signalling a tacit acceptance of Intel's
> engineering. And at the end of that period, we still won't have laptops.
>
> Only holding out for the perfect appears to be the enemy of good in this
> case; it is the wrong mindset for adding alternatives. Under these
> circumstances, there should be absolutely no hint that a robust x86
> alternative is somehow passe... but that appears to be the message
> coming from vendors.
>

I am not aware of any AMD model to recommend on my end which would have the
good mix of QubesOS well supported components to fit requirements and
warned compatibility issues.

If you have such model in mind to recommend, be part of the solution and
let us know.

Meanwhile, models that fitted the bill for workstation/server got dropped
by coreboot by lack of interest from the community (KGPE-D16
).
It might be brought back under grant work (TBD), but AFAIK, there is not
such trust altogether from the community torward AMD, not really more trust
torward their PSP (ME equivalent) and not so much known right now from
attempts reversing  it.

So what model would you suggest in the meantime for which firmware can be
replaced by Open Source Firmware?

>
> --
>
> Chris Laprise, tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886
>


-- 
Thierry Laurion

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAAzJznyUYV78UYTAT%2Bxru%3DZuwNJOqZH4y9d%3De04iUXoy%3DGyEVA%40mail.gmail.com.

Re: [qubes-users] Re: Recommended laptop?

[Chris Laprise]

On 1/1/20 1:36 PM, Thierry Laurion wrote:



Le mercredi 1 janvier 2020 13:32:00 UTC-5, Chris Laprise a écrit :

On 1/1/20 5:43 AM, Lorenzo Lamas wrote:
 > Hello Thierry,
 >
 > Thanks for all that you are doing for the community. Do you see a
 > possibility of a Qubes Certified Laptop with an AMD CPU?
 > Intel is affected a lot more than AMD by the sidechannel
vulnerabilities
 > in the last years. The Privacy Beast has a 3rd gen Intel CPU, Intel
 > stopped providing uCode updates for 1st gen in 2019, so this year is
 > probably the last year they will support 3rd gen. More CPU
 > vulnerabilities will most certainly be discovered in the coming
years,
 > so there is a need for an AMD based certified laptop, or at least a
 > newer generation Intel based laptop, even though that may mean we're
 > stuck with PSP or ME.

As much as I like the Insurgo/Purism/System76 offerings, this issue has
weighed on me to reconsider.

The massive amount of side-channel vulnerabilities have shown Intel's
engineering is reckless, and it gets worse. They're still pushing
fraudulent compiler code – detecting and de-optimizing AMD – almost a
decade after it was reported in the press. And they outright refuse to
pay government fines relating to their misconduct – which also included
threatening PC vendors with retaliation if they sell "too many" AMD
units.

Historically, when a behemoth like Intel goes renegade its because they
know their products are superior and the public will accept the
situation as a trade-off. But the only thing that's "superior" about
Intel is their attitude and their ill-gotten revenue.

The biggest problem I see is peoples' willingness to go along with what
is becoming a tradition of anti-competition. Whatever logical fallacies
are put forward to make it seem palatable with CPUs will also undermine
user motivations in other areas.

Completely agreeing. This is why this 
 
needs collaboration to have real solutions in the future.


The relative ease of using another x86 brand with better implementation 
and ethics such as AMD makes it a clear choice in the meantime, while 
the much more difficult and lengthy task of adopting open hardware is 
pursued.


People can wait 18-36 months for a Qubes port to POWER architecture... 
That is 18-36 months of being subject to maximum side-channel (and 
probably other) risks and signalling a tacit acceptance of Intel's 
engineering. And at the end of that period, we still won't have laptops.


Only holding out for the perfect appears to be the enemy of good in this 
case; it is the wrong mindset for adding alternatives. Under these 
circumstances, there should be absolutely no hint that a robust x86 
alternative is somehow passe... but that appears to be the message 
coming from vendors.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9b6d6ae6-5252-21a4-2a52-d9dfa355b905%40posteo.net.

Re: [qubes-users] Re: Recommended laptop?

[Thierry Laurion]

Le mercredi 1 janvier 2020 13:32:00 UTC-5, Chris Laprise a écrit :
>
> On 1/1/20 5:43 AM, Lorenzo Lamas wrote: 
> > Hello Thierry, 
> > 
> > Thanks for all that you are doing for the community. Do you see a 
> > possibility of a Qubes Certified Laptop with an AMD CPU? 
> > Intel is affected a lot more than AMD by the sidechannel vulnerabilities 
> > in the last years. The Privacy Beast has a 3rd gen Intel CPU, Intel 
> > stopped providing uCode updates for 1st gen in 2019, so this year is 
> > probably the last year they will support 3rd gen. More CPU 
> > vulnerabilities will most certainly be discovered in the coming years, 
> > so there is a need for an AMD based certified laptop, or at least a 
> > newer generation Intel based laptop, even though that may mean we're 
> > stuck with PSP or ME. 
>
> As much as I like the Insurgo/Purism/System76 offerings, this issue has 
> weighed on me to reconsider. 
>
> The massive amount of side-channel vulnerabilities have shown Intel's 
> engineering is reckless, and it gets worse. They're still pushing 
> fraudulent compiler code – detecting and de-optimizing AMD – almost a 
> decade after it was reported in the press. And they outright refuse to 
> pay government fines relating to their misconduct – which also included 
> threatening PC vendors with retaliation if they sell "too many" AMD units. 
>
> Historically, when a behemoth like Intel goes renegade its because they 
> know their products are superior and the public will accept the 
> situation as a trade-off. But the only thing that's "superior" about 
> Intel is their attitude and their ill-gotten revenue. 
>
> The biggest problem I see is peoples' willingness to go along with what 
> is becoming a tradition of anti-competition. Whatever logical fallacies 
> are put forward to make it seem palatable with CPUs will also undermine 
> user motivations in other areas. 
>
 
Completely agreeing. This is why this 
 
needs collaboration to have real solutions in the future.

>
> -- 
>
> Chris Laprise, tas...@posteo.net  
> https://github.com/tasket 
> https://twitter.com/ttaskett 
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886 
>

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/11ad83dc-145e-4af4-830a-33950773cc63%40googlegroups.com.

Re: [qubes-users] Re: Recommended laptop?

[Chris Laprise]

On 1/1/20 5:43 AM, Lorenzo Lamas wrote:

Hello Thierry,

Thanks for all that you are doing for the community. Do you see a 
possibility of a Qubes Certified Laptop with an AMD CPU?
Intel is affected a lot more than AMD by the sidechannel vulnerabilities 
in the last years. The Privacy Beast has a 3rd gen Intel CPU, Intel 
stopped providing uCode updates for 1st gen in 2019, so this year is 
probably the last year they will support 3rd gen. More CPU 
vulnerabilities will most certainly be discovered in the coming years, 
so there is a need for an AMD based certified laptop, or at least a 
newer generation Intel based laptop, even though that may mean we're 
stuck with PSP or ME.


As much as I like the Insurgo/Purism/System76 offerings, this issue has 
weighed on me to reconsider.


The massive amount of side-channel vulnerabilities have shown Intel's 
engineering is reckless, and it gets worse. They're still pushing 
fraudulent compiler code – detecting and de-optimizing AMD – almost a 
decade after it was reported in the press. And they outright refuse to 
pay government fines relating to their misconduct – which also included 
threatening PC vendors with retaliation if they sell "too many" AMD units.


Historically, when a behemoth like Intel goes renegade its because they 
know their products are superior and the public will accept the 
situation as a trade-off. But the only thing that's "superior" about 
Intel is their attitude and their ill-gotten revenue.


The biggest problem I see is peoples' willingness to go along with what 
is becoming a tradition of anti-competition. Whatever logical fallacies 
are put forward to make it seem palatable with CPUs will also undermine 
user motivations in other areas.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9b3a1464-f137-229a-9e8f-2bd0ed7423b3%40posteo.net.

Re: [qubes-users] Re: Recommended laptop?

[Thierry Laurion]

On Wed, Jan 1, 2020 at 5:43 AM Lorenzo Lamas  wrote:

> Hello Thierry,
>
> Thanks for all that you are doing for the community. Do you see a
> possibility of a Qubes Certified Laptop with an AMD CPU?
>
There could be others certifying such models, but I won't do certification
process for those.
Only model that would not have an Intel ME equivalent, doesn't rely on
binary blobs etc would be the G505S
 which doesn't have enough
SPI flash space to do anything interesting.

Intel is affected a lot more than AMD by the sidechannel vulnerabilities in
> the last years. The Privacy Beast has a 3rd gen Intel CPU, Intel stopped
> providing uCode updates for 1st gen in 2019, so this year is probably the
> last year they will support 3rd gen. More CPU vulnerabilities will most
> certainly be discovered in the coming years, so there is a need for an AMD
> based certified laptop, or at least a newer generation Intel based laptop,
> even though that may mean we're stuck with PSP or ME.
>
My personal path is to try to go away of x86 as fast as possible and try to
move actual interest (chicken and egg problem) toward where we should
really want to go

.

I understand all the fuss around those CPU vulnerabilities, but mostly for
the server use case, where everything NEEDS to be kept in memory. The
concept that needs to be gripped here for workstations is that an
information that is not in memory cannot be stolen. Getting the root of
this concept, applied to QubesOS, which shuts off smt (HyperThreading) and
enforces easy DisposableVMs usage, the user changing some of his habits and
compartmentalize accordingly resolves most of the risks. Unsafe browsing?
DisposableVM. Done with unsafe browsing? Close unsafe browser, which shuts
down DisposableVM and deletes disk changes and memory content. Unsafe
attachment? Open in DisposableVM. Often attach untrusted USB device to
computer? Create a separate USB sys-usb-unsafe and affect distinct USB
controller to it and always attach untrusted USB devices to that port only.
Consider USB compartment as being temporary and never trust anything being
in memory of that AppVM or its attached storage. Don't give network access
to AppVMs not needing it.

To say it short, hardware will continue to have vulnerabilities. Those will
continue to be really hard to patch. Users will have to change their habits
in any case, the sooner the better. Now seems a good moment. The current
race for better security enclaves, memory encryption etc won't save the day
if closed and behind NDAs for code review and documentation access. The
best protection a user can have is against himself. Combined with a root of
trust that contains lesser to none untrusted binaries is the best scenario
IMOHO, where untrusted binaries are isolated and untrusted at all time.
Having ways to make users aware of harware casing tampering would be best.
Supply chain not being a problem would be ideal but impossible, targeting
and implants always being possible. Race conditions in accessing
confidential information in memory is key Do you really need those 16
AppVMs opened at all time on older hardware :) Or worst. Have those 20
proprietary software running concurrently on your monolithic operating
system disclosing information you don't know on you and other applications
running at the same time? Habits.

Meanwhile, having a non-monolithic operating system on top of measured
firmware containing less to none binary blobs, and verified boot on core
components is the best we can have as a root of trust (RoT) perspective for
end point devices. It always go down to the simple question: What do you
put your trust in? My personal answer is: on hardware that is the most
user-controllable as possible. And this is where my interest, time and
energies are directed at. The lesser blobs the better.

>
> On Tuesday, December 31, 2019 at 9:45:18 PM UTC+1, Thierry Laurion wrote:
>>
>>
>> On Wed, Dec 25, 2019 at 6:03 PM  wrote:
>>
>>> Insurgo is providing a service.
>>>
>>> If one can do the steps themselves, that’s fine.
>>>
>>> If I were advising a somewhat less technical journalist or a potentially
>>> targeted human-rights worker or politically targeted activist who just
>>> wanted to get stuff done and had the resources, I’d point them to Insurgo.
>>>
>>> Brendan
>>>
>>> --
>>> 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 qubes...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/qubes-users/7a7741f2-6b80-40be-a5a0-0f56b658f9fc%40googlegroups.com
>>> .
>>>
>>
>>
>> Hello there, Thierry Laurion from Insurgo Open Technologies.
>>
>> Thanks Brendan.
>>
>> I feel the need to clarify things a bit once in a while. This reply is
>> one 

Fwd: [qubes-users] Re: Recommended laptop?

[Thierry Laurion]

Sorry for reposting. Previous mail badly formatted.

On Wed, Jan 1, 2020 at 3:16 AM Anil Eklavya  wrote:

> Thanks for putting all this information in one place. I was earlier
> looking to buy Insurgio Privacy Beast, but it was not clear whether it
> could be shipped to India. I then ordered Librem 13.
>

Website does the simulation in costs for tax and shipping costs. If
shipping address returns a shipping option, it can be shipped to you.

>
> Is there any comparison available between these two, based on privacy and
> security considerations?
>

Unfortunately, not for the moment. External comparisons welcome!
At the end of the day, it goes to those simple points:

   - X230's Intel ME has no kernel, no syslibs. It is reduced to be able to
   boot itself and main CPU and is shut down, not having anything else to
   execute since the modules have been removed completely. See here
   

   .
   - Here is an extract of the same me_cleaner command applied to:
  - X230:

Full image detected
The ME/TXE region goes from 0x3000 to 0x4ff000
Found FPT header at 0x3010
Found 23 partition(s)
Found FTPR header: FTPR partition spans from 0x183000 to 0x24d000
*ME/TXE firmware version 8.1.30.1350*
Removing extra partitions...
Removing extra partition entries in FPT...
Removing EFFS presence flag...
Removing ME/TXE R/W access to the other flash regions...
Correcting checksum (0x7b)...
Reading FTPR modules list...
 UPDATE   (LZMA   , 0x1cf4f2 - 0x1cf6b0): removed

* ROMP (Huffman, fragmented data): NOT removed,
essential BUP  (Huffman, fragmented data): NOT removed,
essential*
 KERNEL   (Huffman, fragmented data): removed
 POLICY   (Huffman, fragmented data): removed
 HOSTCOMM (LZMA   , 0x1cf6b0 - 0x1d648b): removed
 RSA  (LZMA   , 0x1d648b - 0x1db6e0): removed
 CLS  (LZMA   , 0x1db6e0 - 0x1e0e71): removed
 TDT  (LZMA   , 0x1e0e71 - 0x1e7556): removed
 FTCS (Huffman, fragmented data): removed
 ClsPriv  (LZMA   , 0x1e7556 - 0x1e7937): removed
 SESSMGR  (LZMA   , 0x1e7937 - 0x1f6240): removed
Relocating FTPR from 0xd00 - 0xcad00 to 0xd00 - 0xcad00...
 Adjusting FPT entry...
 Adjusting LUT start offset...
 Adjusting Huffman start offset...
 Adjusting chunks offsets...
 Moving data...
*The ME minimum size should be 98304 bytes (0x18000 bytes)*
The ME region can be reduced up to:
 3000:0001afff me
Setting the AltMeDisable bit in PCHSTRP10 to disable Intel ME...
Removing ME/TXE R/W access to the other flash regions...
Extracting and truncating the ME image to "extracted_me.rom"...
Checking the FTPR RSA signature of the extracted ME image... VALID
Checking the FTPR RSA signature... VALID
Done! Good luck!

   - Librem V3:
   Full image detected
   Found FPT header at 0x1010
   Found 1 partition(s)
   Found FTPR header: FTPR partition spans from 0x1000 to 0xa8000
   Found FTPR manifest at 0x1448
   *ME/TXE firmware version 11.6.0.1126 (generation 3)*
   Public key match: Intel ME, firmware versions 11.x.x.x
   The HAP bit is SET
   Reading partitions list...
FTPR (0x1000 - 0xa8000, 0x000a7000 total bytes): NOT removed
   Removing partition entries in FPT...
   Removing EFFS presence flag...
   Correcting checksum (0x98)...
   Reading FTPR modules list...
FTPR.man (uncompressed, 0x001448 - 0x002018): NOT removed,
   partition manif.
rbe.met  (uncompressed, 0x002018 - 0x0020ae): NOT removed, module
   metadata
kernel.met   (uncompressed, 0x0020ae - 0x00213c): NOT removed, module
   metadata
syslib.met   (uncompressed, 0x00213c - 0x0021a0): NOT removed, module
   metadata
bup.met  (uncompressed, 0x0021a0 - 0x00274a): NOT removed, module
   metadata
pm.met   (uncompressed, 0x00274a - 0x0027f8): NOT removed, module
   metadata
vfs.met  (uncompressed, 0x0027f8 - 0x003158): NOT removed, module
   metadata
evtdisp.met  (uncompressed, 0x003158 - 0x0032e6): NOT removed, module
   metadata
loadmgr.met  (uncompressed, 0x0032e6 - 0x00340e): NOT removed, module
   metadata
busdrv.met   (uncompressed, 0x00340e - 0x0037b4): NOT removed, module
   metadata
gpio.met (uncompressed, 0x0037b4 - 0x0038fe): NOT removed, module
   metadata
prtc.met (uncompressed, 0x0038fe - 0x003aae): NOT removed, module
   metadata
policy.met   (uncompressed, 0x003aae - 0x003c72): NOT removed, module
   metadata
crypto.met   (uncompressed, 0x003c72 - 0x003dfc): NOT removed, module
   metadata
heci.met (uncompressed, 0x003dfc - 0x003fc8): NOT removed, module
   metadata
storage.met  (uncompressed, 0x003fc8 - 0x0042c4): NOT removed, module
   metadata
pmdrv.met(uncompressed, 0x0042c4 - 0x0043e8): NOT removed, module
   metadata
maestro.met  (uncompressed, 0x0043e8 - 0x0044d2): NOT removed, module
   metadata
fpf.met  

Re: [qubes-users] Re: Recommended laptop?

[Thierry Laurion]

On Wed, Jan 1, 2020 at 3:16 AM Anil Eklavya  wrote:

> Thanks for putting all this information in one place. I was earlier
> looking to buy Insurgio Privacy Beast, but it was not clear whether it
> could be shipped to India. I then ordered Librem 13.
>

Website does the simulation in costs for tax and shipping costs. If
provided shipping address returns a shipping option, it can be shipped to
you.


> Is there any comparison available between these two, based on privacy and
> security considerations?
>

Unfortunately, not for the moment. External comparisons welcome!
At the end of the day, it goes to those simple points:

   - X230's Intel ME has no kernel, no syslibs. It is reduced to be able to
   boot itself and main CPU and is shut down, not having anything else to
   execute since the modules have been removed completely. See here
   

   .
   - Here is an extract of the same me_cleaner command applied to:
  - *X230:*

Full image detected
The ME/TXE region goes from 0x3000 to 0x4ff000
Found FPT header at 0x3010
Found 23 partition(s)
Found FTPR header: FTPR partition spans from 0x183000 to 0x24d000
*ME/TXE firmware version 8.1.30.1350*
Removing extra partitions...
Removing extra partition entries in FPT...
Removing EFFS presence flag...
Removing ME/TXE R/W access to the other flash regions...
Correcting checksum (0x7b)...
Reading FTPR modules list...
 UPDATE   (LZMA   , 0x1cf4f2 - 0x1cf6b0): removed

* ROMP (Huffman, fragmented data): NOT removed,
essential BUP  (Huffman, fragmented data): NOT removed,
essential*
 KERNEL   (Huffman, fragmented data): removed
 POLICY   (Huffman, fragmented data): removed
 HOSTCOMM (LZMA   , 0x1cf6b0 - 0x1d648b): removed
 RSA  (LZMA   , 0x1d648b - 0x1db6e0): removed
 CLS  (LZMA   , 0x1db6e0 - 0x1e0e71): removed
 TDT  (LZMA   , 0x1e0e71 - 0x1e7556): removed
 FTCS (Huffman, fragmented data): removed
 ClsPriv  (LZMA   , 0x1e7556 - 0x1e7937): removed
 SESSMGR  (LZMA   , 0x1e7937 - 0x1f6240): removed
Relocating FTPR from 0xd00 - 0xcad00 to 0xd00 - 0xcad00...
 Adjusting FPT entry...
 Adjusting LUT start offset...
 Adjusting Huffman start offset...
 Adjusting chunks offsets...
 Moving data...
*The ME minimum size should be 98304 bytes (0x18000 bytes)*
The ME region can be reduced up to:
 3000:0001afff me
Setting the AltMeDisable bit in PCHSTRP10 to disable Intel ME...
Removing ME/TXE R/W access to the other flash regions...
Extracting and truncating the ME image to "extracted_me.rom"...
Checking the FTPR RSA signature of the extracted ME image... VALID
Checking the FTPR RSA signature... VALID
Done! Good luck!

   - *Librem V3:*
   Full image detected
   Found FPT header at 0x1010
   Found 1 partition(s)
   Found FTPR header: FTPR partition spans from 0x1000 to 0xa8000
   Found FTPR manifest at 0x1448
   *ME/TXE firmware version 11.6.0.1126 (generation 3)*
   Public key match: Intel ME, firmware versions 11.x.x.x
   The HAP bit is SET
   Reading partitions list...
FTPR (0x1000 - 0xa8000, 0x000a7000 total bytes): NOT removed
   Removing partition entries in FPT...
   Removing EFFS presence flag...
   Correcting checksum (0x98)...
   Reading FTPR modules list...
FTPR.man (uncompressed, 0x001448 - 0x002018): NOT removed,
   partition manif.
rbe.met  (uncompressed, 0x002018 - 0x0020ae): NOT removed, module
   metadata
kernel.met   (uncompressed, 0x0020ae - 0x00213c): NOT removed, module
   metadata
syslib.met   (uncompressed, 0x00213c - 0x0021a0): NOT removed, module
   metadata
bup.met  (uncompressed, 0x0021a0 - 0x00274a): NOT removed, module
   metadata
pm.met   (uncompressed, 0x00274a - 0x0027f8): NOT removed, module
   metadata
vfs.met  (uncompressed, 0x0027f8 - 0x003158): NOT removed, module
   metadata
evtdisp.met  (uncompressed, 0x003158 - 0x0032e6): NOT removed, module
   metadata
loadmgr.met  (uncompressed, 0x0032e6 - 0x00340e): NOT removed, module
   metadata
busdrv.met   (uncompressed, 0x00340e - 0x0037b4): NOT removed, module
   metadata
gpio.met (uncompressed, 0x0037b4 - 0x0038fe): NOT removed, module
   metadata
prtc.met (uncompressed, 0x0038fe - 0x003aae): NOT removed, module
   metadata
policy.met   (uncompressed, 0x003aae - 0x003c72): NOT removed, module
   metadata
crypto.met   (uncompressed, 0x003c72 - 0x003dfc): NOT removed, module
   metadata
heci.met (uncompressed, 0x003dfc - 0x003fc8): NOT removed, module
   metadata
storage.met  (uncompressed, 0x003fc8 - 0x0042c4): NOT removed, module
   metadata
pmdrv.met(uncompressed, 0x0042c4 - 0x0043e8): NOT removed, module
   metadata
maestro.met  (uncompressed, 0x0043e8 - 0x0044d2): NOT removed, module
   metadata
fpf.met  (uncompressed, 0x0044d2 - 0x0045de): NOT 

Re: [qubes-users] Re: Recommended laptop?

[Lorenzo Lamas]

Hello Thierry,

Thanks for all that you are doing for the community. Do you see a 
possibility of a Qubes Certified Laptop with an AMD CPU?
Intel is affected a lot more than AMD by the sidechannel vulnerabilities in 
the last years. The Privacy Beast has a 3rd gen Intel CPU, Intel stopped 
providing uCode updates for 1st gen in 2019, so this year is probably the 
last year they will support 3rd gen. More CPU vulnerabilities will most 
certainly be discovered in the coming years, so there is a need for an AMD 
based certified laptop, or at least a newer generation Intel based laptop, 
even though that may mean we're stuck with PSP or ME.

On Tuesday, December 31, 2019 at 9:45:18 PM UTC+1, Thierry Laurion wrote:
>
>
> On Wed, Dec 25, 2019 at 6:03 PM > wrote:
>
>> Insurgo is providing a service.
>>
>> If one can do the steps themselves, that’s fine. 
>>
>> If I were advising a somewhat less technical journalist or a potentially 
>> targeted human-rights worker or politically targeted activist who just 
>> wanted to get stuff done and had the resources, I’d point them to Insurgo.
>>
>> Brendan
>>
>> -- 
>> 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 qubes...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/qubes-users/7a7741f2-6b80-40be-a5a0-0f56b658f9fc%40googlegroups.com
>> .
>>
>
>
> Hello there, Thierry Laurion from Insurgo Open Technologies.
>
> Thanks Brendan.
>
> I feel the need to clarify things a bit once in a while. This reply is one 
> of those. This QubesOS community is large, and even if replies were done on 
> Reddit and other posts here in the past, the same questions arises with the 
> same scattered answers. Here is a combination of those answers.
>
>- Insurgo made grant applications so that actual best trustworthy 
>unmaintained hardware becomes mainstreamed under coreboot, and added under 
>Heads (extend Heads measured boot support of latest coreboot 
> VBOOT+measured 
>boot on Sandy/Ivy bridge xx30 and xx20 platforms:  t530, t430, x220. 
> Thanks 
>to obtained NlNet grant for Accessible Security project).
>- Insurgo is attempting to gather developers, device manufacturers 
>(RaptorEngineering) and funders around Power9-Power10 hardware based X86 
>alternative platform (PPC64le QubesOS platform support which has a bounty 
>offer already but needs commited developers). Let's remember that their 
>Blackbird/Talos II platforms recently got RYF certification.
>   - The last x86 platform having met RYF criteria is the X200, thanks 
>   to the Libreboot project, which removed Intel ME. 
>   - Since then, the x86 platforms have blobs we have to accept/deal 
>   with to make it trustworthier:
>   - Sandy Bridge/Ivy bridge : EC firmware, Intel ME BUP ROMP modules. 
>  Coreboot doesnt rely on FSP blobs for initialization. ME is actually 
>  neutered (no kernel nor syslibs as opposed to newer platforms, just 
> BUP and 
>  ROMP) and deactivated (AltMeDisable bit, not HAP bit).
>  - More recent hardware requires ME with its kernel and syslibs 
>  binary blobs present, while ME is asked to be deactivated through 
> HAP bit, 
>  requires Intel FSP and other binary blobs for hardware 
> initialization.
>  - Insurgo works to bridge the gap to broader QubesOS 
>accessibility, so that users in need of remote support can have secured 
>remote administration from trusted third parties (new revenue? AccessNow? 
>Other third parties?) over hidden tor onion service from additional GUI 
>(NlNet grant for Accessible Security project).
>- Insurgo tries its best to support Heads community through GitHub 
>opened issues while promoting collaboration.
>- Insurgo tries its best to mainstream CI build systems to produce 
>reproducible builds artifacts (this is broken for months and is still not 
>resolved).
>- Insurgo tries to raise awareness of researchers and developers on 
>the current state of "Open Source Firmware" (currently requiring FSP, ME 
> or 
>equivalent,not having completely neutered Intel ME while claiming it is 
>deactivated, while system libraries and kernel is still there but 
>latent...) This implies going to conferences, doing talks, confronting the 
>status quo, researching, developing so we have alternatives in the 
>futurewhile also doing the required clerical work.
>- Insurgo made QubesOS preinstallable for the first time on the 
>PrivacyBeast X230, thanks to its reownership wizard which takes care of 
> GPG 
>key generation, internal ROM reflashing, TPM ownership and sealing of 
>measurements, signing boot configuration, while enforcing diceware 
>passphrases in the provisioning phase. The goal is to 

Re: [qubes-users] Re: Recommended laptop?

[trueriver]

Thanks Thierry,

Thanks for the detailed explanation and thanks for the work you have chosen to 
do. Thanks even more for upstreaming as much as you already have so that others 
can benefit too.

I want too add a couple of points that I hope are supportative, but let me 
start with an analogy.

When I was an impoverished student I used to fix my own car when it went wrong: 
serious problems too, stripping down the engine at one point. I never enjoyed 
it, and as soon as I was earning I gave that work to the local mechanic even 
though I knew how to do it. 

If someone wants the most secure laptop available on a turnkey basis then they 
would buy from you. Maybe they are not expert enough to know all the pitfalls 
you mention; but even if they do know enough they may make the same choice I 
made over car maintenance. They have things to do with their time that they 
prefer to be doing rather than doing IT stuff. AND they can afford to do so.

There are two sorts of people her who will want to do the work for themselves.

There are those of us who enjoy the process and want to actually work through 
the choices for ourselves as the best way to fully understand our own kit. 

And there are also those of us who need to watch every penny, so will do the 
best we can for ourselves within a budget that makes a 230 affordable at second 
hand prices but not at refurb prices.

Actually I'm in both those groups when it comes to IT, and my security needs 
are not so pressing as to need to pay the security premium that your product 
offers. And I enjoy tinkering with software more than I ever enjoyed lying 
under a car in the road when it was snowing.

So you have my sincere thanks for the info you do share (both through the open 
source channels and through posts like this one). And if a friend asks me to 
install a secure OS for them I will send them to you rather than take on a 
lifetime commitment to give them free support. 

Equally, from where I am at the moment I would actually prefer to buy the 
second hand laptop and work through the process myself. But please don't ever 
think that that means I disrespect what you are doing, or that I have any 
problem with your pricing policies. You've made this your work and you are 
totally entitled to make a living out of it. At the end of the day I'm a 
hobbyist.

And it's not just free beer: I pay back when I can, not with currency, but in 
giving advice here when I see other ppl who are struggling with what I already 
solved, by making bug reports, and I've even edited the Qubes docs on a couple 
of occasions. For me free as in speech is a two way process: I come to ask 
questions here, but when I come I always find myself answering questions as 
well. 

So much kudos to you for your choice of making your livelihood, and for 
facilitating hobbyists and those on low budgets by sharing info as well.

Have a great year Thierry

River~~



-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1f1f6c5e-5ed1-4a96-858d-411c84f4f831%40googlegroups.com.

Re: [qubes-users] Re: Recommended laptop?

[Anil Eklavya]

Thanks for putting all this information in one place. I was earlier looking to 
buy Insurgio Privacy Beast, but it was not clear whether it could be shipped to 
India. I then ordered Librem 13.

Is there any comparison available between these two, based on privacy and 
security considerations?

Regards,

Anil Kumar Singh 

> On 01-Jan-2020, at 2:15 AM, Thierry Laurion  wrote:
> 
> 
> 
>> On Wed, Dec 25, 2019 at 6:03 PM  wrote:
>> Insurgo is providing a service.
>> 
>> If one can do the steps themselves, that’s fine. 
>> 
>> If I were advising a somewhat less technical journalist or a potentially 
>> targeted human-rights worker or politically targeted activist who just 
>> wanted to get stuff done and had the resources, I’d point them to Insurgo.
>> 
>> Brendan
>> 
>> -- 
>> 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 qubes-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/qubes-users/7a7741f2-6b80-40be-a5a0-0f56b658f9fc%40googlegroups.com.
> 
> 
> Hello there, Thierry Laurion from Insurgo Open Technologies.
> 
> Thanks Brendan.
> 
> I feel the need to clarify things a bit once in a while. This reply is one of 
> those. This QubesOS community is large, and even if replies were done on 
> Reddit and other posts here in the past, the same questions arises with the 
> same scattered answers. Here is a combination of those answers.
> Insurgo made grant applications so that actual best trustworthy unmaintained 
> hardware becomes mainstreamed under coreboot, and added under Heads (extend 
> Heads measured boot support of latest coreboot VBOOT+measured boot on 
> Sandy/Ivy bridge xx30 and xx20 platforms:  t530, t430, x220. Thanks to 
> obtained NlNet grant for Accessible Security project).
> Insurgo is attempting to gather developers, device manufacturers 
> (RaptorEngineering) and funders around Power9-Power10 hardware based X86 
> alternative platform (PPC64le QubesOS platform support which has a bounty 
> offer already but needs commited developers). Let's remember that their 
> Blackbird/Talos II platforms recently got RYF certification.
> The last x86 platform having met RYF criteria is the X200, thanks to the 
> Libreboot project, which removed Intel ME. 
> Since then, the x86 platforms have blobs we have to accept/deal with to make 
> it trustworthier:
> Sandy Bridge/Ivy bridge : EC firmware, Intel ME BUP ROMP modules. Coreboot 
> doesnt rely on FSP blobs for initialization. ME is actually neutered (no 
> kernel nor syslibs as opposed to newer platforms, just BUP and ROMP) and 
> deactivated (AltMeDisable bit, not HAP bit).
> More recent hardware requires ME with its kernel and syslibs binary blobs 
> present, while ME is asked to be deactivated through HAP bit, requires Intel 
> FSP and other binary blobs for hardware initialization.
> Insurgo works to bridge the gap to broader QubesOS accessibility, so that 
> users in need of remote support can have secured remote administration from 
> trusted third parties (new revenue? AccessNow? Other third parties?) over 
> hidden tor onion service from additional GUI (NlNet grant for Accessible 
> Security project).
> Insurgo tries its best to support Heads community through GitHub opened 
> issues while promoting collaboration.
> Insurgo tries its best to mainstream CI build systems to produce reproducible 
> builds artifacts (this is broken for months and is still not resolved).
> Insurgo tries to raise awareness of researchers and developers on the current 
> state of "Open Source Firmware" (currently requiring FSP, ME or 
> equivalent,not having completely neutered Intel ME while claiming it is 
> deactivated, while system libraries and kernel is still there but latent...) 
> This implies going to conferences, doing talks, confronting the status quo, 
> researching, developing so we have alternatives in the futurewhile also 
> doing the required clerical work.
> Insurgo made QubesOS preinstallable for the first time on the PrivacyBeast 
> X230, thanks to its reownership wizard which takes care of GPG key 
> generation, internal ROM reflashing, TPM ownership and sealing of 
> measurements, signing boot configuration, while enforcing diceware 
> passphrases in the provisioning phase. The goal is to generalize it to other 
> platforms. Ideally through collaboration...
> Insurgo made the PrivacyBeast X230 certified by QubesOS, with a lot of work 
> done on Heads that is unfortunately not upstreamed yet. Will go back at this, 
> while branch is available through Gitlab and GitHub.
> Insurgo collaborates with other parties to make needed work to have fwupd 
> (firmware upgrades), available inside of QubesOS, including Heads firmware, 
> thanks to NlNet Privacy and Trust grant, once again.
> Insurgo tries to push verified boot to measure also the LVM 

Re: [qubes-users] Re: Recommended laptop?

[Thierry Laurion]

On Wed, Dec 25, 2019 at 6:03 PM  wrote:

> Insurgo is providing a service.
>
> If one can do the steps themselves, that’s fine.
>
> If I were advising a somewhat less technical journalist or a potentially
> targeted human-rights worker or politically targeted activist who just
> wanted to get stuff done and had the resources, I’d point them to Insurgo.
>
> Brendan
>
> --
> 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 qubes-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/7a7741f2-6b80-40be-a5a0-0f56b658f9fc%40googlegroups.com
> .
>


Hello there, Thierry Laurion from Insurgo Open Technologies.

Thanks Brendan.

I feel the need to clarify things a bit once in a while. This reply is one
of those. This QubesOS community is large, and even if replies were done on
Reddit and other posts here in the past, the same questions arises with the
same scattered answers. Here is a combination of those answers.

   - Insurgo made grant applications so that actual best trustworthy
   unmaintained hardware becomes mainstreamed under coreboot, and added under
   Heads (extend Heads measured boot support of latest coreboot VBOOT+measured
   boot on Sandy/Ivy bridge xx30 and xx20 platforms:  t530, t430, x220. Thanks
   to obtained NlNet grant for Accessible Security project).
   - Insurgo is attempting to gather developers, device manufacturers
   (RaptorEngineering) and funders around Power9-Power10 hardware based X86
   alternative platform (PPC64le QubesOS platform support which has a bounty
   offer already but needs commited developers). Let's remember that their
   Blackbird/Talos II platforms recently got RYF certification.
  - The last x86 platform having met RYF criteria is the X200, thanks
  to the Libreboot project, which removed Intel ME.
  - Since then, the x86 platforms have blobs we have to accept/deal
  with to make it trustworthier:
  - Sandy Bridge/Ivy bridge : EC firmware, Intel ME BUP ROMP modules.
 Coreboot doesnt rely on FSP blobs for initialization. ME is actually
 neutered (no kernel nor syslibs as opposed to newer
platforms, just BUP and
 ROMP) and deactivated (AltMeDisable bit, not HAP bit).
 - More recent hardware requires ME with its kernel and syslibs
 binary blobs present, while ME is asked to be deactivated
through HAP bit,
 requires Intel FSP and other binary blobs for hardware initialization.
 - Insurgo works to bridge the gap to broader QubesOS
   accessibility, so that users in need of remote support can have secured
   remote administration from trusted third parties (new revenue? AccessNow?
   Other third parties?) over hidden tor onion service from additional GUI
   (NlNet grant for Accessible Security project).
   - Insurgo tries its best to support Heads community through GitHub
   opened issues while promoting collaboration.
   - Insurgo tries its best to mainstream CI build systems to produce
   reproducible builds artifacts (this is broken for months and is still not
   resolved).
   - Insurgo tries to raise awareness of researchers and developers on the
   current state of "Open Source Firmware" (currently requiring FSP, ME or
   equivalent,not having completely neutered Intel ME while claiming it is
   deactivated, while system libraries and kernel is still there but
   latent...) This implies going to conferences, doing talks, confronting the
   status quo, researching, developing so we have alternatives in the
   futurewhile also doing the required clerical work.
   - Insurgo made QubesOS preinstallable for the first time on the
   PrivacyBeast X230, thanks to its reownership wizard which takes care of GPG
   key generation, internal ROM reflashing, TPM ownership and sealing of
   measurements, signing boot configuration, while enforcing diceware
   passphrases in the provisioning phase. The goal is to generalize it to
   other platforms. Ideally through collaboration...
   - Insurgo made the PrivacyBeast X230 certified by QubesOS, with a lot of
   work done on Heads that is unfortunately not upstreamed yet. Will go back
   at this, while branch is available through Gitlab and GitHub.
   - Insurgo collaborates with other parties to make needed work to have
   fwupd (firmware upgrades), available inside of QubesOS, including Heads
   firmware, thanks to NlNet Privacy and Trust grant, once again.
   - Insurgo tries to push verified boot to measure also the LVM containers
   inside of deployed QubesOS reencrypted disk installation, through Heads, so
   that third party OEMs could also deploy reproducible ROMs that are
   measureable, verify their reproducibility, have verified boot and known
   good QubesOS installation with safer defaults to deploy to users by
   themselves (LUKS discards, 

[qubes-users] Re: Recommended laptop?

[brendan . hoar]

On Sunday, December 29, 2019 at 5:35:52 PM UTC-5, Blake S wrote:
>
> On Wednesday, December 25, 2019 at 10:09:24 PM UTC-6, brend...@gmail.com 
> wrote:
>>
>> My own longterm Qubes primary has been a used W520 quad core with four 
>> 8GB DIMMs for 32GB of RAM. Not bad for 2012 era laptop. [Avoid the dual 
>> core versions: they only have two memory slots and can only support 16GB 
>> Max.] 
>>
>
> What BIOS are you using?  I have a W520 coming in soon that I plan to use 
> for Qubes.  I've been using a G505s for a while but it isn't terribly well 
> built and suspend/resume doesn't work on it.
>

Lenovo BIOS for W520, v1.46 (most recent last I checked). 
Qubes R4.0 (updated as of today, including current-testing repo).
Using kernel-latest in dom0 (5.4.3-1, but 5.4.5-1 on next reboot).
Suspend/Resume appear to be working ok.

B

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/14936bfa-4880-4acd-a1d5-9953880dc7a2%40googlegroups.com.

[qubes-users] Re: Recommended laptop?

[Blake S]

On Wednesday, December 25, 2019 at 10:09:24 PM UTC-6, brend...@gmail.com 
wrote:
>
> My own longterm Qubes primary has been a used W520 quad core with four 8GB 
> DIMMs for 32GB of RAM. Not bad for 2012 era laptop. [Avoid the dual core 
> versions: they only have two memory slots and can only support 16GB Max.] 
>
>
> B


What BIOS are you using?  I have a W520 coming in soon that I plan to use 
for Qubes.  I've been using a G505s for a while but it isn't terribly well 
built and suspend/resume doesn't work on it.

-BS
 

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fdaaeef1-530a-4ca2-9cfc-c9dc8ebe1e0d%40googlegroups.com.

[qubes-users] Re: Recommended laptop?

[brendan . hoar]

My own longterm Qubes primary has been a used W520 quad core with four 8GB 
DIMMs for 32GB of RAM. Not bad for 2012 era laptop. [Avoid the dual core 
versions: they only have two memory slots and can only support 16GB Max.]

Storage: 1 x mSATA (300MB/s) slot; 1 x SATA (600MB/s) main bay; 1 x SATA 
(600MB/s) in media tray replacing optical drive; 1 x eSATAp (300MB/s) external 
port. Additional 1 x eSATA (300MB/s) on some docks.  So plenty of fast-enough 
storage options. Plus an SD card slot.

VGA. DisplayPort. Ethernet. WiFi. Modem.

2 x USB 3.0.

2 x USB 2.0 (1 is part of the eSATAp connector). More on some docks.

FireWire and Expresscard (you’d generally want to disable both in bios for 
security reasons). Though...expresscard can be used to add another usb 
controller if two is not enough (e.g. to work around usb pass through issues 
with usbip).

Core unit generally $250-$300 on eBay in ok shape (sans ram and storage which 
you can add yourself).

Bit heavier than the x230, but I appreciate the additional RAM and cores most 
of the time.

Install in legacy mode, disable discrete GPU.

B

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c953df6c-145a-4380-b395-d49b2f4699b8%40googlegroups.com.

[qubes-users] Re: Recommended laptop?

[rec wins]

On 12/25/19 1:03 PM,
brendan.hoar-re5jqeeqqe8avxtiumw...@public.gmane.org wrote:
> Insurgo is providing a service.
> 
> If one can do the steps themselves, that’s fine. 
> 
> If I were advising a somewhat less technical journalist or a potentially 
> targeted human-rights worker or politically targeted activist who just wanted 
> to get stuff done and had the resources, I’d point them to Insurgo.
> 
> Brendan
> 

+1 thinkpads think mine is a x540 or something,  +1 16gb RAM and SSD,
bought my thinkpad used year ago for like $200 add the RAM and SSD ,

apparently some feel Intel isn't really trustworthy  but might have to
pay more for non Intel machines, and roll dice if it has the VT-d or
Iommu  required minimums,  personally I don't use the  TPM though I have
it,  fear I'll likely lock myself out , and don't know what I'm doing in
general :)

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f0dfb38f-d19e-1076-2e8a-645e3d9a99e6%40riseup.net.

[qubes-users] Re: Recommended laptop?

[Yethal]

W dniu wtorek, 24 grudnia 2019 10:43:08 UTC+1 użytkownik Ondřej Šulák 
napisał:
>
> Hello pals,
> for the last release of Qubes, what laptop would you recommend? Is there 
> any cheaper option which does have HW compatibility with latest Qubes 
> (ideally with shipping from EU), than this one:
>
> https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/
>  
> ?
>
> Thanks for any tips!
>
> Ondrej
>

Insurgo isn't really doing anything you can't do yourself with an x230 so 
just buy a regular x230 (they're dirt cheap at this point), put 16gb of ram 
and an ssd inside and then flash heads on there 

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fa3b1fa1-2096-4276-b5d4-78a24ebdeba4%40googlegroups.com.