date:20200101

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

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

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

 > needs collaboration to have real solutions in the future.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


-- 
Thierry Laurion

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAAzJznyUYV78UYTAT%2Bxru%3DZuwNJOqZH4y9d%3De04iUXoy%3DGyEVA%40mail.gmail.com.

Re: [qubes-users] HOWTO: Enable screen poweroff (instead of blanking)

On 12/23/19 5:23 PM, Defiant wrote:

On 22. 12. 19 15:45, Claudia wrote:

I just wanted to drop a note here before I forget. Out of the box, Qubes blanks
the screen after a few minutes, but never powers off the screen, even though
it's configured to do so in the XFCE Power Manager. I've had this problem on
several machines, all the way back to R3.2, and I always blamed it on lack of
hardware support.

Turns out, it's because Qubes comes with Xscreensaver enabled which overrides the XFCE Power Manager settings. Xscreensaver is
only configured to blank the screen; I'm not sure if it even supports powering it off. To return control to XFCE, go to Menu >
System Tools > Session and Startup > Application Autostart, and uncheck "Screensaver". Then you can logout,
reboot, or go to Menu > System Tools > Screensaver > File > Kill Daemon. You may have to also open Menu > System
Tools > Power Manager > Display, and switch "Display power management" to off and then on again.

Note this will disable the lockscreen. This is not recommended if you use a USB
keyboard or mouse and a USB Qube, or if someone has physical access to your
computer while it's on. Otherwise, I recommend enabling screen poweroff in
order to conserve energy and lengthen the lifespan of your screen's backlight.

I have also noticed this annoyance on several machines and different
linux distributions so it must be an Xfce problem, not a Qubes problem.

That is probably the case since this was one of the problems that got
solved when I switched to KDE.

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/9b2e5ba7-0f4c-8061-15e5-176870281ba2%40posteo.net.

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

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

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

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

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

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

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

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

Completely agreeing. This is why this 

needs collaboration to have real solutions in the future.

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

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

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

--

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

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9b6d6ae6-5252-21a4-2a52-d9dfa355b905%40posteo.net.

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



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?

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

Hello Thierry,

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

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

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

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

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

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

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

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

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

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

.

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

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

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

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

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

Sorry for reposting. Previous mail badly formatted.

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

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

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

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

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

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

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

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

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

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

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

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] Recommended laptop?

2020-01-01 Thread Claudia

December 31, 2019 1:02 PM, "eira wahlin"  wrote:

> I use qubes on an AMD system (thinkpad with Ryzen 5 pro 2500u). While I'm 
> happy with it, I've had
> to make some sacrifices. AMD systems are tricky with hardware forwarding, so 
> I cannot (at the
> moment) use a sys-USB. There is an inherent security problem there.
> 
> Also, I've had to make my own versions of the (horribly elitistic and 
> class-hatingly named) AEM
> system. I use my machine's TPM2 to verify that my BIOS hasn't been infected, 
> but that was difficult
> as hell to set up. AEM relies on Intel's TPM module, and doesn't work with 
> AMD machines.
> 
> So while most of it all works, it's been tricky to set up, and it's not all 
> functional yet.
> 
> <3
> /panina

Hi again, processor buddy. I have the Ryzen 5 (non-Pro) 2500U. I've also had a 
lot of problems with it. The IOMMU grouping is terrible, the kernel has a lot 
of problems with the firmware and ACPI, it doesn't support USB Qube, and so on. 
I haven't dared to even try AEM on this machine. But considering the 
performance for the money, I guess I really can't complain.

I recently got suspend/resume half working. Turns out, some or all of the 
Fam15h processors including the 2500U change their cpuid feature bits when 
resuming from suspend, which causes a Xen panic. This means the fans come back 
on, but the screen doesn't power back on and it can't save any logs, so it's 
really hard to diagnose. You can patch Xen to disable the feature check.

If you don't mind patching Xen, it's very likely that this will fix it for you 
(although you may run into other post-resume problems). And it's really not as 
difficult as it sounds.

This link contains a patch and instructions for building it.
https://www.mail-archive.com/qubes-users@googlegroups.com/msg31697.html

-- 
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/7cb86fb029b7e582b13e5cf32013d7c4%40disroot.org.

Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics

2020-01-01 Thread Claudia

December 30, 2019 6:44 PM, "qubes123"  wrote:

