Re: [qubes-users] Creating snapshot

[Thierry Laurion - Insurgo Technologies Libres / Open Technologies]

I'm talking on top of my head but snapshots are supposed to be taken 
automatically, with 2 reverts possible, by default.

qvm-volume
qvm-volume revert windows:root
qvm-volume revert windows:private

On February 18, 2020 9:26:30 PM UTC, brendan.h...@gmail.com wrote:
>Assuming a standard qubes 4.0.x install, just clone the VM each time
>you are making risky changes...before each change of course.*
>
>The use of lvm thin pool makes clones essentially use zero storage
>other that the bits where they diverge from the original VM, where copy
>on write preserves the differences.
>
>Brendan
>
>* ok, technically...make the clone anytime *before* shutting down the
>vm after the risky change...but purposely cutting it that close has
>risks.
>
>-- 
>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/8f1c91d3-c6ae-4822-9e0c-5daa55d5c29d%40googlegroups.com.

-- Sent from /e/ Mail

-- 
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/9344D6D8-0EAE-4B22-B105-3FDFAB57C836%40gmail.com.

Re: [qubes-users] How to setup Win10 HVM ?

[Thierry Laurion - Insurgo Technologies Libres / Open Technologies]

On February 15, 2020 2:18:33 PM UTC, A E  wrote:
>fre. 14. feb. 2020 kl. 12.56 skrev unman :
>
>> On Fri, Feb 14, 2020 at 08:19:13AM +0100, A E wrote:
>> > Okay, I read your message again.
>> >
>> > It shall just turn up in the file list of dom0.
>> >
>> > I???ll look later.
>> >
>> >
>> > fre. 14. feb. 2020 kl. 08.14 skrev A E :
>> >
>> > > Okay, thanks.
>> > >
>> > > How can I see if the "install.sh" file has been created in dom0 ?
>> > >
>> > >
>>
>> The convention here is not to top-post.
>> Please scroll to the bottom of the message before you start typing.
>Or
>> reply inline.
>> It only takes you seconds, makes it much easier to follow threads,
>and
>> cumulatively saves your fellow users hours.
>> Thanks.
>> unman
>>
>> --
>> You received this message because you are subscribed to a topic in
>the
>> Google Groups "qubes-users" group.
>> To unsubscribe from this topic, visit
>>
>https://groups.google.com/d/topic/qubes-users/78DgmWxZf80/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/20200214115648.GA688%40thirdeyesecurity.org
>> .
>>
>
>
>Yes, install.sh was copied to dom0. I just thought the terminal would
>say
>so after it did this.
>
>The pc is downloading now.
>
>I wonder why Windows 7 has to be installed before Windows 10...
>especially
>as Microsoft has stopped supporting it and it takes about 2 hours to
>download it and I don’t have any product code for it. So maybe I can’t
>even
>use it.

Has someone tried to active with a windows 7 license?

>
>Besides that, I appreciate and thanks Elliot Killick for the easy to
>use
>installation script.

-- Sent from /e/ Mail

-- 
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/7B09E9CA-3B10-4EB6-9B13-9FCAB1D992E4%40gmail.com.

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   
> > <mailto:tas...@posteo.net >> 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 c

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
<https://github.com/osresearch/heads/issues/134#issuecomment-368922440>).
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 <https://github.com/PSPReverse/PSPTool> 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?