> Answering to your earlier question, my CPU capability information bits change 
> like this after
> suspend:
> 
> (XEN) Entering ACPI S3 state.
> (XEN) AMD-Vi: Applying erratum 746 workaround for IOMMU at :00:00.2
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) CPU0: cap[ 1] is 3e98320b (expected b698320b)
> (XEN) Missing previously available feature(s).
> (XEN) Enabling non-boot CPUs ...
> 
> Without the patch this result in xen panic.
> 
>> I decided to give this a try, but I don't really know how to use the build 
>> system. I did `make
>> vmm-xen`, modified the file
>> chroot-dom0-fc29/home/user/rpmbuild/BUILD/xen-4.12.1/xen/arch/x86/acpi/power.c,
>>  but it appears
>> after running `make vmm-xen` again my changes have been reverted. After it 
>> finishes the line is no
>> longer commented out. Do I have to commit the change, or generate a patch 
>> file, or something like
>> that?
> 
> After you configure the qubes builder (easiest done with ./setup) and 
> download all the sources
> (including the qubes-vmm-xen extra sources), you have to put the patch file 
> in the
> qubes-src/vmm-xen directory.
> 
> Then, include this patch in xen.spec.in file (somewhere below the last patch 
> line eg. as Patch
> 1202: xxx --> filename is relative to the vmm-xen directory).
> Then, change the release (rel file) number to avoid mixing the "official" and 
> your custom versions.
> Then run: make wmm-xen, and the new rpms will be available in the pkgs folder.
> You can check the logs meanwhile xen compiles if your patch was applied 
> sucessfuly or not.
> Then, install all the rpms (7), that are currently installed in dom0 (eg. the 
> devel and the debug
> files etc. are not needed.
> 
> PS: my patch looks like this (it will show the CPUID capability bits changing 
> in the hypervisor
> log)
> 
> diff -ruN a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
> --- a/xen/arch/x86/acpi/power.c 2019-12-15 18:26:11.18300 +0100
> +++ b/xen/arch/x86/acpi/power.c 2019-12-15 18:23:15.43900 +0100
> @@ -257,7 +257,7 @@
> microcode_resume_cpu(0);
> 
> if ( !recheck_cpu_features(0) )
> - panic("Missing previously available feature(s).");
> + printk(XENLOG_ERR "Missing previously available feature(s).\n");
> 
> /* Re-enabled default NMI/#MC use of MSR_SPEC_CTRL. */
> ci->spec_ctrl_flags |= (default_spec_ctrl_flags & SCF_ist_wrmsr);

Thanks for the patch and the instructions. The qubes-builder documentation is 
outdated and sorely
lacking (it doesn't even mention ./setup!). I applied the patch for marek's 4.1 
repo but I couldn't
get to produce an fc31 package. It kept building for fc29 which I don't 
currently have installed.
Then I built it for fc25 4.0 stable, but the patch wouldn't apply cleanly so I 
just modified the
existing patch-x86-check-feature-flags-after-resume.patch to print an error 
instead of panic, and
changed the message slightly.

patch-x86-check-feature-flags-after-resume.patch
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 3d26d4be31..e8fb3f6f31 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -255,6 +255,9 @@ static int enter_state(u32 state)

microcode_resume_cpu(0);

+ if ( !recheck_cpu_features(0) )
+ printk(XENLOG_ERR "Missing previously available feature(s). Ignoring.\n");
+
/* Re-enabled default NMI/#MC use of MSR_SPEC_CTRL. */
ci->spec_ctrl_flags |= (default_spec_ctrl_flags & SCF_ist_wrmsr);
spec_ctrl_exit_idle(ci);

Installed the seven packages already present in dom0. In case anyone is 
wondering those are:
xen-libs-4.8.5-14custom.fc25.x86_64.rpm
xen-4.8.5-14custom.fc25.x86_64.rpm
xen-hypervisor-4.8.5-14custom.fc25.x86_64.rpm
xen-runtime-4.8.5-14custom.fc25.x86_64.rpm
python3-xen-4.8.5-14custom.fc25.x86_64.rpm
xen-licenses-4.8.5-14custom.fc25.x86_64.rpm
xen-hvm-4.8.5-14custom.fc25.x86_64.rpm

Note that 4.8.5-14 -> 4.8.5-14custom shows up as a downgrade.

Ran `strings -a /boot/efi/EFI/qubes/xen.efi | grep Ignoring` to check for my 
unique message, just to be sure.

Rebooted. Checked xl info. Looks good. (Yes, it actually truncated the last 
character of the
version, apparently. Odd.)
xen_major : 4
xen_minor : 8
xen_extra : .5-14custom.fc2
xen_version : 4.8.5-14custom.fc2
cc_compile_date : Wed Jan 1 01:11:51 UTC 2020

Hit suspend from the XFCE menu. Waited 30 seconds or so. Crossed my fingers and 
resumed.

And... SUCCESS!

xl dmesg
(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) Entering ACPI S3 state.
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) CPU0: cap[ 1] is 7ed8320b (expected f6d8320b)
(XEN) Missing previously available feature(s). Ignoring.
(XEN) Enabling non-boot CPUs ...

Thank you for your help! It appears your machine is not a special case. Exact 
same result for both of us. Bit 27 flips on and bit 31 flips off (xor of 
0x8800). No idea what those mean, though. 

However, I still have a long road ahead of me. I did several

[qubes-users] Re: Installation fails in many different ways

Thanks for sharing, trueriver,

I finally got past the introductory boss of Qubes--now I get to roam the 
sandbox world. 

It wasn't so much an issue with the trackpad as it was the Nvidia GPU that 
can't be disabled.

Since you seem to be a dev who's interested in Qubes' compatibility with 
this particular 10th gen Dell, I can keep you posted (privately) about my 
experiences if you want.

-- 
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/abc949ac-e7bb-4ec6-9f90-fc5aa015c2f1%40googlegroups.com.

Re: [qubes-users] Installation fails in many different ways

awokd,

It was Nvidia--adding "nouveau.modeset=0" to BOOTX64.cfg did the trick.

Thank you!

-- 
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/955d5e5d-ee2b-4df6-aa80-8ad599b7c1f1%40googlegroups.com.

Re: [qubes-users] Installation fails in many different ways

It was Nvidia--adding "nouveau.modeset=0" did the trick. 

Thank you!

-- 
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/7b576d6b-fb4f-49bf-ad0a-0eb7c56e122c%40googlegroups.com.

[qubes-users] Re: Installation fails in many different ways