[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?

[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
<https://github.com/osresearch/heads/issues/453> 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
<https://github.com/QubesOS/qubes-issues/issues/4318#issuecomment-549986749>
.

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/

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

[Thierry Laurion]

: NOT removed, module
   metadata
touch_fw.met (uncompressed, 0x0048fe - 0x004a40): NOT removed, module
   metadata



* rbe  (Huffman , 0x004a40 - 0x0070c0): NOT removed, essential
kernel   (Huffman , 0x0070c0 - 0x015dc0): NOT removed, essential
syslib   (Huffman , 0x015dc0 - 0x028a00): NOT removed, essential
bup  (Huffman , 0x028a00 - 0x051600): NOT removed, essential*
pm   (LZMA/uncomp., 0x051600 - 0x053f80): removed
syncman  (LZMA/uncomp., 0x053f80 - 0x0544c0): removed
vfs  (LZMA/uncomp., 0x0544c0 - 0x05c2c0): removed
evtdisp  (LZMA/uncomp., 0x05c2c0 - 0x05dd40): removed
loadmgr  (LZMA/uncomp., 0x05dd40 - 0x060b80): removed
busdrv   (LZMA/uncomp., 0x060b80 - 0x063980): removed
gpio (LZMA/uncomp., 0x063980 - 0x064e00): removed
prtc (LZMA/uncomp., 0x064e00 - 0x065bc0): removed
policy   (LZMA/uncomp., 0x065bc0 - 0x06c280): removed
crypto   (LZMA/uncomp., 0x06c280 - 0x07be00): removed
heci (LZMA/uncomp., 0x07be00 - 0x07fec0): removed
storage  (LZMA/uncomp., 0x07fec0 - 0x084640): removed
pmdrv(LZMA/uncomp., 0x084640 - 0x085e40): removed
maestro  (LZMA/uncomp., 0x085e40 - 0x088d40): removed
fpf  (LZMA/uncomp., 0x088d40 - 0x08a740): removed
hci  (LZMA/uncomp., 0x08a740 - 0x08afc0): removed
fwupdate (LZMA/uncomp., 0x08afc0 - 0x08f840): removed
ptt  (LZMA/uncomp., 0x08f840 - 0x0a3980): removed
touch_fw (LZMA/uncomp., 0x0a3980 - 0x0a8000): removed
   *The ME minimum size should be 352256 bytes (0x56000 bytes)*
   Checking the FTPR RSA signature... VALID
   Done! Good luck!


   - X230's coreboot doesn't depend on Intel FSP binary blobs on the x230
   nor any others
   
<https://github.com/osresearch/heads/blob/master/config/coreboot-x230.config>.
   Librem's depend on those
   
<https://github.com/osresearch/heads/blob/master/config/coreboot-librem15v4.config>
   .
   - There is no mechanical switch for the webcam nor microphone on X230,
   while those are isolated under QubesOS (microphone: dom0; not network,
   webcam: sys-usb; no network) and require explicit assignment to AppVM it
   will be used in prior to usage. A nice project exists to mod the
   X230/X220 <https://hackaday.io/project/164343-nsa-b-gone> but
   prototyping has not taken off by the community to simplify and make build
   reproducible enough to be included.
   - Both X230 and Librems provide a wifi mechanical switch, while again,
   QubesOS isolates network from the rest of the system out of the box,
   relying on routing between defined gateways, firewalls and network. AppVMs
   that do not need networking doesn't.
   - The PrivacyBeast strongly emphasize on the importance of setting a
   Disk Unlock Key, released by the TPM only if firmware measurements are
   known and user supplies the valid valid passphrase to unlock encrypted LUKS
   container with a second decryption key to boot QubesOS. This security
   measure mitigate the risk of having a third party record keystrokes and be
   able to unlock remotely the cloned disk, since the user doesn't type the
   Disk Recovery Key passphrase to boot his laptop. Purism chose to base their
   disk unlock feature on their USB security dongle and unlock the LUKS
   container when provided with passphrase for the security dongle (untested
   from me).


> 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 actu

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?

[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 instal

Re: [qubes-users] Re: Announcement: Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification

[Thierry Laurion]

m a écrit :
>
> Guyz, this is not serious.
>
> >100$ laptop
> >chink keyboard
> >lost battery
> >flashed with a $5 ch341a coreboot
>
>
> среда, 24 июля 2019 г., 20:48:11 UTC+3 пользователь Thierry Laurion 
> написал:
>>
>>
>>
>> On Wed, Jul 24, 2019 at 1:16 PM  wrote:
>>
>>> >sandybridge
>>> >
>>>
>>> $1,581.00
>>>  
>>> laught high.
>>>
>> I can understand seeing the total price. The reality is 946$CAD, though 
>> for the Grade A refurbished laptop i7 2.9ghz, 16GB ram, 256Gb SSD drive and 
>> IPS screen. See product description. You pay an additional 500$CAD to have 
>> integrity attestation of firmware and QubesOS preinstallation, while 
>> supporting what I try to accomplish. 
>>
>> Else you can do it yourself from locally available hardware, but I doubt 
>> you can find equivalent quality refurb grade A equivalent hardware with 
>> competitive price. 
>> The OEM Re-Ownership wizard in action, with important links and 
>> references: https://archive.org/details/oemuserreownership
>>
>> Regards,
>> Thierry Laurion/Insurgo
>>
>>
>>>
>>>
>>> пятница, 19 июля 2019 г., 7:19:37 UTC+3 пользователь Andrew David Wong 
>>> написал:
>>>>
>>>> -BEGIN PGP SIGNED MESSAGE- 
>>>> Hash: SHA512 
>>>>
>>>> Dear Qubes Community, 
>>>>
>>>> We are very pleased to announce that the Insurgo PrivacyBeast X230 [1] 
>>>> has passed Qubes 4.0 Hardware Certification and is now a 
>>>> Qubes-certified 
>>>> Laptop! [2] 
>>>>
>>>> ## What is Qubes Certified Hardware? 
>>>>
>>>> Qubes Certified Hardware [3] is hardware that has been certified by the 
>>>> Qubes developers as compatible with Qubes OS. Beginning with Qubes 4.0, 
>>>> in order to achieve certification, the hardware must satisfy a rigorous 
>>>> set of requirements [4], and the vendor must commit to offering 
>>>> customers the very same configuration (same motherboard, same screen, 
>>>> same BIOS version, same Wi-Fi module, etc.) for at least one year. 
>>>>
>>>> Qubes-certified Laptops [2], in particular, are regularly tested 
>>>> by the Qubes developers to ensure compatibility with all of Qubes' 
>>>> features. The developers test all new major versions and updates to 
>>>> ensure that no regressions are introduced. 
>>>>
>>>> It is important to note, however, that Qubes Hardware Certification 
>>>> certifies only that a particular hardware *configuration* is 
>>>> *supported* 
>>>> by Qubes. The Qubes OS Project takes no responsibility for any 
>>>> manufacturing or shipping processes, nor can we control whether 
>>>> physical 
>>>> hardware is modified (whether maliciously or otherwise) *en route* to 
>>>> the user. (However, see below for information about how the Insurgo 
>>>> team mitigates this risk.) 
>>>>
>>>> ## About the Insurgo PrivacyBeast X230 Laptop 
>>>>
>>>> The Insurgo PrivacyBeast X230 [1] is a custom refurbished ThinkPad X230 
>>>> [5] that not only *meets* all Qubes Hardware Certification requirements 
>>>> [4] but also *exceeds* them thanks to its unique configuration, 
>>>> including: 
>>>>
>>>>   - Coreboot [6] initialization for the x230 is binary-blob-free, 
>>>> including native graphic initialization. Built with the 
>>>> Heads [7] payload, it delivers an Anti Evil Maid (AEM) [8]-like 
>>>> solution built into the firmware. (Even though our requirements [4] 
>>>> provide an exception for CPU-vendor-provided blobs for silicon and 
>>>> memory initialization, Insurgo exceeds our requirements by 
>>>> insisting 
>>>> that these be absent from its machines.) 
>>>>
>>>>   - Intel ME [9] is neutered through the AltMeDisable bit, while all 
>>>> modules other than ROMP and BUP, which are required to initialize 
>>>> main CPU, have been deleted. [10] 
>>>>
>>>>   - A re-ownership process that allows it to ship pre-installed with 
>>>> Qubes OS, including full-disk encryption already in place, but 
>>>> where the final disk encryption key is regenerated only when the 
>>>> machine is first powered on by the user, so that the OEM doesn

Re: [qubes-users] Re: Announcement: Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification

[Thierry Laurion]

On Wed, Jul 24, 2019 at 1:16 PM  wrote:

> >sandybridge
> >
>
> $1,581.00
>
> laught high.
>
I can understand seeing the total price. The reality is 946$CAD, though for
the Grade A refurbished laptop i7 2.9ghz, 16GB ram, 256Gb SSD drive and IPS
screen. See product description. You pay an additional 500$CAD to have
integrity attestation of firmware and QubesOS preinstallation, while
supporting what I try to accomplish.

Else you can do it yourself from locally available hardware, but I doubt
you can find equivalent quality refurb grade A equivalent hardware with
competitive price.
The OEM Re-Ownership wizard in action, with important links and references:
https://archive.org/details/oemuserreownership

Regards,
Thierry Laurion/Insurgo


>
>
> пятница, 19 июля 2019 г., 7:19:37 UTC+3 пользователь Andrew David Wong
> написал:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> Dear Qubes Community,
>>
>> We are very pleased to announce that the Insurgo PrivacyBeast X230 [1]
>> has passed Qubes 4.0 Hardware Certification and is now a Qubes-certified
>> Laptop! [2]
>>
>> ## What is Qubes Certified Hardware?
>>
>> Qubes Certified Hardware [3] is hardware that has been certified by the
>> Qubes developers as compatible with Qubes OS. Beginning with Qubes 4.0,
>> in order to achieve certification, the hardware must satisfy a rigorous
>> set of requirements [4], and the vendor must commit to offering
>> customers the very same configuration (same motherboard, same screen,
>> same BIOS version, same Wi-Fi module, etc.) for at least one year.
>>
>> Qubes-certified Laptops [2], in particular, are regularly tested
>> by the Qubes developers to ensure compatibility with all of Qubes'
>> features. The developers test all new major versions and updates to
>> ensure that no regressions are introduced.
>>
>> It is important to note, however, that Qubes Hardware Certification
>> certifies only that a particular hardware *configuration* is *supported*
>> by Qubes. The Qubes OS Project takes no responsibility for any
>> manufacturing or shipping processes, nor can we control whether physical
>> hardware is modified (whether maliciously or otherwise) *en route* to
>> the user. (However, see below for information about how the Insurgo
>> team mitigates this risk.)
>>
>> ## About the Insurgo PrivacyBeast X230 Laptop
>>
>> The Insurgo PrivacyBeast X230 [1] is a custom refurbished ThinkPad X230
>> [5] that not only *meets* all Qubes Hardware Certification requirements
>> [4] but also *exceeds* them thanks to its unique configuration,
>> including:
>>
>>   - Coreboot [6] initialization for the x230 is binary-blob-free,
>> including native graphic initialization. Built with the
>> Heads [7] payload, it delivers an Anti Evil Maid (AEM) [8]-like
>> solution built into the firmware. (Even though our requirements [4]
>> provide an exception for CPU-vendor-provided blobs for silicon and
>> memory initialization, Insurgo exceeds our requirements by insisting
>> that these be absent from its machines.)
>>
>>   - Intel ME [9] is neutered through the AltMeDisable bit, while all
>> modules other than ROMP and BUP, which are required to initialize
>> main CPU, have been deleted. [10]
>>
>>   - A re-ownership process that allows it to ship pre-installed with
>> Qubes OS, including full-disk encryption already in place, but
>> where the final disk encryption key is regenerated only when the
>> machine is first powered on by the user, so that the OEM doesn't
>> know it.
>>
>>   - Heads [7] provisioned pre-delivery to protect against malicious
>> interdiction. [11]
>>
>> ## How to get one
>>
>> Please see the Insurgo PrivacyBeast X230 [1] on the Insurgo website [12]
>> for more information.
>>
>> ## Acknowledgements
>>
>> Special thanks go to:
>>
>>   - Thierry Laurion [13], Director of Insurgo, Technologies Libres (Open
>> Technologies), for spearheading this effort and making Heads+Qubes
>> laptops more broadly accessible.
>>
>>   - Trammell Hudson [14], for creating Heads [7].
>>
>>   - Purism [15], for greatly improving the UX of Heads [7], including
>> the GUI menu, and for adding Nitrokey [16] and Librem Key [17]
>> support.
>>
>>
>>  [1]
>> https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/
>>  [2]
>> https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptop-insu

Re: [qubes-users] Announcement: Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification

[Thierry Laurion]

On Wed, Jul 24, 2019 at 7:16 AM Matthew Finkel 
wrote:

> Hi Thierry,
>
> Thanks for the response. Maybe I'm not looking at the correct page.On
>
> https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/
> I see it says:
>
> "2x Fast USB 3. 0 ports (left side blue ports) + 1x USB 2.0 port
> (right side yellow port)"
>
> But I don't see any mention of the number of distinct USB controllers
> - specifically the number of controllers (and USB ports) that can be
> isolated per qube.
>
There is 3 usb-controllers, all attached to sys-usb by default, added to
the sdcard controller. See attachment.


> Thanks,
>
> On Mon, Jul 22, 2019 at 3:21 PM Thierry Laurion
>  wrote:
> >
> > This is detailed under product page.
> > Thanks
> >
> > On Sun, Jul 21, 2019, 03:34 Matthew Finkel, 
> wrote:
> >>
> >> On Friday, July 19, 2019, Andrew David Wong  wrote:
> >>>
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA512
> >>>
> >>> Dear Qubes Community,
> >>>
> >>> We are very pleased to announce that the Insurgo PrivacyBeast X230 [1]
> >>> has passed Qubes 4.0 Hardware Certification and is now a
> Qubes-certified
> >>> Laptop! [2]
> >>
> >>
> >>  Can you say how many USB controllers this laptop has?
> >>
> >> Thanks,
> >> Matt
> >>
> >>
> >> --
> >> Matthew Finkel
> >>
> >> --
> >> 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/CAGF8hsvas-dcbgYYaHhtjerfnyMV9AO%3D0Dnd3ALoL5zhqKw3fQ%40mail.gmail.com
> .
>
>
>
> --
> Matthew Finkel
>

-- 
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/CAAzJznzSFHLd8sSKHOps%3Dn1w6_WkfwwXdyjkbf01YyhsykUMJg%40mail.gmail.com.

Re: [qubes-users] Re: Announcement: Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification

[Thierry Laurion]

 VM to leverage 
side-channel theoretical attack impacts.
Best would be to completely externalize internal SPI flash or design an 
equivalent. 

Something that could be hacked on on already existing hardware, or designed 
from scratch.
Interesting work by Trammel Hudson that can be transferred to this: 
https://github.com/osresearch/spispy

There are funds available for such projects. NL, OpenTech funds. We only 
need to organize :) 

But you're right. I'm not a hardware designer. I cannot take that lead.
But I think we should all collaborate on this to make it reality.

Cheers,
Thierry Laurion / Insurgo Open Technologies

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

Le lundi 22 juillet 2019 11:40:44 UTC-4, Chris Laprise a écrit :
>
> On 7/21/19 5:44 PM, Lorenzo Lamas wrote: 
> > Very nice to finally have a certified Qubes laptop! 
> > 
> > Personally, for me it would be nice if there was a more powerful 
> > alternative in the future. I'm currently using something with about the 
> > same resource power and I find myself often wishing I had something 
> > faster because Qubes is quite heavy compared to a standard OS. It would 
> > be great to have a quad core CPU(and a proper one, not one of those 
> > power-saving U line from Intel), 32GB RAM or more and a NVMe SSD instead 
> > of SATA. 
> > Also, there is the issue of the CPU being a 3rd gen Intel i CPU. Maybe 
> > this is specifically chosen because later CPU's are harder to get blob 
> > free, I don't know the details. However, Intel had quite a few side 
> > channel vulnerabilities over the past year, and this year they dropped 
> > microcode update support for 1st gen CPU's, so there is a pretty high 
> > chance they will drop 2nd gen support next year and 3rd gen support the 
> > year after that. 
>
> There is even one statement from Intel out there that they've 
> tentatively already dropped support for 3rd gen (which is what the X230 
> and its 'sister' the T430s uses). 
>
> The Lenovo G505s should be slightly more powerful than the X230, and its 
> AMD A10 processor is significantly less prone to attack. 
>
> The only problems with it are that HEADS doesn't work (not a big 
> disadvantage, given how vulnerable X230's older TPM is), and to install 
> Qubes you need to flash it with a Coreboot config that requires you to 
> add an un-signed graphics driver (I think if enough people posted SHA256 
> hashes of the driver it wouldn't be a big problem). 
>
> It also accepts ECC RAM, which reduces the DDR3 side-channel 
> vulnerabilities somewhat. 
>
> So the alternative to the 2012 laptop is the 2013 laptop. A bit 
> underwhelming. 
>
> - 
>
> The overall problem here is none of these open source OS projects are 
> true integrators or designers, not when it has anything to do with 
> hardware. This is why Qubes project will identify USB controller 
> isolation as a major issue, but then do nothing about it (note the X230 
> is lacking a secondary USB controller). They'll say Intel or X86 is 
> fundamentally insecure, but won't begin to describe what a good 
> alternative would look like at the component level; without that, 
> there's nothing into which the hardware people to sink their teeth or 
> even notice Qubes. 
>
> -- 
>
> 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/abacc82c-3463-4526-b754-2b1d78a41bd5%40googlegroups.com.

Re: [qubes-users] Re: Announcement: Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification

[Thierry Laurion]

That model is unfortunately not really available to redistribute. The SPI flash 
isn't big enough to support Heads features right now, even though the  Librem 
Key could be used to support firmware and boot integrity attestation.

There is a ticket opened on Heads project page to make that device supported. 
But that device cannot be used to preinstall QubesOS as of right now.

Tasket: you have references to 3rd gen Intel support drop?



On July 22, 2019 3:40:39 PM UTC, Chris Laprise  wrote:
>On 7/21/19 5:44 PM, Lorenzo Lamas wrote:
>> Very nice to finally have a certified Qubes laptop!
>> 
>> Personally, for me it would be nice if there was a more powerful 
>> alternative in the future. I'm currently using something with about
>the 
>> same resource power and I find myself often wishing I had something 
>> faster because Qubes is quite heavy compared to a standard OS. It
>would 
>> be great to have a quad core CPU(and a proper one, not one of those 
>> power-saving U line from Intel), 32GB RAM or more and a NVMe SSD
>instead 
>> of SATA.
>> Also, there is the issue of the CPU being a 3rd gen Intel i CPU.
>Maybe 
>> this is specifically chosen because later CPU's are harder to get
>blob 
>> free, I don't know the details. However, Intel had quite a few side 
>> channel vulnerabilities over the past year, and this year they
>dropped 
>> microcode update support for 1st gen CPU's, so there is a pretty high
>
>> chance they will drop 2nd gen support next year and 3rd gen support
>the 
>> year after that.
>
>There is even one statement from Intel out there that they've 
>tentatively already dropped support for 3rd gen (which is what the X230
>
>and its 'sister' the T430s uses).
>
>The Lenovo G505s should be slightly more powerful than the X230, and
>its 
>AMD A10 processor is significantly less prone to attack.
>
>The only problems with it are that HEADS doesn't work (not a big 
>disadvantage, given how vulnerable X230's older TPM is), and to install
>
>Qubes you need to flash it with a Coreboot config that requires you to 
>add an un-signed graphics driver (I think if enough people posted
>SHA256 
>hashes of the driver it wouldn't be a big problem).
>
>It also accepts ECC RAM, which reduces the DDR3 side-channel 
>vulnerabilities somewhat.
>
>So the alternative to the 2012 laptop is the 2013 laptop. A bit 
>underwhelming.
>
>-
>
>The overall problem here is none of these open source OS projects are 
>true integrators or designers, not when it has anything to do with 
>hardware. This is why Qubes project will identify USB controller 
>isolation as a major issue, but then do nothing about it (note the X230
>
>is lacking a secondary USB controller). They'll say Intel or X86 is 
>fundamentally insecure, but won't begin to describe what a good 
>alternative would look like at the component level; without that, 
>there's nothing into which the hardware people to sink their teeth or 
>even notice Qubes.
>
>-- 
>
>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/8cd5347b-a30d-3af6-a254-e059be7a4907%40posteo.net.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/161580D7-2ADD-4941-9F02-F6E3EB647FC6%40gmail.com.

Re: [qubes-users] Re: Announcement: Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification

[Thierry Laurion]

On July 19, 2019 9:32:52 PM UTC, 'awokd' via qubes-users 
 wrote:
>Thierry Laurion:
>> Hello all.
>> 
>> For those of you who would want to ask questions but are against
>using
>> Google services/Twitter/Facebook, you are more then welcome to
>comment post
>> on my ZeroNet technical blog:
>>
>http://127.0.0.1:43110/1DMb3CV66qZPwJqkgm4z12nu8BrAwDoD4g/?Post:26:PrivacyBeast+X230+is+alive!!!
>
>Unless you hacked my computer, I don't think the above link is going to
>
>work. :)

This is ZeroNet URL. :)
It can be accessed through a clearnet proxy here for read access:

https://zero.acelewis.com/#1DMb3CV66qZPwJqkgm4z12nu8BrAwDoD4g/?Post:26:PrivacyBeast+X230+is+alive!!!

>
>Otherwise, nice work with the laptop!
Thanks!

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/325EED15-FF83-4B9A-9ED3-788C045D951C%40gmail.com.

[qubes-users] Re: Announcement: Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification

[Thierry Laurion]

Hello all.

For those of you who would want to ask questions but are against using 
Google services/Twitter/Facebook, you are more then welcome to comment post 
on my ZeroNet technical blog:
http://127.0.0.1:43110/1DMb3CV66qZPwJqkgm4z12nu8BrAwDoD4g/?Post:26:PrivacyBeast+X230+is+alive!!!

Cheers,
Thierry Laurion
Insurgo Open Technologies/Technologies Libres

Le vendredi 19 juillet 2019 00:19:37 UTC-4, Andrew David Wong a écrit :
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA512 
>
> Dear Qubes Community, 
>
> We are very pleased to announce that the Insurgo PrivacyBeast X230 [1] 
> has passed Qubes 4.0 Hardware Certification and is now a Qubes-certified 
> Laptop! [2] 
>
> ## What is Qubes Certified Hardware? 
>
> Qubes Certified Hardware [3] is hardware that has been certified by the 
> Qubes developers as compatible with Qubes OS. Beginning with Qubes 4.0, 
> in order to achieve certification, the hardware must satisfy a rigorous 
> set of requirements [4], and the vendor must commit to offering 
> customers the very same configuration (same motherboard, same screen, 
> same BIOS version, same Wi-Fi module, etc.) for at least one year. 
>
> Qubes-certified Laptops [2], in particular, are regularly tested 
> by the Qubes developers to ensure compatibility with all of Qubes' 
> features. The developers test all new major versions and updates to 
> ensure that no regressions are introduced. 
>
> It is important to note, however, that Qubes Hardware Certification 
> certifies only that a particular hardware *configuration* is *supported* 
> by Qubes. The Qubes OS Project takes no responsibility for any 
> manufacturing or shipping processes, nor can we control whether physical 
> hardware is modified (whether maliciously or otherwise) *en route* to 
> the user. (However, see below for information about how the Insurgo 
> team mitigates this risk.) 
>
> ## About the Insurgo PrivacyBeast X230 Laptop 
>
> The Insurgo PrivacyBeast X230 [1] is a custom refurbished ThinkPad X230 
> [5] that not only *meets* all Qubes Hardware Certification requirements 
> [4] but also *exceeds* them thanks to its unique configuration, 
> including: 
>
>   - Coreboot [6] initialization for the x230 is binary-blob-free, 
> including native graphic initialization. Built with the 
> Heads [7] payload, it delivers an Anti Evil Maid (AEM) [8]-like 
> solution built into the firmware. (Even though our requirements [4] 
> provide an exception for CPU-vendor-provided blobs for silicon and 
> memory initialization, Insurgo exceeds our requirements by insisting 
> that these be absent from its machines.) 
>
>   - Intel ME [9] is neutered through the AltMeDisable bit, while all 
> modules other than ROMP and BUP, which are required to initialize 
> main CPU, have been deleted. [10] 
>
>   - A re-ownership process that allows it to ship pre-installed with 
> Qubes OS, including full-disk encryption already in place, but 
> where the final disk encryption key is regenerated only when the 
> machine is first powered on by the user, so that the OEM doesn't 
> know it. 
>
>   - Heads [7] provisioned pre-delivery to protect against malicious 
> interdiction. [11] 
>
> ## How to get one 
>
> Please see the Insurgo PrivacyBeast X230 [1] on the Insurgo website [12] 
> for more information. 
>
> ## Acknowledgements 
>
> Special thanks go to: 
>
>   - Thierry Laurion [13], Director of Insurgo, Technologies Libres (Open 
> Technologies), for spearheading this effort and making Heads+Qubes 
> laptops more broadly accessible. 
>
>   - Trammell Hudson [14], for creating Heads [7]. 
>
>   - Purism [15], for greatly improving the UX of Heads [7], including 
> the GUI menu, and for adding Nitrokey [16] and Librem Key [17] 
> support. 
>
>
>  [1] 
> https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/
>  
>  [2] 
> https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptop-insurgo-privacybeast-x230
>  
>  [3] https://www.qubes-os.org/doc/certified-hardware/ 
>  [4] 
> https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-requirements
>  
>  [5] https://www.thinkwiki.org/wiki/Category:X230 
>  [6] https://www.coreboot.org/ 
>  [7] https://github.com/osresearch/heads/ 
>  [8] https://www.qubes-os.org/doc/anti-evil-maid/ 
>  [9] https://libreboot.org/faq.html#intelme 
> [10] 
> https://github.com/osresearch/heads-wiki/blob/master/Clean-the-ME-firmware.md#how-to-disabledeactive-most-of-it
>  
> [11] https://en.wikipedia.org/wiki/Interdiction 
> [12] https://insurgo.ca 
> [13] https://www.linkedin.com/in/thierry-laurion-40b

Re: [qubes-users] Re: HCL - Vikings D8

[Thierry Laurion]

Because HCL reports are community based. See guidelines for posting HCL:
https://www.qubes-os.org/doc/hcl/#generating-and-submitting-new-reports

On June 16, 2019 12:33:36 PM UTC, cubalibre2...@gmail.com wrote:
>Why is this not yet in the Qubes HCL? I'm running a KCMA-D8 and it
>works with Qubes.
>
>-- 
>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 post to this group, send email to qubes-users@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/qubes-users/0131d0d9-49fe-4ac7-addf-4d85232bec38%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/B2BF2192-4EE0-4231-96A2-D78F34D1D9E2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] how to use app-shutdown-idle

[Thierry Laurion]

On Mon, Apr 29, 2019, 04:36 ,  wrote:

> Hi!
>
> According to https://github.com/QubesOS/updates-status/issues/782 the
> script "app-shutdown-idle" is included in the latest stable templates.
> How to enable/use it? Unfortunately, I couldn't find any documentation in
> https://github.com/QubesOS/qubes-app-shutdown-idle to use it.
>
"The mechanism is opt-in - enable shutdown-idle service in qube settings to
use it."
Which litterally means what it says.

>
> Best, Pete
>
> --
> 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 post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/fae7f7e6-7983-6b87-065f-fa79e149cfec%40gmx.de
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [qubes-users] HCL - Purism Librem 13 v2

[Thierry Laurion]

On November 14, 2018 9:14:58 PM UTC, 799  wrote:
>Hello 22rip,
>
>Am Mo., 12. Nov. 2018, 03:26 hat <22...@tutamail.com> geschrieben:
>
>> (...)
>> However I think your "..Pretty easy to maintain.." would be hell for
>me.
>> (...)
>> I checked out the x230 and you are right they are available and
>cheap. I
>> would still be interested in finding some company/individual who I
>can
>> trust to take care of the BIOS flashing for me as a service
>
>(I would think others would also want this service as well...). The
>problem
>> is who?
>>
>
>I was at the same point some time ago and afraid to give coreboot a
>try.
>I went to a hacking space and got some help from experienced
>"Coreboot'ers".
>I've seen that it is not that hard to build Coreboot and tried it
>myself
>from scratch.
>If you own a X230 you might want to look at my How-to which I wrote
>during
>the process and is targeted at coreboot newbies:
>
>https://github.com/Qubes-Community/Contents/blob/master/docs/coreboot/x230.md
>
>If you need further help, do not hesitate to ask.
>It's really not that hard to use coreboot.
>
>- O
>
>-- 
>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 post to this group, send email to qubes-users@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/qubes-users/CAJ3yz2uRx8c_fQ2dxvuJwwqiy_s_Mtr3aSXyz6wxFpFYYv237g%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.

Hi all,
Last intrusion to this thread.

I would strongly advise digging into the skulls project anyone interested in 
flashing coreboot into their x230 themselves :  
https://github.com/merge/skulls/blob/master/README.md

Sincerely, 
Thierry

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/881038F9-9D0E-4FE8-B916-7BC3B2709F37%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] HCL - Purism Librem 13 v2

[Thierry Laurion]

Hi all,
Sorry to have misadvertised Purism work. Didn't went across that post:
https://puri.sm/posts/neutralizing-intel-management-engine-on-librem-laptops/
So it seems that Intel ME deactivation is on par with Ivy bridge, resulting
in only the ROMP and BUP modules being required to initialize ME.

For firmware binary blob requirements, FSP is still required, see here:
https://github.com/osresearch/heads/tree/master/blobs/librem_skl and here
https://github.com/osresearch/heads/blob/master/config/coreboot-librem13v2.config

Thierry


On Tue, Nov 13, 2018 at 10:44 AM Thierry Laurion 
wrote:

>  Hi qubes-fan. Answers inline.
> On Tue, Nov 13, 2018 at 6:27 AM  wrote:
>
>> Hi Thiery, I wasn't aware the X230 can be freed same way as the X200 can.
>
> Unfortunately, the x230 cannot have Intel ME deleted the same way the x200
> can, even though binary free firmware is par with it.
>
> The x200 is RYF certified where the x230 isn't for approximately the same
> reasons Libreboot supports only the former. RYF and Libreboot have a really
> strong guideline against binary blobs. Even Libreboot opened up it's ethic
> to support the x220 (Sandy bridge), but backed off, since part of the ME
> engine is still present even if deactivated. The RYF certification could
> not be obtainable for those. See archive:
> https://web.archive.org/web/20170404144825/https://minifree.org/product/libreboot-x220/
>
> Intel ME can be completely removed on the x200 (GM45 based), leaving no
> trace of it at all. (https://libreboot.org/faq.html#intel). It can be
> neutralized on the x220 and x230 (Ivy bridge), leaving only the ROMP and
> BUP modules (<90k of it), but "deactivating" ME before it's kernel is even
> booted, where the Librem Laptops have parts of it deactivated only, and
> unfortunately contains binary blobs in the firmware. Once again, depending
> of your threat model, that may or not be a deal breaker for you.
>
> Neutralizing/Deactivating/Deleting/Freeing Intel ME is a word game where a
> lot of ink spilled over the last years. I suggest you to read this doc: (
> https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F) .
> Basically, Intel ME version <11 can be deactivated, since no kernel needs
> to be present in the firmware for validation prior to initialization,
> resulting in the BUP module only being launched, permitting the machine to
> boot, where version >11 requires the kernel and syslib modules to be
> present and validated at initialization. So even if Intel ME is neutralized
> by me_cleaner, the modules are still there in >11. Could they be executed?
> That depends on your beliefs and threat modeling.
>
> Technically, GM45 based laptops are currently the last Intel based
> hardware where Intel ME can be completely removed. Unfortunately, such old
> hardware comes with important limitations, some of which makes it
> incompatible with QubesOS 4 requirements for isolation and virtualization.
> The x200 has vt-d1 only, no vt-d2 (No IOMMU!): there is no interrupt
> remapping, meaning that there is no hardware isolation enforced in QubesOS.
> (
> https://github.com/QubesOS/qubes-issues/issues/1594#issuecomment-209213917
> ).
>
> At best, the x200 is an awesome laptop for using Tails, but not with
> QubesOS. Using it with QubesOS gives the user an illusion of hardware
> isolation, putting him at risk.
>
> As you saw, I am thinking about buying the RYF
>> https://tehnoetic.com/tet-t400s <https://tehnoetic.com/tet-t400s> to be
>> able to run with the Qubes 4. The  T400s has but unfortunately 8GB RAM max
>> and so the X230 with 16GB seems very interesting.
>>
> The T400s is an hardware equivalent of the x200.
>
>>
>> So my question is if the X230 is really deprived of all ME-AMT, or any
>> non-free dirt?
>
> See here for the output of me_cleaner:
> https://github.com/osresearch/heads-wiki/blob/master/Clean-the-ME-firmware.md
> with this understanding
> https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F
>
> If this is the case, your offer seems really interesting with all
>> mentioned options available. I also use the RYF X200 for non-Qubes
>> activities, but it would be just excellent if I could have just one machine
>> for Qubes+non-Qubes too.
>>
> A lower end, AMD laptop, the G505s seems a good candidate for libre
> oriented QubesOS users. It's porting to Heads is on the way, even though I
> do not have that hardware myself.
> https://github.com/osresearch/heads/issues/453
>
> As some pointed out earlier, the EC is still a binary blob present in
> laptops (not currently freed), microcode updates are unfortunately still
> required for security.
>
> Laptop world needs to be shaken. Binary free laptops 

Re: [qubes-users] HCL - Purism Librem 13 v2

[Thierry Laurion]

ing for me as a service(I would think
> others would also want this service as well...). The problem is who?
> >>
> > I started Insurgo Technologies Libres/Open Technologies exactly for
> that! (> https://www.facebook.com/InsurgoTech/insights/?section=navPosts <
> https://www.facebook.com/InsurgoTech/insights/?section=navPosts>> )
> >
> > We actually reprogram A-Grade refurbished x230 with Heads firmware (>
> http://osresearch.net/ <http://osresearch.net/>> ), while neutralizing
> Intel ME (>
> https://github.com/osresearch/heads-wiki/blob/master/Clean-the-ME-firmware.md
> <
> https://github.com/osresearch/heads-wiki/blob/master/Clean-the-ME-firmware.md>>
> ) while being there.
> >
> > I collaborate with Heads and QubesOS developers for a while now..
> > QubesOS can even be preinstalled with user's desired customizations (>
> https://github.com/SkypLabs/my-qubes-os-formula/issues <
> https://github.com/SkypLabs/my-qubes-os-formula/issues>> ) or shipped
> with latest QubesOS ISO on external MicroSD support. Heads validates ISO
> integrity with distribution's signing keys prior to boot them (Tails,
> Fedora, QubesOS).
> >
> > Heads, deployed with a Nitrokey Pro v2/LibremKey or by using internal
> TPM, validates rom' integrity before booting from it. With the help of a
> NitroKey/LibremKey (> https://puri.sm/posts/introducing-the-librem-key/ <
> https://puri.sm/posts/introducing-the-librem-key/>> ), the boot
> configurations are signed with user's keys and verified and the firmware
> integrity is attested at each reboot through HOTP (led flashing or TPMTOTP
> on user's cell phone through Google Authenticator or compatible app.
> >
> > The user receives the Nitrokey/LibremKey and his computer in distinct
> shipping packages and reunites at first laptop boot to attest that the
> firmware of the computer has not been tampered with in transit. (>
> https://puri.sm/posts/introducing-the-librem-key/ <
> https://puri.sm/posts/introducing-the-librem-key/>> ).
> >
> > The user, upon bootup integrity attestation, proceeds to the ownership
> of his new laptop (TPM) and his LibremKey. The user is then invited to
> reencrypt his SSD encrypted content with it's own chosen passphrase(>
> https://github.com/osresearch/heads/issues/463 <
> https://github.com/osresearch/heads/issues/463>> ) and to choose a
> secondary disk unlock passphrase, which will unlock encrypted disk content
> only if the firmware has boot attested integrity.
> >
> > Notes:
> > The user will be able to ask > Insurgo>  interactive support in the near
> future. (> https://github.com/SkypLabs/my-qubes-os-formula/issues/6 <
> https://github.com/SkypLabs/my-qubes-os-formula/issues/6>> ).
> > Buying from>  Insurgo (ITL/IOT)>  funds directly my participation to
> those projects.
> > Bulk discount are available upon request. Insurgo plans to transit into
> a working/buying cooperative in the near future.
> >
> >
> > Prices are in Canadian Dollars (CDN)
> > x230>  i5 240GB SSD 16GB Webcam and IPS: $620
> > Hardware reprogramming fee: +250$
> > Backlit Keyboard: 40$  (optional)
> > Webcam 10$  (optional)
> > Nitrokey/LibremKey: + 80$
> > The refurbisher offers a warranty plan on the value of the purchase:
> > 1 Month %5
> > 3 Months %10
> > 6 Months %15
> > 1 Year %25
> >
> > Thierry Laurion:
> > GitHub: > https://github.com/tlaurion/ <https://github.com/tlaurion/>
> > LinkedIn: > https://www.linkedin.com/in/thierry-laurion-40b4128/ <
> https://www.linkedin.com/in/thierry-laurion-40b4128/>
> >
> > Insurgo, Technologies Libres / Open Technologies:
> > email: > insu...@riseup.net <mailto:insu...@riseup.net>>  for more
> information.
> > GPG key: >
> http://keys.gnupg.net/pks/lookup?op=get=0x79C78E6659DB658F <
> http://keys.gnupg.net/pks/lookup?op=get=0x79C78E6659DB658F>
> > Follow this guide or it's platform equivalent: >
> https://securityinabox.org/en/guide/thunderbird/mac/ <
> https://securityinabox.org/en/guide/thunderbird/mac/>
> > Website: > https://Insurgo.ca <https://Insurgo.ca>
> > Facebook: > https://www.facebook.com/InsurgoTech/ <
> https://www.facebook.com/InsurgoTech/>
> >
> > On Sun, Nov 11, 2018 at 9:26 PM <> 22...@tutamail.com  22...@tutamail.com>> > wrote:
> >
> >> Unman your posts have been extremely helpful to me and I can't thank
> you enough for the help(I am sure many others would agree).
> >>
> >>  However I think your "..Pretty easy to

Re: [qubes-users] HCL - Purism Librem 13 v2

[Thierry Laurion]

Hi!

> I checked out the x230 and you are right they are available and cheap. I
> would still be interested in finding some company/individual who I can
> trust to take care of the BIOS flashing for me as a service(I would think
> others would also want this service as well...). The problem is who?
>
I started Insurgo Technologies Libres/Open Technologies exactly for that! (
https://www.facebook.com/InsurgoTech/insights/?section=navPosts)

We actually reprogram A-Grade refurbished x230 with Heads firmware (
http://osresearch.net/), while neutralizing Intel ME (
https://github.com/osresearch/heads-wiki/blob/master/Clean-the-ME-firmware.md)
while being there.

I collaborate with Heads and QubesOS developers for a while now..
QubesOS can even be preinstalled with user's desired customizations (
https://github.com/SkypLabs/my-qubes-os-formula/issues) or shipped with
latest QubesOS ISO on external MicroSD support. Heads validates ISO
integrity with distribution's signing keys prior to boot them (Tails,
Fedora, QubesOS).

Heads, deployed with a Nitrokey Pro v2/LibremKey or by using internal TPM,
validates rom' integrity before booting from it. With the help of a
NitroKey/LibremKey (https://puri.sm/posts/introducing-the-librem-key/), the
boot configurations are signed with user's keys and verified and the
firmware integrity is attested at each reboot through HOTP (led flashing or
TPMTOTP on user's cell phone through Google Authenticator or compatible app.

The user receives the Nitrokey/LibremKey and his computer in distinct
shipping packages and reunites at first laptop boot to attest that the
firmware of the computer has not been tampered with in transit. (
https://puri.sm/posts/introducing-the-librem-key/).

The user, upon bootup integrity attestation, proceeds to the ownership of
his new laptop (TPM) and his LibremKey. The user is then invited to
reencrypt his SSD encrypted content with it's own chosen passphrase (
https://github.com/osresearch/heads/issues/463) and to choose a secondary
disk unlock passphrase, which will unlock encrypted disk content only if
the firmware has boot attested integrity.

Notes:

   - The user will be able to ask *Insurgo* interactive support in the near
   future. (https://github.com/SkypLabs/my-qubes-os-formula/issues/6).
- *Buying from Insurgo (ITL/IOT) funds directly my participation to those
   projects.*
   -
*Bulk discount are available upon request. Insurgo plans to transit into a
   working/buying cooperative in the near future. *



Prices are in Canadian Dollars (CDN)

   - x230 i5 240GB SSD 16GB Webcam and IPS: $620
   - Hardware reprogramming fee: +250$
  - Backlit Keyboard: 40$  (optional)
  - Webcam 10$  (optional)
   - Nitrokey/LibremKey: + 80$

The refurbisher offers a warranty plan on the value of the purchase:

   - 1 Month %5
   - 3 Months %10
   - 6 Months %15
   - 1 Year %25


Thierry Laurion:

   - GitHub: https://github.com/tlaurion/
   - LinkedIn: https://www.linkedin.com/in/thierry-laurion-40b4128/


Insurgo, Technologies Libres / Open Technologies:

   - email: insu...@riseup.net for more information.
  - GPG key:
  http://keys.gnupg.net/pks/lookup?op=get=0x79C78E6659DB658F
  - Follow this guide or it's platform equivalent:
  https://securityinabox.org/en/guide/thunderbird/mac/
  - Website: https://Insurgo.ca
   - Facebook: https://www.facebook.com/InsurgoTech/


On Sun, Nov 11, 2018 at 9:26 PM <22...@tutamail.com> wrote:

> Unman your posts have been extremely helpful to me and I can't thank you
> enough for the help(I am sure many others would agree).
>
> However I think your "..Pretty easy to maintain.." would be hell for me.
>
> Librem(and maybe the Majora line) have huge appeal for me as they take
> care of the BIOS flashing.
>
> I checked out the x230 and you are right they are available and cheap. I
> would still be interested in finding some company/individual who I can
> trust to take care of the BIOS flashing for me as a service(I would think
> others would also want this service as well...). The problem is who?
>
> Thanks...
>
> ("-boxy is the new black." Good one and couldn't agree more...very funny!)
>
> --
> 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 post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/26f75d86-0349-4533-8f3a-66fe2e37c1b3%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thierry Laurion

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this grou

Re: [qubes-users] Q4 Laptops...

[Thierry Laurion]

Le lun. 16 avr. 2018 05:47, awokd <aw...@danwin1210.me> a écrit :

> On Sun, April 15, 2018 12:52 pm, Thierry Laurion wrote:
>
> > Let's start a real debate aimed at improving stuff and building proper
> > arguments. Pressure against manufacturers will build with market laws,
> and
> > energy should be put where things can evolve in the meantime.
>
> I think everyone can agree to this!
>
> > G505s are not powerful and tough enough to run Qubes as a daily
> > driver.
>
> They don't have a titanium frame, but what laptops do these days? I did a
> full Stretch linux-image build in 2.5 hours on one, but that's the
> heaviest work I put it through. With 16GB RAM and a good SSD, they're fast
> enough for what I need.
>
What is your CPU speed? How much lasts the battery? How is the screen? Does
it feel bulky in a backpack?

>
> > ME is a really nasty piece of shit to deal with, agreed. But things needs
> >  to move forward. Hiding in a cave waiting for things to magically happen
> > is not enough.
>
> I think everyone can agree to this too. I posted some thoughts on ways
> forward over on qubes-devel a little while ago
> https://www.mail-archive.com/qubes-devel@googlegroups.com/msg03097.html
> and there were a couple related threads around the same time. Neither
> Intel or AMD seem concerned about actual security, only locking down the
> platform by handing over control of it to manufacturers instead of end
> users.
>
>
>

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAAzJznybiJUNTPDn%3Dg3fk_c8WO-B%2BH%3DP7FnHU85ircyPLF-dLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Q4 Laptops...

[Thierry Laurion]

To Taiidan and all others complaining about Purism lies and consumer being
misled.

I keep reading stuff about purism lying about deactivating/disabling ME
being impossible, lying about the future of Intel removing ME, etc. I think
THIS is misleading.

First, its me_cleaner job to do the cleaning.
The ME hack itself won't remove ME, but can remove modules by stripping
them. There is a big semantic difference between the words removing,
disabling and deactivating, I agree. Me_cleaner won't remove ME, that is
true. But all this ranting is not factual.

See here:
https://github.com/corna/me_cleaner/wiki/HAP-AltMeDisable-bit

From
https://github.com/corna/me_cleaner/blob/master/README.md:

"For pre-Skylake firmware (ME version < 11) this tool removes almost
everything, leaving only the two fundamental modules needed for the correct
boot, ROMP and BUP. The code size is reduced from 1.5 MB (non-AMT firmware)
or 5 MB (AMT firmware) to ~90 kB of compressed code.

Starting from Skylake (ME version >= 11) the ME subsystem and the firmware
structure have changed, requiring substantial changes in me_cleaner. The
fundamental modules required for the correct boot are now four (rbe,
kernel, syslib and bup) and the minimum code size is ~300 kB of compressed
code (from the 2 MB of the non-AMT firmware and the 7 MB of the AMT one)."

To have Intel without ME ( but also without vt-d2, meaning no IOMMU) one
will need to choose old hardware, like the x200, which will not have more
then 8gb ram and won't support hardware isolation, so no real advantage of
using Qubes.

x230 and x220 and others will boot with deactivated ME, booting with ROMP
and BUP present, true, but without kernel and no other modules.

The rest of what you say, I agree. But oversimplifying things doesn't
fulfill the goal of making people aware of what is needed now and in the
future. Maybe Intel will change their way of fusing keys into the CPU when
they realise a lot of money is going out of their pocket to privacy
defending manufacturers. Maybe not. Time only will let us know. Their
objective is good. They might now success against Goliath, but really
trying their best for actual possibilities. ( IOMMU, minimal ME footprint,
disabling ME the same way it is done for three letters agencies laptops).


Until brand new laptops can fulfill IOMMU needs for certain threat models,
there is few alternatives now.

Tl;dr:
Used laptops:
Having IOMMU without ME/PSP (Qubes): Lenovo g505s.
Removed ME, without IOMMU: x200.
Disabled ME with IOMMU (Qubes): x230/x220.

New laptops:
Deactivated ME, with IOMMU (Qubes): Purism Librems.

Desktop/Servers:
Used:
With IOMMU (Qubes), no ME/PSP: kgpe-d16, kcma-d8
New:
With IOMMU (no Qubes): Talos II.

Let's start a real debate aimed at improving stuff and building proper
arguments.
Pressure against manufacturers will build with market laws, and energy
should be put where things can evolve in the meantime.

For my part, I wouldn't recommend using a x200 other then for amnesic
laptops.
G505s are not powerful and tough enough to run Qubes as a daily driver.

ME is a really nasty piece of shit to deal with, agreed. But things needs
to move forward. Hiding in a cave waiting for things to magically happen is
not enough.

Thierry




Le mer. 11 avr. 2018 16:57, taii...@gmx.com  a écrit :

> On 04/11/2018 03:14 AM, Drew White wrote:
>
> > On Wednesday, 11 April 2018 16:55:48 UTC+10, tai...@gmx.com  wrote:
> >> What you ask for is impossible, it simply isn't made - no one has a
> >> laptop with 64GB RAM and 12 threads let alone one that is old enough to
> >> not have UEFI.
> > I know that they exist, and I would have one if I had enough money. But
> they do exist. As for UEFI (Microsofts shit invention) if I can disable it
> or else just replace it with an actual REAL BIOS, then I will.
> You can't do that unless the computer supports coreboot and the new
> stuff doesn't.
> >> The best you will get is a W520 or W530 where you can install coreboot
> >> (open hw init + nerfed ME) and have 32GB RAM.
> > Can the CPU be upgraded in those though?
> Yeah its socketed.
>
> I suggest buying a W520 and installing the best ivybridge CPU you can,
> then you get the better non-chiclet keyboard and it is also better
> supported in coreboot the port for the W530 was never upstreamed.
> >> Purism is not libre - their "open source firmware" has hardware
> >> initiation done entirely via binary blobs and their ME is certainly not
> >> disabled as the kernel still runs along with any hypothetical backdoor.
> >> Their marketing is incredibly dishonest and I simply don't understand
> >> why they get so much air time.
> > lol, then the only way I can get around it is to disable it myself by
> editing the CPU firmware? Or is there something else that controls that?
> (I'll have to look into it.)
> Disabling ME/PSP is impossible, it simply can't be done without
> intervention from intel/amd.
> The puridiots claim they will eventually be able to 

Re: [qubes-users] Q4 Laptops...

[Thierry Laurion]

"Their objective is good."
Talking about Purism here, not Intel :)

Le dim. 15 avr. 2018 08:52, Thierry Laurion <thierry.laur...@gmail.com> a
écrit :

> To Taiidan and all others complaining about Purism lies and consumer being
> misled.
>
> I keep reading stuff about purism lying about deactivating/disabling ME
> being impossible, lying about the future of Intel removing ME, etc. I think
> THIS is misleading.
>
> First, its me_cleaner job to do the cleaning.
> The ME hack itself won't remove ME, but can remove modules by stripping
> them. There is a big semantic difference between the words removing,
> disabling and deactivating, I agree. Me_cleaner won't remove ME, that is
> true. But all this ranting is not factual.
>
> See here:
> https://github.com/corna/me_cleaner/wiki/HAP-AltMeDisable-bit
>
> From
> https://github.com/corna/me_cleaner/blob/master/README.md:
>
> "For pre-Skylake firmware (ME version < 11) this tool removes almost
> everything, leaving only the two fundamental modules needed for the correct
> boot, ROMP and BUP. The code size is reduced from 1.5 MB (non-AMT firmware)
> or 5 MB (AMT firmware) to ~90 kB of compressed code.
>
> Starting from Skylake (ME version >= 11) the ME subsystem and the firmware
> structure have changed, requiring substantial changes in me_cleaner. The
> fundamental modules required for the correct boot are now four (rbe,
> kernel, syslib and bup) and the minimum code size is ~300 kB of compressed
> code (from the 2 MB of the non-AMT firmware and the 7 MB of the AMT one)."
>
> To have Intel without ME ( but also without vt-d2, meaning no IOMMU) one
> will need to choose old hardware, like the x200, which will not have more
> then 8gb ram and won't support hardware isolation, so no real advantage of
> using Qubes.
>
> x230 and x220 and others will boot with deactivated ME, booting with ROMP
> and BUP present, true, but without kernel and no other modules.
>
> The rest of what you say, I agree. But oversimplifying things doesn't
> fulfill the goal of making people aware of what is needed now and in the
> future. Maybe Intel will change their way of fusing keys into the CPU when
> they realise a lot of money is going out of their pocket to privacy
> defending manufacturers. Maybe not. Time only will let us know. Their
> objective is good. They might now success against Goliath, but really
> trying their best for actual possibilities. ( IOMMU, minimal ME footprint,
> disabling ME the same way it is done for three letters agencies laptops).
>
>
> Until brand new laptops can fulfill IOMMU needs for certain threat models,
> there is few alternatives now.
>
> Tl;dr:
> Used laptops:
> Having IOMMU without ME/PSP (Qubes): Lenovo g505s.
> Removed ME, without IOMMU: x200.
> Disabled ME with IOMMU (Qubes): x230/x220.
>
> New laptops:
> Deactivated ME, with IOMMU (Qubes): Purism Librems.
>
> Desktop/Servers:
> Used:
> With IOMMU (Qubes), no ME/PSP: kgpe-d16, kcma-d8
> New:
> With IOMMU (no Qubes): Talos II.
>
> Let's start a real debate aimed at improving stuff and building proper
> arguments.
> Pressure against manufacturers will build with market laws, and energy
> should be put where things can evolve in the meantime.
>
> For my part, I wouldn't recommend using a x200 other then for amnesic
> laptops.
> G505s are not powerful and tough enough to run Qubes as a daily driver.
>
> ME is a really nasty piece of shit to deal with, agreed. But things needs
> to move forward. Hiding in a cave waiting for things to magically happen is
> not enough.
>
> Thierry
>
>
>
>
> Le mer. 11 avr. 2018 16:57, taii...@gmx.com <taii...@gmx.com> a écrit :
>
>> On 04/11/2018 03:14 AM, Drew White wrote:
>>
>> > On Wednesday, 11 April 2018 16:55:48 UTC+10, tai...@gmx.com  wrote:
>> >> What you ask for is impossible, it simply isn't made - no one has a
>> >> laptop with 64GB RAM and 12 threads let alone one that is old enough to
>> >> not have UEFI.
>> > I know that they exist, and I would have one if I had enough money. But
>> they do exist. As for UEFI (Microsofts shit invention) if I can disable it
>> or else just replace it with an actual REAL BIOS, then I will.
>> You can't do that unless the computer supports coreboot and the new
>> stuff doesn't.
>> >> The best you will get is a W520 or W530 where you can install coreboot
>> >> (open hw init + nerfed ME) and have 32GB RAM.
>> > Can the CPU be upgraded in those though?
>> Yeah its socketed.
>>
>> I suggest buying a W520 and installing the best ivybridge CPU you can,
>> then you get the better non-chiclet keyb

Re: [qubes-users] Re: desktop recommendations?

[Thierry Laurion]

Le sam. 7 avr. 2018 08:26, <brendan.h...@gmail.com> a écrit :

> On Friday, April 6, 2018 at 9:27:11 PM UTC-4, Drew White wrote:
> > On Saturday, 7 April 2018 10:41:13 UTC+10, Thierry Laurion  wrote:
> > > You seem to have misunderstood. Ivy bridge and beyond on the Intel
> side will provide you with SLAT capabilities, IOMMU and virtualization,
> which is all that is required.  A x230 with 16gb ram and a i5 or i7 will
> provide you akk the power needed if you have an sad drive.
> >
> > I only went on what I was told. I have Ivy Bridge, and they don't have
> SLAT.
>
> Which CPU in particular? Did you look it up at the following link?
>   https://ark.intel.com/Search/FeatureFilter?productType=processors
>
> > At least, they don't SAY they do.
>
SLAT exist on Intel i3 i5 and i7 from their first generation (nehalem). Its
nothing new.

https://en.m.wikipedia.org/wiki/Second_Level_Address_Translation

Check Qubes HCL:
https://www.qubes-os.org/hcl/



> Which "they" are we talking about? If you mean Intel, they are on top of
> keeping the ark pages updated with this information.
>
> > Do they sometimes not say they have it even when they do?
>
> I doubt it. But CPU-reporting tools might misreport information due to a
> bug, or might report how the BIOS has configured the CPU rather than what
> the CPU is capable of.
>
> In addition to the CPU having to support certain features, many
> manufacturers don't enable the requisite virtualization features in the
> BIOS startup. Ignoring the closed-source firmware controversy (I don't want
> engage deeply on that, other than to say there are some complex ways of
> working around the BIOS issues with coreboot, etc. but there is no
> guarantee)...the BIOS issue is why I would recommend Thinkpad and Dell
> workstation-laptops from 2011 onward if the installed CPU has been verified
> in ARK* to have the supported features: VT-x with EPT or RVI *AND* VT-d or
> AMD-Vi aka IOMMU. These manufacturers went out of their way to do things
> correctly for their business-oriented machines, ensuring that all the
> higher-end CPU features could be utilized.
>
> E.g. why the "manufactured after 20xx" approach does not work...
>
> - I have a stack of purchased-used Thinkpad W520s here: manufactured in
> 2011 and 2012, they meet the prerequisites, as they have Sandy Bridge CPUs
> and proper support in BIOS.
>
> Sadly the embedded CPU in my GPX Pocket, manufactured in 2017, has an Atom
> x7-Z8750 (Cherry Trail family of power-efficient CPUs). While that CPU was
> released to market in 2016, and while it support VT-x, both EPT and VT-d
> are missing, so no QUBES 4.0 support. :(
>
> Last caveat: some Intel CPUs had broken support for these features in
> early steppings (manufacturer run tweaks), e.g. this one, which did not
> support EPT until the C2 stepping:
> https://ark.intel.com/products/63697/Intel-Core-i7-3930K-Processor-12M-Cache-up-to-3_80-GHz
>
> Brendan
>
> * AMD likely has a similar site to Intel's ARK site for use in gathering
> information on CPU features, but I haven't dug into that.
>
> --
> 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 post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/747a5aa5-0540-4e94-9184-52cb849c09a2%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [qubes-users] Re: desktop recommendations?

[Thierry Laurion]

Sorry for autocorrect.

Le ven. 6 avr. 2018 20:40, Thierry Laurion <thierry.laur...@gmail.com> a
écrit :

>
>
> Le ven. 6 avr. 2018 20:11, Drew White <drew.qu...@gmail.com> a écrit :
>
>> On Thursday, 5 April 2018 17:52:09 UTC+10, tai...@gmx.com  wrote:
>> > On 04/04/2018 10:59 PM, Drew White wrote:
>> >
>> > > I can't say anything about Qubes 4 because their restrictions on it
>> require the latest CPUs and all (apparently) with certain technology that
>> pre-2017 CPUs don't have. (Or so I read).
>> > 2017? what? where did you read that? (I have a good idea where...a
>> > certain company perhaps?)
>> >
>> > The first CPU with all the capabilities is circa 2011 with the last and
>> > best owner controlled x86_64 CPU's 2013. (AMD 43xx and 63xx)
>>
>> No, Qubes 4 I was told would require certain functionality in the CPU. I
>> even read it on the Qubes website. Part of the CPU vulnerability remedy for
>> RAM access and the page sharing vulnerabilities.
>>
>> Qubes 4 was supposed to not work on anything except CPUs that have that.
>>
>> And that was some technology only implemented in CPUs that came out in
>> late 2016 early 2017 and beyond.
>>
>> That is what I was told about Qubes 4, therefore it would not run on my
>> older CPUs. This is what the makers of Qubes informed me of.
>>
> You seem to have misunderstood. Ivy bridge and beyond on the Intel side
> will provide you with SLAT capabilities, IOMMU and virtualization, which is
> all that is required.  A x230 with 16gb ram and a i5 or i7 will provide you
> akk the power needed if you have an sad drive.
>
>>
>>
>>
>> --
>> 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 post to this group, send email to qubes-users@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/qubes-users/49c98dd9-0546-4efd-b8fa-5af0cbdc9fa2%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

Re: [qubes-users] Re: desktop recommendations?

[Thierry Laurion]

Le ven. 6 avr. 2018 20:11, Drew White  a écrit :

> On Thursday, 5 April 2018 17:52:09 UTC+10, tai...@gmx.com  wrote:
> > On 04/04/2018 10:59 PM, Drew White wrote:
> >
> > > I can't say anything about Qubes 4 because their restrictions on it
> require the latest CPUs and all (apparently) with certain technology that
> pre-2017 CPUs don't have. (Or so I read).
> > 2017? what? where did you read that? (I have a good idea where...a
> > certain company perhaps?)
> >
> > The first CPU with all the capabilities is circa 2011 with the last and
> > best owner controlled x86_64 CPU's 2013. (AMD 43xx and 63xx)
>
> No, Qubes 4 I was told would require certain functionality in the CPU. I
> even read it on the Qubes website. Part of the CPU vulnerability remedy for
> RAM access and the page sharing vulnerabilities.
>
> Qubes 4 was supposed to not work on anything except CPUs that have that.
>
> And that was some technology only implemented in CPUs that came out in
> late 2016 early 2017 and beyond.
>
> That is what I was told about Qubes 4, therefore it would not run on my
> older CPUs. This is what the makers of Qubes informed me of.
>
You seem to have misunderstood. Ivy bridge and beyond on the Intel side
will provide you with SLAT capabilities, IOMMU and virtualization, which is
all that is required.  A x230 with 16gb ram and a i5 or i7 will provide you
akk the power needed if you have an sad drive.

>
>
>
> --
> 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 post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/49c98dd9-0546-4efd-b8fa-5af0cbdc9fa2%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

[qubes-users] Using Qubes for forensic/Data extraction of a raw image that should stay RO

[Thierry Laurion]

Hello all,

I've been extracting raw disk data from a 1TB from ddrescue for the past week. 
The last pass is showing a lot of errors, which means that I will have to 
repair the data before extracting it elsewhere, and i'm lacking space.

What I want to do is use Qubes to use that disk as a Standalone template, and 
save the changes elsewhere for the created VM, limiting the sizes of COW for 
only the reperations that will occur.

How would I accomplish that? The extracted file disk image is on another disk, 
mounted in sys-usb. Would it be possible to boot that disk an a newly created 
AppVM using that disk image? How would I do that?

Thanks a bunch! Thierry

Note: also posted here: 
https://www.reddit.com/r/Qubes/comments/87jbfm/using_qubes_for_forensicdata_extraction_of_a_raw/

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/861436a7-b6ae-4af7-9a49-900f48b85aa5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] power9 and qubes os

[Thierry Laurion]

Le dimanche 25 juin 2017 08:09:04 UTC-4, tai...@gmx.com a écrit :
> On 06/24/2017 08:16 PM, Johnysecured88 wrote:
> 
> > Are you a developer?
> No.
> > Can we get input from a developer on this issue?
> You should email the community liaison, as it is definitely a question 
> worth asking.
> a...@qubes-os.org
> If you want a supported build done by them you would probably have to 
> provide the funds for a new/used recent POWER system.

Xen doesn't support Power9 for the moment.
Qubes still depends on Xen for compartmentalization.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4949fc86-fa89-4332-8dca-dfc6059cf1e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Bitmask installation problem

[Thierry Laurion]

Their gpg signing key is expired. Report to leap!

Le lun. 19 mars 2018 18:03, Unman  a écrit :

> On Mon, Mar 19, 2018 at 08:50:50AM -0400, Chris Laprise wrote:
> > On 03/19/2018 04:32 AM, niepowie...@gmail.com wrote:
> > > Hello,
> > >
> > > I'm trying make set up vpn with bitmask application.
> > >
> > > I tried install bitmask to debian template.
> > >
> > >   have done steps listed on bitmask site as below in termainal:
> > >
> > > sudo apt install leap-archive-keyring
> > > sudo sh -c 'echo "deb http://deb.leap.se/client release stretch" >
> /etc/apt/sources.list.d/bitmask.list'
> > > sudo apt update && sudo apt install bitmask
> > >
> > > But there is info as below
> > >
> > > Some packages could not be installed. This may mean that you have
> > > requested an impossible situation or if you are using the unstable
> > > distribution that some required packages have not yet been created
> > > or been moved out of Incoming.
> > > The following information may help to resolve the situation:
> > >
> > > The following packages have unmet dependencies:
> > >   bitmask : Depends: bitmask-core but it is not going to be installed
> > > Depends: bitmask-qt but it is not going to be installed
> > > Depends: bitmask-vpn but it is not going to be installed
> > > Depends: bitmask-mail but it is not going to be installed
> > > E: Unable to correct problems, you have held broken packages.
> > >
> > > How can I resolve this problem? Any advices?
> > >
> >
> > Hi,
> >
> > I'm getting an authentication error when I try to install 'bitmask' with
> > apt:
> >
> > > WARNING: The following packages cannot be authenticated!
> > >   python-leap-common python-sqlcipher soledad-common soledad-client
> bitmask-core bitmask-js
> > >   bitmask-qt bitmask-vpn bitmask-mail bitmask
> >
> >
> > You should probably report the problem to the leap-discuss list. Their
> > bitmask repository may currently be in a transitional state; I know they
> > were planning a new release with Qubes support I contributed.
> >
> > The current release of the standalone bundle can be downloaded here:
> > https://dl.bitmask.net/client/linux/
> >
> > Note the current release v0.10.2 doesn't have Qubes proxyVM support. This
> > means if you run it in a proxyVM some firewall protections won't be in
> > effect, but it should still work. The latest release candidate v0.10.3rc1
> > does have the Qubes proxyVM support.
> >
> > Another difference between the current release and the release candidate
> is
> > that the former has been signed and can be manually verified with gpg.
> >
>
> There does seem to be something amiss with the repo - I imported the
> signing key but still get a GPG error with invalid signature.
>
> --
> 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 post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/20180319220302.s7d2et6wedj337nz%40thirdeyesecurity.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAAzJznyFf5p8Wo-V3PgWa8uieq%3D-ma1Fy4-4u4Gwq%2BeARok%3DmA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: ANN: Qubes network server

[Thierry Laurion]

Le dimanche 6 novembre 2016 19:07:54 UTC-5, Manuel Amador (Rudd-O) a écrit :
> On 11/05/2016 03:54 PM, Max wrote:
> >
> > Thanks for the response!
> >
> > I ran this and also ran 'sudo dnf install go' when I came across the 
> > following error: 'go is needed by qubes-network-server-0.0.4-1.fc23.noarch'.
> 
> A commit is now out which eliminates this dependency.
> 
> > I then did the cd into the cloned folder and the 'make rpm' function has 
> > appeared to have worked.
> >
> > I followed the steps to get this to Dom0 and then installed the RPM. It may 
> > be better to add to the documentation 'sudo rpm -ivh qns.rpm' as I wasn't 
> > initially sure that I actually had to name the file. It helps the noobs! 
> >
> > The purpose for me for installing the network server was to be able to ping 
> > my Debian VM from my Windows VM.
> >
> > These are the configuration steps I took subsequent to install:
> >
> > 1) Created a ProxyVM named server-proxy.
> > 2) Changed the NetVM on both work-apps (my Debian 8 VM) and windows-7 (HVM) 
> > to the new ProxyVM
> 
> Sorry, I should have clarified that HVMs are not supported at all.  I am
> very, very sorry.  I need to do more work to get HVMs to work properly
> ("more" is an euphemism for I have totally forgotten so far to support
> that use case).  It is totally my fault that I did not explain this in
> the documentation.  My bad.  I have updated the documentation to reflect
> that.
> 
> If you could help me, do report what happens when you ping between a
> Fedora and a Debian AppVM, or two Debian AppVMs.
> 
> -- 
> Rudd-O
> http://rudd-o.com/

Considering Qubes 4.x has switched to HVM, what needs to be done to support 
this mode of operation? 
Opened a ticket to track this issue: 
https://github.com/Rudd-O/qubes-network-server/issues/4

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0f8fb811-1b22-4d71-b87d-497d7e1db0f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] HCL - ASUS KGPE-D16

[Thierry Laurion]

Any recommendations for tpm?

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2b14f0d3-5677-43da-9014-b5a22190220d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes on Lenovo Thinkpad X250 Issues

[Thierry Laurion]

Le mercredi 9 novembre 2016 07:43:28 UTC-5, Pablo Di Noto a écrit :
> > Bump. Its not Qubes specific. Same applies to latest Xen Hypervisor on 
> > Ubuntu 16.04.1.
> > 
> > Any idea what got introduced into Xen between 3.0 and 3.1?
> 
> I am using a X250 since last february (installed R3, updated to R3.1 and full 
> reinstall of R3.2).
> 
> No problems with booting so far.
> Let me know if you want to compare BIOS versions, config, etc.
> 
> Regards,
> ///Pablo

Yep I would like to, as I was able to use 3.1 with Legacy but can't boot 3.2.
Updated BIOS to 1.25, made sur vt-d and vt-x were activated.

It's an i7, if it changes anything. Attempting to add Xen hypervisor to Ubuntu 
results in the same behavior. Will attemtpt to find debugging arguments and 
setup AMT to have debug logs. 

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2a01b957-53b1-4bc3-857d-b13d7c38e190%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes on Lenovo Thinkpad X250 Issues

[Thierry Laurion]

Bump. Its not Qubes specific. Same applies to latest Xen Hypervisor on Ubuntu 
16.04.1.

Any idea what got introduced into Xen between 3.0 and 3.1?

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/86285865-2bb2-4b73-b3c9-4553b790f0e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.