rally behind Purism Librem and push for Qubes support

[juwa...@gmail.com]

Hi all,

I have been trying to find compatible hardware which would be fully supported in Qubes, maybe even including TPM. A few weeks ago I more or less zeroed in on some Lenovo Thinkpad T540p variant, but I am still shying from the effort in getting it here (Germany), trying it out and then send it back if it does not work. I am sure, many of you are in the same boat.

So, last week I saw an article on arstechnica [1] about some particularly open source and "essential freedom (TM)" friendly, yet high end-ish laptop (the thing is call "Libre" from company "Purism" [2]) and thought, this would perfect for Qubes (compatibility, high-end, and all), however in its current configuration, the CPU does not support VT-x/VT-d.

I talked to them and explained to the best of my knowledge what is needed for Qubes and they showed interest. So far, so good, but I am even thinking, that it would be great to get someone like them (or system76, etc) to somehow commit to a tested/certified configuration for people like us, ideally even in an ongoing fashion, i.e. whenever they update the specs they should make sure, at least one base config/CPU +BIOS support is included, that meets Qubes' system requirements (even with TPM :)

It is currently a crowd funding campaign [3] and maybe not to late to influence the project. Todd Weaver is their project lead (cc').

IMHO, ideal config would also include TPM, and an option for 16GB RAM - everything else looks decent.

What do you think?
Best, Jürgen


[1] http://arstechnica.com/information-technology/2014/11/crowdfunding-project-promises-a-laptop-that-respects-essential-freedoms/
[2] http://puri.sm/products/
[3] https://www.crowdsupply.com/purism/librem-laptop

[7v5w7go9ub0o]

Makes sense!

ISTM Qubes will soon reach a tipping point of broad awareness, and
outfits like puri will suddenly *rush* to produce a "guaranteed Qubes
optimized" line of laptops - great advertising for them, and great
comfort for prospective Qubes convertees.

It also STM that "Qubes optimized" would include laptops that require
signed/certificated hardware and firmware - i.e. firmware security that
meets NIST requirements. Perhaps they could maintain firmware backups
and updates for the equipment they sell.

[Todd Weaver]

What I need is simple:
1) exact CPU models that support what is needed, that DOES NOT include
vPRO.
What I have received is this:
>> The i7- 4712hq and mq, the -4750, -4760, and -4770 all support vtd
and
>> vtx, with no vPro.
>> The 50, 60, and 70 also have the Intel Irispro graphics 5200, which
>> might a very cool upgrade to the 4600 HD graphics, and apparently the
>> dram for it is supported in linux kernel 3.12.

2) There is no #2 :)

I am already underway to see if any of the above will work within our
design.

I am not on the mailing list, so please cc me directly.

I suspect I will have an answer within a couple days on the above
chipsets. We WILL switch to one of the above, if we can make it work.
(once such issue is the graphics, we may throw out nVidia entirely,
which would need a campaign page update... so we are weighing all
options).

Todd.

[Joanna Rutkowska]

On 11/25/14 19:40, Todd Weaver wrote:
> What I need is simple: 1) exact CPU models that support what is
> needed, that DOES NOT include vPRO. What I have received is this:
>>> The i7- 4712hq and mq, the -4750, -4760, and -4770 all support
>>> vtd
> and
>>> vtx, with no vPro. The 50, 60, and 70 also have the Intel Irispro
>>> graphics 5200, which might a very cool upgrade to the 4600 HD
>>> graphics, and apparently the dram for it is supported in linux
>>> kernel 3.12.

And why is that you would like to avoid vPro so much? FWIW, vPro is an
umbrella name for many technologies: VT-x, VT-d, TXT, and also AMT. It
seems to me like you don't like AMT, is that correct? :)

BTW, speaking of nasty firmware, what BIOS do your laptops use? Is it
Coreboot perhaps?

>
> 2) There is no #2 :)
>
> I am already underway to see if any of the above will work within
> our design.
>

Helpful resources might be our HCL:

https://wiki.qubes-os.org/wiki/HCL

Generally it would be great to have OEM selling Qubes-compatible laptops
(as in: tested to work with specific Qubes release).

Thanks,
joanna.
ps. Please do not top-post :)

[Todd Weaver]

On Tue, 2014-11-25 at 10:40 -0800, Todd Weaver wrote:
> What I need is simple:
> 1) exact CPU models that support what is needed, that DOES NOT include
> vPRO.

We are using these filtering criteria... please correct if anybody has a
known issue:

http://ark.intel.com/Search/Advanced?s=t&MarketSegment=MBL&VTX=true&VTD=true

http://ark.intel.com/Search/Advanced?s=t&SocketsSupported=FCPGA946&MarketSegment=MBL&VTX=true&VTD=true

Todd Weaver
to...@puri.sm

[Todd Weaver]

On Tue, 2014-11-25 at 19:51 +0100, Joanna Rutkowska wrote:
> On 11/25/14 19:40, Todd Weaver wrote:
> And why is that you would like to avoid vPro so much? FWIW, vPro is an
> umbrella name for many technologies: VT-x, VT-d, TXT, and also AMT. It
> seems to me like you don't like AMT, is that correct? :)

Yes correct. AMT is what we want to avoid.

> BTW, speaking of nasty firmware, what BIOS do your laptops use? Is it
> Coreboot perhaps?

We plan (but have not yet finished) to ship coreboot.

> > 2) There is no #2 :)
> >
> > I am already underway to see if any of the above will work within
> > our design.
> >
> Helpful resources might be our HCL:
>
> https://wiki.qubes-os.org/wiki/HCL
>
> Generally it would be great to have OEM selling Qubes-compatible laptops
> (as in: tested to work with specific Qubes release).

We won't have the resources to test Qubes in our first run, but longer
term, if our campaign is successful, we could easily cooperate with
Qubes OS for certification.

Thanks for the link.

Todd Weaver
to...@puri.sm

[Joanna Rutkowska]

On 11/25/14 20:01, Todd Weaver wrote:
> On Tue, 2014-11-25 at 19:51 +0100, Joanna Rutkowska wrote:
>> On 11/25/14 19:40, Todd Weaver wrote:
>> And why is that you would like to avoid vPro so much? FWIW, vPro is an
>> umbrella name for many technologies: VT-x, VT-d, TXT, and also AMT. It
>> seems to me like you don't like AMT, is that correct? :)
>
> Yes correct. AMT is what we want to avoid.
>
>> BTW, speaking of nasty firmware, what BIOS do your laptops use? Is it
>> Coreboot perhaps?
>
> We plan (but have not yet finished) to ship coreboot.
>

I'm afraid this might not be so easy. Note that e.g. proper BIOS support
is needed for the OS to be able to correctly use VT-d. Do you work with
someone (e.g. Intel) on adapting Core boot for the specific chipsets you
use? Do you have access to the, otherwise NDA-ed, Intel's BIOS writer's
guide?

>>> 2) There is no #2 :)
>>>
>>> I am already underway to see if any of the above will work within
>>> our design.
>>>
>> Helpful resources might be our HCL:
>>
>> https://wiki.qubes-os.org/wiki/HCL
>>
>> Generally it would be great to have OEM selling Qubes-compatible laptops
>> (as in: tested to work with specific Qubes release).
>
> We won't have the resources to test Qubes in our first run, but longer
> term, if our campaign is successful, we could easily cooperate with
> Qubes OS for certification.
>
> Thanks for the link.
>
> Todd Weaver
> to...@puri.sm
>

That would be very cool!

A few more features that would make sense for Qubes:

1) Ensure keyboard is *not* (internally) a USB device (normally it is
not for most laptops). This is important to allow (sensible) use of USB
sandboxing in Qubes (UsbVM)

2) TPM and Intel TXT would allow for more Anti Evil Maid options.

3) As many USB controllers as possible (unlike USB ports/devices, USB
controllers are VT-d assignable to untrusted VMs, so this allows for
advanced risk-mitigating configurations)

4) Hardware switches for the mic and camera? (Actually this makes most
sense on non-Qubes systems, but even on Qubes might be useful :)

Regards,
joanna.

[Hakisho Nukama]

On Tue, Nov 25, 2014 at 8:43 PM, Joanna Rutkowska
<joa...@invisiblethingslab.com> wrote:
> On 11/25/14 20:01, Todd Weaver wrote:
>> On Tue, 2014-11-25 at 19:51 +0100, Joanna Rutkowska wrote:
>>> On 11/25/14 19:40, Todd Weaver wrote:
>>> And why is that you would like to avoid vPro so much? FWIW, vPro is an
>>> umbrella name for many technologies: VT-x, VT-d, TXT, and also AMT. It
>>> seems to me like you don't like AMT, is that correct? :)
>>
>> Yes correct. AMT is what we want to avoid.
>>

Hey again Todd.

A nice user on #coreboot has mentioned http://me.bios.io to me.
"Our goal is to implement a completely libre software replacement for
ME. When the implementation of such a security-critical component is
available for scrutiny, it will be peer-reviewed and audited by
persons around the world. This generally results in stronger security.
Our goal is not to replace Intel's ME, but to provide a libre
alternative for users who chose to use it."

May you work with them to get rid of that nasty stuff? :)

Or use these with no vPro and unfortunately missing TXT,
http://ark.intel.com/Search/Advanced?s=t&MarketSegment=MBL&VTX=true&VTD=true&VProTechnology=false
or these with TXT.
http://ark.intel.com/Search/Advanced?s=t&MarketSegment=MBL&VTX=true&VTD=true&VProTechnology=false&TXT=true

>>> BTW, speaking of nasty firmware, what BIOS do your laptops use? Is it

>>> coreboot perhaps?

>>
>> We plan (but have not yet finished) to ship coreboot.
>>
>
> I'm afraid this might not be so easy. Note that e.g. proper BIOS support
> is needed for the OS to be able to correctly use VT-d. Do you work with

> someone (e.g. Intel) on adapting coreboot for the specific chipsets you

> use? Do you have access to the, otherwise NDA-ed, Intel's BIOS writer's
> guide?
>

There are contradictory reports about IOMMU (VT-d) on the Pixel [1]
which uses coreboot.

I welcome your statement to utilize coreboot in your planned model.
Hopefully with IOMMU support. :)

>>>> 2) There is no #2 :)
>>>>
>>>> I am already underway to see if any of the above will work within
>>>> our design.
>>>>
>>> Helpful resources might be our HCL:
>>>
>>> https://wiki.qubes-os.org/wiki/HCL
>>>
>>> Generally it would be great to have OEM selling Qubes-compatible laptops
>>> (as in: tested to work with specific Qubes release).
>>
>> We won't have the resources to test Qubes in our first run, but longer
>> term, if our campaign is successful, we could easily cooperate with
>> Qubes OS for certification.
>>

If you're able to spare a prototype for some time, I could test it.

Should we also include models into the HCL that are planned,
or with no hands-on experience (from data sheets)?

>> Thanks for the link.
>>
>> Todd Weaver
>> to...@puri.sm
>>
> That would be very cool!
>
> A few more features that would make sense for Qubes:
>
> 1) Ensure keyboard is *not* (internally) a USB device (normally it is
> not for most laptops). This is important to allow (sensible) use of USB
> sandboxing in Qubes (UsbVM)
>

Shielded cables for keyboard. EM [2] vulnerability assessment.

> 2) TPM and Intel TXT would allow for more Anti Evil Maid options.
>
> 3) As many USB controllers as possible (unlike USB ports/devices, USB
> controllers are VT-d assignable to untrusted VMs, so this allows for
> advanced risk-mitigating configurations)
>

And documenting which USB controller is responsible
for which port (not ports ;)).

> 4) Hardware switches for the mic and camera? (Actually this makes most
> sense on non-Qubes systems, but even on Qubes might be useful :)
>

A rotatable camera like in some Getac models would be useful.
rotated to front (recording lectures)
rotated to user (normal web cam mode)
rotated inwards (off-state, or when not physically off only ambient light)


> Regards,
> joanna.
>

Best Regards.
Hakisho Nukama

[1] https://plus.google.com/100479847213284361344/posts/QhmBpn5GNE9
[2] https://www.cs.jhu.edu/~astubble/600.412/s-c-papers/em.pdf

[cprise]

If not switches, then status LEDs that are directly wired (not
addressable by software) to the devices' power should also be an
improvement in privacy. All status lights should be visible when laptop
is closed. And if anything should have a hardwired on/off switch, I
think it should be system power; The issue I'm thinking of here is the
recent prevalence of integrated batteries for laptops and handhelds
(they creep me out because they cannot be decisively turned off).


> Regards,
> joanna.
>

[Pedro Martins]

"Purism is devoted, at its heart and soul, to providing the highest
quality hardware available, that utilizes free/libre software, ensuring
the rights of freedom, privacy, and control of your computing. "

So, what about firmware in HDDs/SSDs?

--
Pedro Martins

[juwa...@gmail.com]

Glad so many of you chimed in, thanks!!

If I understood correctly, here is where we are at right now:
a) some great ideas on a _perfect_ configuration (thanks to Joanna, 7v5w7go9ub0o, Hakisho Nukama, cprise)
- coreboot (or another OSS BIOS) is desirable
- USB sandboxing in Qubes (UsbVM) wants keyboards *not* to be a USB device!
- (does the same go for any input/pointing device?)
- HW switch for system power
- microphone & camera - HW switches, or at least a hardwired status indicator LED
- also/better: camera that can be rotated: front-facing, rear-facing, and down(=off) facing (nice idea!!)
- Electromagnetic (EM) side-channel attack resistant cables, esp keyboard (and screen/video?)
- signed/certificated hardware (is such a thing even possible?
how can it be verified that it has not been tampered with?)
- firmware - i.e. firmware security that meets NIST requirements (anyone has more info on this?)
- OSS firmware for mass storage

b) minimum specs for Qubes (as per https://wiki.qubes-os.org/wiki/HCL)
- HVM ("AMD virtualization (AMD-V)", "Intel virtualization (VT-x)", "VIA virtualization (VIA VT)")
- IOMMU ("AMD I/O Virtualization Technology (AMD-Vi)", "Intel Virtualization Technology for Directed I/O (VT-d)")
- TPM ("Trusted Platform Module (TPM)" connected to a "20-pin TPM header" on motherboards.)
- is TPM really as crucial as the other two? if so, shouldn't TXT be in this list, too?
- gotchas: while a particular CPU might support HVM and IOMMU-
both the chipset *and* the BIOS need to properly support it, too!

c) clarifications
- vPro per se is not bad b/c it is just an umbrella term for technology including:
VT-x, VT-d, TXT, and also Intel Active Management Technology (AMT) - with AMT
being that bad one here, because it is a (closed spec/source) remote admin interface.
More: https://en.wikipedia.org/wiki/Intel_Active_Management_Technology
- there is also a neat video about disk and memory (using zram) encryption w/ Qubes (> 12mo old tho)
"Defcon 21 - A Password is Not Enough: Why Disk Encryption is Broken and How We Might Fix It"
https://www.youtube.com/watch?v=pKeiKYA03eE

did I forget anything so far?

@Joanna- how about adding some of this (particularly from "a)") to the Wiki, e.g. "Road to certified Qubes HW" or something. Want help with that -> just let me know, I am happy to type it up in markdown, etc.

[juwa...@gmail.com]

Also, I am a bit worried not to overwhelm Todd and the team @Purism with the "perfect spec". From what I get so far is that if they can change or add a configuration with a supported CPU (HVM, IOMMU), and maybe a few of the others (non-USB keyboard, hw switches for mic/cam -or maybe an option leaving those two out altogether), would that be a reasonable first step?


> The BIOS on the Librem 15 laptop currently uses an Intel binary blob, called FSP. We are working with Intel to release under a free license, or allow Purism to release under a free license and maintain the source.
> http://puri.sm/posts/bios-freedom-status/

Those should not be a long-term road block (hoping of course, it pans out that way), since it should be possible to update the BIOS/firmware at a later point?

Any other obstacles/issues you can think of?

> If you're able to spare a prototype for some time, I could test it.

Thanks @Hakisho Nukama for the offer- I would love to see this, once it is a ready.

Thanks, Jürgen

[Pedro Martins]

Well, since you asked nicely ;), below I attach a copy of something I
mentioned a few months ago (with cprise feedback), concerning this subject:

On 08/02/14 13:39, Pedro Martins wrote:
>
> This got me thinking what hardware support would be nice to have,
> which allows one to put security before convenience.
>
> Some wishful thinking follows.
>
>
> ** Minor hardware changes to improve security **
>
>
> 1) some way to lock laptop lid when closed:
>
> even those luggage combination locks might be better than nothing.
>

Maybe like "Kensignton lock, Level-2"... it would at least make some
scenarios messy for the attacker.

Since laptop makers (even Lenovo) have banished the lid latch, it would
be pretty funny to see them do a U-turn and then some.

>
> 2) hardware switches to power on and off ports/devices:
>
> real ones, not software driven - when it's off it remains off until I
> flip it on; for ethernet, wireless stuff, camera, mic, display, usb
> controllers/ports, memory cards, keyboard, internal stuff like sata
> ports (dangerous), etc;
>
> even if vm exploited, without power, no game: would no longer need
> to tape over my camera and mic; could boot computer with as little
> devices powered as possible, enable only as needed; as bonus, could
> disable all ports not needed to save power; added bonus, would end up
> with as many switches as pdp 11 ;-P

Yeah, but the most important IMHO is the battery. Never trust a machine
from which you cannot quickly yank the power source. BTW, how does an
"Airplane mode" switch on a typical business laptop rate? I assumed the
wireless switch on my Lenovo was hardware, but maybe that's wishful
thinking.

>
> 3) an usb controller for each usb port:
>
> would allow to reserve ports according to domain trust level.
> Snooping can still happen but now only within the same domain trust
> level. usbvm used to park usb controllers. Unfortunately it doesn't
> prevent me from inserting untrusted device in trusted port/domain -
> mistakes happen.
>

My T430s appears to have that: One controller per port.

>
> 4) an high-quality random number generator:
>
> as previously discussed on the list; can be bought today as usb
> device; to be used in addition to cpu existing one, if any.
>
>
> ** Not so minor hardware changes to improve security **
>

Well, if you're not willing to trust Intel/AMD's integrated HWRNG, then who?

>
> 5) proper support for TPM, TXT, VT-x, VT-d and upcoming SGX [3][4]:
>
> something is always missing because cost outranks security every
> time. also assuming owner will be in total control.
>

Industry imperatives appear to rank as high as cost, it seems. I recall
one of Joanna's blog posts describing how a feature (can't remember
which) did not live up to its potential to protect the user because it
was primarily intended to address Hollywood's interests.

>
> 6) some sort of usb virtualization support by the usb controller:
>
> each usb device inserted would have own isolated environment,
> virtual port assigned; usbvm could work as a sort of firewallvm/netvm
> to assign virtual usb ports to domains. Unfortunately it still
> doesn't prevent me from assigning untrusted device to trusted domain
> - mistakes happen.
>
> nice to have for usb ports, additional hardware switch to enable or
> disable data pins, allowing safe charge of usb devices - aka 'usb
> condom'.
>

Assuming some Qubes-of-the-future or spiritual successor to Qubes,
perhaps a USB *VIS*ualization to go along with the isolation
capabilities provided by some future hardware platform.

>
> 7) only minimal firmware needed to configure & boot the system and
> no firmware stored on devices/controllers for network, display,
> storage, usb, etc:
>
> coreboot [5] all the way. all drivers from source; unconstrained and
> freely available hardware interfacing specs; this will probably never
> happen, unless hardware OEMs totally committed to support open
> source/free software friendly components in their designs.
>

Don't give up hope. Open source hardware appears to be advancing, even
WRT security features:
http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

>
> 8) the ability to power on or off cpu/chipset "features", like vPro
> &co; ditto for gpu:
>
> yeah, as if ever! BIOS support only for enabling or disabling some
> of these features, but not all that can be supported by given
> cpu/chipset; something disabled might still be used/usable.
>

I don't think we can live without GPUs on the desktop at this point.
They are not inherently insecure, although current implementations may
be particularly lacking in that area.

>
> 9) virtualization support by/for the gpu(s):
>
> with so many cores available nowadays, makes sense and would allow
> better utilization of resources. even something crude like reserving
> some coarse groups of cores as virtual gpus would be nice to have.
>

GPU virtualization is becoming a reality, even with current hardware.
Intel has a driver that can virtualize a Haswell integrated GPU, for
instance.

>
> 10) generic hardware support for software defined radio [6]:
>
> not ever! legal nightmare expected; licensing & testing requirements
> for each and every country/state regulations.
>
>
> So, that's it. 1) to 5) are not that big deal IMO, could be made
> available on some brand 'professional' line of computers.
>
> Or, we could follow Canonical example and crowd-fund our own
> computer for $32 million [7] ;-) Nice 15" 4K non-glare screen,
> thinkpad-like keyboard, 512 Gib SSD, etc; fully supported by QubesOS
> R3!
>

11) Hardwired status lights for things like microphones and cameras.
This should be even on smartphones.

12) Peripherals that can be given individualized keys by the user, to
authenticate them with the CPU, so that any attempt at replacement would
be noticed and/or rejected. It doesn't matter what type of peripheral:
SATA, USB, SD card, etc. I think this could contribute toward a solution
to #BadUSB.


--
Pedro Martins

[Pedro Martins]

On 26-11-2014 14:02, juwa...@gmail.com wrote:

May I add:

- support for 16GB RAM (or 32GB with 4 slots, give some room to grow),
preferably ECC;

Also, if you have TPM you need TXT support (in CPU and chipset and BIOS).

Concerning UEFI, it hasn't been mentioned and I'm not up to date on
latest developments since I never had hardware with it, does anyone know
if it is already possible to use signed kernels (by ITL) without major
hurdles? Maybe coreboot is capable of handling that nicely?

Thanks for bringing this up on the list. Much appreciated :)

>
> @Joanna- how about adding some of this (particularly from "a)") to the Wiki, e.g. "Road to certified Qubes HW" or something. Want help with that -> just let me know, I am happy to type it up in markdown, etc.
>

--
Pedro Martins

[Todd Weaver]

On Tue, 2014-11-25 at 20:46 -0500, cprise wrote:
> > 4) Hardware switches for the mic and camera? (Actually this makes most
> > sense on non-Qubes systems, but even on Qubes might be useful :)
> If not switches, then status LEDs that are directly wired (not
> addressable by software) to the devices' power should also be an
> improvement in privacy. All status lights should be visible when laptop
> is closed. And if anything should have a hardwired on/off switch, I
> think it should be system power; The issue I'm thinking of here is the
> recent prevalence of integrated batteries for laptops and handhelds
> (they creep me out because they cannot be decisively turned off).

While there is a lot to reply to on this thread, this one is quick... We
do have LED light for the camera, hardwired. But what we've been toying
with is having a keystroke to cut power to the camera (similar to
wireless), I'll add to our list to consider microphone, for the same
obvious reason.

Todd.

[7v5w7go9ub0o]

On 11/26/14 09:02, juwa...@gmail.com wrote:
> Glad so many of you chimed in, thanks!!
>
> If I understood correctly, here is where we are at right now:
> a) some great ideas on a _perfect_ configuration (thanks to Joanna, 7v5w7go9ub0o, Hakisho Nukama, cprise)
> - coreboot (or another OSS BIOS) is desirable
> - USB sandboxing in Qubes (UsbVM) wants keyboards *not* to be a USB device!
> - (does the same go for any input/pointing device?)
> - HW switch for system power
> - microphone & camera - HW switches, or at least a hardwired status indicator LED
> - also/better: camera that can be rotated: front-facing, rear-facing, and down(=off) facing (nice idea!!)
> - Electromagnetic (EM) side-channel attack resistant cables, esp keyboard (and screen/video?)
> - signed/certificated hardware (is such a thing even possible?
> how can it be verified that it has not been tampered with?)

Was thinking of signed/certificated firmware (see below), and more of an
inventory of hardware which would be checked during boot (perhaps a TPM
function). Of particular interest would be hardware changes and additions.

> - firmware - i.e. firmware security that meets NIST requirements (anyone has more info on this?)

Please ref the 3.1 section of this document
<http://csrc.nist.gov/publications/nistpubs/800-147/NIST-SP800-147-April2011.pdf>

e.g. IIUC Lenovo t440p bios internally validates upgrades.

Thanks for pursuing this!

[Joanna Rutkowska]

Cameras are easy to cover with a piece of tape (and EFF even recently
released a branded piece of tape for covering cameras, which I'm sure
people will be mad to get ;) The mic is much more tricky to disable
safely. Also, the led is of little use for the mic, as it might got
enabled some time when people just don't happen to be paying attention.
H/w switch for mic definitely seems like a good idea.

joanna.

[syd2...@gmail.com]

People like the NSA can access devices on the motherboard whether they are powered on or not, or even if modules are removed. It seems that if the motherboard has a particular device capability featured on it, it can be accessed. (Unless a manufacturer can guarantee that their h/w switches really do work.) So the most secure design would be to have as much of a barebones-type motherboard as possible. And any peripherals - like cam, mic/audio, bluetooth, wifi, ethernet, etc., - could be USB add-on devices - or you could have a dock attachment with USB ports, ethernet ports, etc.. This would be especially good for Qubes because of the isolation of the USB controllers. So the actual computer+motherboard itself would be as much of a hardware/device-isolated design as possible. But then that would mean a compromise on convenience.

[Todd Weaver]

On Wed, 2014-11-26 at 13:31 +0000, Pedro Martins wrote:
> "Purism is devoted, at its heart and soul, to providing the highest
> quality hardware available, that utilizes free/libre software, ensuring
> the rights of freedom, privacy, and control of your computing. "
>
> So, what about firmware in HDDs/SSDs?

That, and all component hardware microcontrollers, must be freed. We
will get there, but first have to free the BIOS binaries.

The main goal of forming Purism is to push the free movement up the
supply chain. Right now the common business negotiation practice is
proprietary is fine by default. We are here to change that, and to
negotiate, source, and buy hardware that includes freed source for all
component parts.

There are many people working to free hardware, a lot from reverse
engineering, a small talented subset who are designing boards with free
source (which are growing in quality). But there is very few, if any,
who are leveraging their purchasing power upstream to their full
capacity. We plan on being such a company, if there is enough interest
in backing us, we will be.

Thanks for writing!

Todd Weaver
to...@puri.sm

[Todd Weaver]

On Wed, 2014-11-26 at 06:02 -0800, juwa...@gmail.com wrote:
> a) some great ideas on a _perfect_ configuration (thanks to Joanna, 7v5w7go9ub0o, Hakisho Nukama, cprise)
> - coreboot (or another OSS BIOS) is desirable

This is a top priority for us. Specifically the Intel binary needed
inside coreboot.

> - USB sandboxing in Qubes (UsbVM) wants keyboards *not* to be a USB device!

I believe, from our design specifications, that the keyboard controller
circuitry is wired to the motherboard, which is NOT usb. However, I do
not know how I would verify that via GNU/Linux. Does anybody know the
command to prove via kernel, or OS, how the keyboard is interfaced?

> - microphone & camera - HW switches, or at least a hardwired status indicator LED

We have hardwired status indicator next to the camera, but not
microphone. I am evaluating either a keystroke to cut power (like
wireless), or a hardware switch.

> - OSS firmware for mass storage

This is a longer term goal, plus all component hardware
microcontrollers.

Todd.

[Andrew]

`dmesg | grep "input:"` should do the trick. You should see some line like:
[time] input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input0

Andrew

[Todd Weaver]

On Wed, 2014-11-26 at 00:10 +0000, Hakisho Nukama wrote:
> A nice user on #coreboot has mentioned http://me.bios.io to me.
> "Our goal is to implement a completely libre software replacement for
> ME. When the implementation of such a security-critical component is
> available for scrutiny, it will be peer-reviewed and audited by
> persons around the world. This generally results in stronger security.
> Our goal is not to replace Intel's ME, but to provide a libre
> alternative for users who chose to use it."
>
> May you work with them to get rid of that nasty stuff? :)

Yes, we have been introduced, and will see how we can help!

Todd.

[syd2...@gmail.com]

If you want to do a real world test on a prototype with a wifi h/w switch, I could do that for you. Because I am constantly attacked by network hackers (so I may as well put them to good use). If my work gets hacked from your prototype with the h/w switch off - like my other computers have been - it would mean that your h/w switch is ineffective. If I don't get hacked you could say that it has passed real-world testing. 

[Todd Weaver]

We can take further conversations off the thread...

Reply with where you are located, we may take you up on that offer. Even
though it is a pretty easy test to see if power gets to the chip when
the keystroke is given.

Our initial research suggests we could do a keystroke power cut off for
camera and possibly microphone easier than a case mod to support a
switch. But we are still gathering the details.

[7v5w7go9ub0o]

On 11/29/14 12:59, Todd Weaver wrote:
> Reply with where you are located, we may take you up on that offer.
> Even though it is a pretty easy test to see if power gets to the chip
> when the keystroke is given. Our initial research suggests we could do
> a keystroke power cut off for camera and possibly microphone easier
> than a case mod to support a switch. But we are still gathering the
> details.

...... *NO* .........a H/W switch is *GREATLY* preferred - understanding
it's a PITA for you and $ for the buyer:

1. More reassuring!
2. Quickly verifiable
3. Sexy.
4. Set your product apart as a "security box"

Perhaps there are additional, security-related items that should be H/W
switched, allowing you to attach a "strip" of switches?

[Alex Dubois]

> On 29 Nov 2014, at 21:00, 7v5w7go9ub0o <7v5w7g...@gmail.com> wrote:
>
>
>> On 11/29/14 12:59, Todd Weaver wrote:
>> Reply with where you are located, we may take you up on that offer.
>> Even though it is a pretty easy test to see if power gets to the chip
>> when the keystroke is given. Our initial research suggests we could do
>> a keystroke power cut off for camera and possibly microphone easier
>> than a case mod to support a switch. But we are still gathering the
>> details.
>
> ...... *NO* .........a H/W switch is *GREATLY* preferred - understanding
> it's a PITA for you and $ for the buyer:
>
> 1. More reassuring!

I agree, hardware as the alternative is software, and we can do without having to trust/review/re flash the keyboard firmware

> 2. Quickly verifiable
> 3. Sexy.
> 4. Set your product apart as a "security box"
>
> Perhaps there are additional, security-related items that should be H/W
> switched, allowing you to attach a "strip" of switches?
>

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

[Joanna Rutkowska]

While this is a noble goal and I strongly support it, I would like to
point out just two potential misconceptions:

1) Free software != secure software. I.e. freedom doesn't guarantee
there are no bugs there. Admittedly makes them easier to find by others.

2) As far as firmware is considered it is difficult for others to
independently verify the firmware is indeed... free.

Consider this: how do you know what firmware does the device X runs?
Well, typically there would be some interface (e.g. to read SPI
flash/EEPROM content) exposed by... the device firmware. So, it might be
easy to imagine a malicious firmware pretending to be open, and feeding
some fake image to whoever requests reads of it. It's more tricky to
correctly handle the new firmware upload, as the user might
intentionally build subtle "backdoors" into the new firmware, upload it,
and then test behaviorally for them. But even that can be bypassed e.g.
by running the user-uploaded firmware in a VM (not necessarily h/w
based, might be binary translation). I wonder when the industry become
ready for the next gen Blue Pill for BIOS ;)

Nevertheless, please continue with what you're doing, Todd.
joanna.

[Pedro Martins]

Todd:

Hard disk hacking
http://spritesmods.com/?art=hddhack

Free Linux Driver Development!
http://www.kroah.com/log/linux/free_drivers.html

If you can manage to have some hw OEMS' to commit to supply you
(no-strings-attached preferably) tech specs for their hardware,
free/open drivers/firmware can be developed to support it.

But I understand that is easier to say than do...


Also, have you considered providing your hardware with SteamOS?

At first it seems to be contrary to your goals, but if you can manage to
provide an open/free hw platform & associated sw to drive it, and add on
top of it add some closed stuff (games!), those of us wishing for better
security/privacy protection can then customise it to our liking (like
having GamingVM within Qubes! R3 should be able to support this IIRC).

By having SteamOS/gaming laptop you can increase you target audience, no?

But I'm hinting you this for selfish reasons; this way you would have to
provide also a nice gaming keyboard (no numeric keypad please!).

Thanks for all your efforts to make this happen.

--
Pedro Martins

[Todd Weaver]

On Tue, 2014-12-02 at 12:00 +0100, Joanna Rutkowska wrote:
> While this is a noble goal and I strongly support it, I would like to
> point out just two potential misconceptions:
>
> 1) Free software != secure software. I.e. freedom doesn't guarantee
> there are no bugs there. Admittedly makes them easier to find by others.

Yes, I am well aware of this. However, I am in the camp that free
software, where it can be scrutinized publicly is stronger in the long
run than proprietary software ever could be. Primarily because free
software bugs or security holes are often found by reverse engineering
(the same way for proprietary software), not by seeing a weakness in the
source code base. Heartbleed, the most recent large scale vulnerability,
was found by attack testing as an example, not by pouring through the
source code looking for a vulnerability.

Your point is still valid that free software != secure software. But
free software does (in my opinion) create a way to develop (the most)
secure software.

> 2) As far as firmware is considered it is difficult for others to
> independently verify the firmware is indeed... free.

True, but even with this downside, it is far better than having mystery
code running on it.

> Consider this: how do you know what firmware does the device X runs?
> Well, typically there would be some interface (e.g. to read SPI
> flash/EEPROM content) exposed by... the device firmware. So, it might be
> easy to imagine a malicious firmware pretending to be open, and feeding
> some fake image to whoever requests reads of it. It's more tricky to
> correctly handle the new firmware upload, as the user might
> intentionally build subtle "backdoors" into the new firmware, upload it,
> and then test behaviorally for them. But even that can be bypassed e.g.
> by running the user-uploaded firmware in a VM (not necessarily h/w
> based, might be binary translation). I wonder when the industry become
> ready for the next gen Blue Pill for BIOS ;)

This is likely above my understanding, since it enters into signing and
cryptography, but I imagine having the firmware freed, and the source to
compile, it would be trivial to create some signing and trusting service
to operate within the kernel. This is not our goal. Our goal is to free
the source, it is the free software world who can determine how to
secure it best :)

> Nevertheless, please continue with what you're doing, Todd.

Thanks, we do have big plans, but first have to focus on closing our
initial motherboard manufacturing funding for the Librem 15.

Thanks Joanna!

Todd.

[Todd Weaver]

On Tue, 2014-12-02 at 18:04 +0000, Pedro Martins wrote:
> On 02-12-2014 11:00, Joanna Rutkowska wrote:
> Hard disk hacking
> http://spritesmods.com/?art=hddhack
>
> Free Linux Driver Development!
> http://www.kroah.com/log/linux/free_drivers.html
>

Thanks for sharing, it is helpful to know that the community will get
behind our goals. I will push upstream to simply 'grant access' and when
we need to influence by signing an NDA ourselves, scrub, and release
what we can, we will do just that.

> If you can manage to have some hw OEMS' to commit to supply you
> (no-strings-attached preferably) tech specs for their hardware,
> free/open drivers/firmware can be developed to support it.
>
> But I understand that is easier to say than do...

When we can make it a zero cost game, it makes it a lot easier, as then
it is just business negotiations. Which we are willing to spend the time
doing.

> Also, have you considered providing your hardware with SteamOS?

No, we have not.

> At first it seems to be contrary to your goals, but if you can manage to
> provide an open/free hw platform & associated sw to drive it, and add on
> top of it add some closed stuff (games!), those of us wishing for better
> security/privacy protection can then customise it to our liking (like
> having GamingVM within Qubes! R3 should be able to support this IIRC).

Realize that if we close our funding goal, we will be shipping laptops
that meet the strictest of beliefs. You are free of course to install
SteamOS or anything else for that matter onto the device. (Same goes for
Qubes OS).

> By having SteamOS/gaming laptop you can increase you target audience, no?

I imagine so, but we need to focus on our goals of freedom respecting
hardware bundled with freedom respecting software. You can of course run
SteamOS/gaming on this laptop.

> But I'm hinting you this for selfish reasons; this way you would have to
> provide also a nice gaming keyboard (no numeric keypad please!).

Yes, we cannot please everybody.

> Thanks for all your efforts to make this happen.

Thanks! I appreciate the support!

Todd Weaver
to...@puri.sm

[Todd Weaver]

On Nov 25, 2014, at 8:01 AM, juwa...@gmail.com wrote:
> ...however in its current configuration, the CPU does not support VT-x/VT-d.
> ...and an option for 16GB RAM - everything else looks decent.
>
> [1] https://www.crowdsupply.com/purism/librem-laptop


Thank you all for your help in pinning down the CPU that would work best with QubesOS, and yet fit most everything else we required.

With this update:
https://www.crowdsupply.com/purism/librem-laptop/new-hardware-options

We have (finally) been able to design the motherboard to support the i7-4770HQ chip and increase to 16GB of RAM.

As promised, I am updating the qubes-users mailing list with this news!

Let me know if there are any concerns, questions, or comments.

Todd Weaver
to...@puri.sm

[syd2...@gmail.com]

So do you know how the wireless devices - wifi & bluetooth - are organised and operate on the motherboard? For example, are they both on the same module? Also, is part of the wifi circuitry embedded in the motherboard, and part on the module - or is it all on the module? Because wifi has an uplink and a downlink. So if you remove the module does that only stop the downlink - with the uplink still being broadcast from the motherboard? 

These devices are difficult to fully turn off. For example, if you turn off wifi, airplane mode can come on, and if you turn off airplane mode, bluetooth can come on. And on some computers you may not be able to turn one of them off at all - not even in the BIOS. How will your h/w switch handle this complexity?

[Todd Weaver]

On Tue, 2014-12-09 at 20:12 -0800, syd2...@gmail.com wrote:
> So do you know how the wireless devices - wifi & bluetooth - are
> organised and operate on the motherboard? For example, are they both
> on the same module?

We are providing a half-height minipcie wifi daughter card, we could
bundle it with bluetooth, but there are no bluetooth drivers that are
binary free, so we'd have to have that freed.

You can see the video of it being taken out (and put back in) here:
http://puri.sm/posts/the-librem-15-laptop-video/

> Also, is part of the wifi circuitry embedded in the motherboard, and
> part on the module - or is it all on the module? Because wifi has an
> uplink and a downlink. So if you remove the module does that only stop
> the downlink - with the uplink still being broadcast from the
> motherboard?

I am not sure I follow this exactly, but I'll try to answer this way, we
are working to design where function key combinations physically cut
power to devices, so wifi (possibly bluetooth), camera, microphone, each
have a key combination that cuts power.

> These devices are difficult to fully turn off. For example, if you
> turn off wifi, airplane mode can come on, and if you turn off airplane
> mode, bluetooth can come on. And on some computers you may not be able
> to turn one of them off at all - not even in the BIOS. How will your
> h/w switch handle this complexity?

We are not yet final on our design, but it will either be a function key
combination controlled at the BIOS level to cut power, or a physical
switch. We are still a little bit away from the answer to how best to
handle it.

Todd.

[Pedro Martins]

A true physical switch is better - it cannot be turned on/off by
accident while typing or conflict with some program keyboard mapping;
key combinations can be injected by malware e.g. to turn camera/mic on!

Probably more demanding/costly hardware-wise to implement...

--
Pedro Martins

[Pedro Martins]

Great news! Thanks for your efforts to accommodate qubes-users wishes.
It's great to have more RAM and higher dpi display options.

Regarding the updated specs, I have some questions:

1) Is the display reflective or matte (non-glossy)?


2) Which chipset are you considering, HM86, HM87 or QM87? [0][1]

My concern here is that the only one that supports Trusted Execution
Technology (TXT) is the one with vPro support (QM87). And all of them
support Anti-Theft Technology, aka phone-home snitch feature (probably
can be disabled). That Small Business Advantage also sounds fishy!

The lack of TXT support is probably a deal breaker for some (most?)
qubes-users. Anti Evil Maid requires it. [2] [3]


3) If TXT is to be supported somehow, will you have a TPM module as an
option (must have motherboard support)? [3]


Sorry to be nagging you about this, I fully understand that your main
objective is to have the most free hardware/software combination
possible; unfortunately there seems to be a conflict currently regarding
qubes needs in hardware support and what can be free on the software side.


[0] i7-4770HQ Processor
http://ark.intel.com/products/83505
http://ark.intel.com/products/83505#@compatibility

[1] HM86, HM87 and QM87 compared
http://ark.intel.com/compare/75531,75528,75525

[2] Anti Evil Maid
https://wiki.qubes-os.org/wiki/SecurityGuidelines#AntiEvilMaid
http://theinvisiblethings.blogspot.pt/2011/09/anti-evil-maid.html

[3] from an intel cpu datasheet:

"No computer system can provide absolute security under all
conditions. Intel ® Trusted Execution Technology (Intel ® TXT) requires
a computer system with Intel ® Virtualization Technology, an Intel
TXT-enabled processor, chipset, BIOS, Authenticated Code
Modules and an Intel TXT-compatible measured launched environment (MLE).
The MLE could consist of a virtual machine monitor,
an OS or an application. In addition, Intel TXT requires the system to
contain a TPM v1.2, as defined by the Trusted Computing
Group and specific software for some uses. For more information, see
http://www.intel.com/technology/security/"

--
Pedro Martins

[Franz]

On Wed, Dec 10, 2014 at 6:12 PM, Todd Weaver <to...@puri.sm> wrote:

On Tue, 2014-12-09 at 20:12 -0800, syd2...@gmail.com wrote:
> So do you know how the wireless devices - wifi & bluetooth - are
> organised and operate on the motherboard? For example, are they both
> on the same module?

We are providing a half-height minipcie wifi daughter card, we could
bundle it with bluetooth, but there are no bluetooth drivers that are
binary free, so we'd have to have that freed.

You can see the video of it being taken out (and put back in) here:
http://puri.sm/posts/the-librem-15-laptop-video/

Awasome video! Where are you building it? Any plan to make a smaller model, like a 12.5? Why only 8GB max RAM, are there problems for 16 GB?

Good luck, you deserve it!

Fran

 

> Also, is part of the wifi circuitry embedded in the motherboard, and
> part on the module - or is it all on the module? Because wifi has an
> uplink and a downlink. So if you remove the module does that only stop
> the downlink - with the uplink still being broadcast from the
> motherboard?

I am not sure I follow this exactly, but I'll try to answer this way, we
are working to design where function key combinations physically cut
power to devices, so wifi (possibly bluetooth), camera, microphone, each
have a key combination that cuts power.

> These devices are difficult to fully turn off. For example, if you
> turn off wifi, airplane mode can come on, and if you turn off airplane
> mode, bluetooth can come on. And on some computers you may not be able
> to turn one of them off at all - not even in the BIOS. How will your
> h/w switch handle this complexity?

We are not yet final on our design, but it will either be a function key
combination controlled at the BIOS level to cut power, or a physical
switch. We are still a little bit away from the answer to how best to
handle it.

Todd.

--
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...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1418242349.22686.51.camel%40dave.att.net.

[Todd Weaver]

On Thu, 2014-12-11 at 07:59 -0200, Franz wrote:

> You can see the video of it being taken out (and put back in)
> here:
> http://puri.sm/posts/the-librem-15-laptop-video/

> Awasome video! Where are you building it?

We are sourcing the case and component parts, manufacturing the
motherboard from a fabrication plant in China (this is why we need to
have a minimum order quantity run). We are assembling it all in South
San Francisco, loading the software, and shipping from here as well.

> Any plan to make a smaller model, like a 12.5?

13" is next, which we have prototypes for, if we reach our funding goal
for the 15".

> Why only 8GB max RAM, are there problems for 16 GB?

The video has two updated changes: 16GB (we went from 4 layer to 6 layer
motherboard to support the extra 8GB).
And we upgraded the CPU (to support VT-x, and VT-d, per QubesOS mailing
list recommendations) which threw out the nVidia.

>
> Good luck, you deserve it!

Thanks!
>
> Fran

Todd.

[Todd Weaver]

On Wed, 2014-12-10 at 22:21 +0000, Pedro Martins wrote:

> Great news! Thanks for your efforts to accommodate qubes-users wishes.
> It's great to have more RAM and higher dpi display options.
>
> Regarding the updated specs, I have some questions:
>
> 1) Is the display reflective or matte (non-glossy)?

matte (non-glossy) for the 1080p screen, we are evaluating the 4k screen
suppliers to decide.

> 2) Which chipset are you considering, HM86, HM87 or QM87? [0][1]

HM87, we are avoiding vPro.

> My concern here is that the only one that supports Trusted Execution
> Technology (TXT) is the one with vPro support (QM87). And all of them
> support Anti-Theft Technology, aka phone-home snitch feature (probably
> can be disabled). That Small Business Advantage also sounds fishy!

There are a lot of configuration options we have when setting up the CPU
for the first time. We will publish what we are allowed. We are working
with security advisors to make sure we configure the CPU in the best way
to support free software, and privacy.

> The lack of TXT support is probably a deal breaker for some (most?)
> qubes-users. Anti Evil Maid requires it. [2] [3]

I have read the posting on Anti Evil Maid (Joanna is a great writer), I
would like to maybe discuss an alternative solution, but maybe I should
move that to a new thread. In short, if a user could burn a one-time
cert, thus immutable from change, and the BIOS binaries must be signed
with that cert, that I suspect would suffice, but I'm not the expert.
This is what we are considering.

> 3) If TXT is to be supported somehow, will you have a TPM module as an
> option (must have motherboard support)? [3]

I doubt it, but we are looking into TPM, per QubesOS mailing list
request.

> Sorry to be nagging you about this, I fully understand that your main
> objective is to have the most free hardware/software combination
> possible; unfortunately there seems to be a conflict currently regarding
> qubes needs in hardware support and what can be free on the software side.

I think there is a way to solve both the free software and security, at
least we're willing to discuss it to see!

Thanks for writing!

Todd.

[cprise]

On 12/11/14 14:53, Todd Weaver wrote:
> On Wed, 2014-12-10 at 22:21 +0000, Pedro Martins wrote:
>
>> The lack of TXT support is probably a deal breaker for some (most?)
>> qubes-users. Anti Evil Maid requires it. [2] [3]
> I have read the posting on Anti Evil Maid (Joanna is a great writer), I
> would like to maybe discuss an alternative solution, but maybe I should
> move that to a new thread. In short, if a user could burn a one-time
> cert, thus immutable from change, and the BIOS binaries must be signed
> with that cert, that I suspect would suffice, but I'm not the expert.
> This is what we are considering.

My understanding of AEM (using SRTM) is that it does *not* use TXT
(using DRTM). I think this is implied in Joanna's AEM blog post. Perhaps
ITL could clarify on this point...

[Marek Marczykowski-Górecki]

The first version of AEM was using SRTM, but the current one uses TXT.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[syd2...@gmail.com]

If the h/w switch is a function key combo, will that mean the settings will return to a default state each time you boot the computer? And the default state would probably be all devices on? Whereas a physical h/w switch would maintain the settings despite reboots?

And it would be good to see a motherboard design - in terms of how everything is connected (and will be disconnected via h/w switch) - if you can post one.

[cprise]

Congratulations on meeting your crowdfunding goal! (Its at "101%" as I write this...)

On 12/11/14 14:53, Todd Weaver wrote:

On Wed, 2014-12-10 at 22:21 +0000, Pedro Martins wrote:

3) If TXT is to be supported somehow, will you have a TPM module as an 
option (must have motherboard support)? [3]

I doubt it, but we are looking into TPM, per QubesOS mailing list
request.

Were you able to include a TPM (or a socket for one) in the Librem?

Its a significant enough security device that the Qubes HCL has a column for TPM. The Anti Evil Maid feature requires it.

[Todd Weaver]

On Wed, 2015-01-21 at 14:54 -0500, cprise wrote:
>
> Congratulations on meeting your crowdfunding goal! (Its at "101%" as I
> write this...)
>

Thank you!

>
> On 12/11/14 14:53, Todd Weaver wrote:
>
> > On Wed, 2014-12-10 at 22:21 +0000, Pedro Martins wrote:
> >
> > > 3) If TXT is to be supported somehow, will you have a TPM module as an
> > > option (must have motherboard support)? [3]
> > I doubt it, but we are looking into TPM, per QubesOS mailing list
> > request.
> >
>
> Were you able to include a TPM (or a socket for one) in the Librem?
>
> Its a significant enough security device that the Qubes HCL has a
> column for TPM. The Anti Evil Maid feature requires it.
>

We are working with Joanna, Jake Appelbaum, Matthew Garrett, and RMS to
see what options we have... No publishable update to provide yet.

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Joanna Rutkowska wrote:
> On 11/26/14 18:29, Todd Weaver wrote:
>> On Tue, 2014-11-25 at 20:46 -0500, cprise wrote:
>>>> 4) Hardware switches for the mic and camera? (Actually this
>>>> makes most sense on non-Qubes systems, but even on Qubes
>>>> might be useful :)
>>> If not switches, then status LEDs that are directly wired (not
>>> addressable by software) to the devices' power should also be
>>> an improvement in privacy. All status lights should be visible
>>> when laptop is closed. And if anything should have a hardwired
>>> on/off switch, I think it should be system power; The issue I'm
>>> thinking of here is the recent prevalence of integrated
>>> batteries for laptops and handhelds (they creep me out because
>>> they cannot be decisively turned off).
>>
>>
>> While there is a lot to reply to on this thread, this one is
>> quick... We do have LED light for the camera, hardwired. But what
>> we've been toying with is having a keystroke to cut power to the
>> camera (similar to wireless), I'll add to our list to consider
>> microphone, for the same obvious reason.
>>
>
> Cameras are easy to cover with a piece of tape [...snip...]

This is true, but it's kind of an annoying and messy solution. Todd,
please consider something like a simple hardware slide cover for the
camera, integrated cleanly into the body of the laptop. This should be
relatively cheap to implement, and a surprising number of people --
even (especially?) non-tech-savvy users -- really want this (e.g.,
[1]). I've seen this implemented in one or two other laptops and
netbooks over the years (simple plastic slide cover), and I'm not sure
why it's not more common. Right now, people who want something better
than tape or sticky notes have few options except products like
this[2], which don't work very well and tend to be ugly. (The idea of
a rotating camera, which can be rotated inward, is obviously even
better but also more complicated and expensive.)

[1]https://apple.stackexchange.com/questions/87726/is-there-a-high-quality-webcam-cover-solution-for-a-macbook-air
[2]http://www.amazon.com/Webcam-Cover-Laptops-Pad-Devices/dp/B004Z0XSY6
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU3e41AAoJEJh4Btx1RPV8NcMQANS6Cd/pvC7LwnbCKsyLBKrc
/GTp8nN/G85b1U1hKp6l20btGwPFIHBcth1BXIyRXlZB0EiMRPI/0KHt3SIsUlPp
bRDAXCHQjNLv12AvyI6Rbpo+PjSqGpXPNi0gp/hkiiYfIFya34fAVz8/bycRrvQh
xG2aYRIvz7FMtM14eE7BQE8UYZ1xplEC4COQqXy0d9wAK0WV/FdmVwyXWPDuzvbJ
oROknzSIgWrcIlahAX+cKtqMerVICmSkuPeEu9+oxFAd+uC1cCRkdkmhW8JAnd9v
OqSHY6ycTJZdZOtxpc68v+AWjGd0xpPGPX/ICUMXLYe5gKTGZ7cGR+z7MR+QhcJ7
7lQWXg0tucY8N326eQ6BdeLpAEftIndnZ/ZhPuGt4Y9LqAABHlnWQZyMTKfqZbuI
HEUWym5YPaKlPNyceaLOS5Y7H9AKLDZDHx0/VCQT/pmThiRI6o/+7VnTopEYQ49g
4CS9ksU30jJOt7r23jiLwNyeu9wSRC2AeO2vwHYsWPMpceDYCR7Ii0c1MPUPTi+/
8Ny2PG4AcSQoIzaPIRcJqyNOxBTgE9i3PvSlVTxNTbMTkY8bHVUE/R0yozrnySDu
b7biJXAAkpzWkcVNkTMZSQpKWrvjOc1TZ66FIWcoPFVe6kJ2B8Ob9uwI6i2S5ydT
PYu01fB0k+PMj8+80JwI
=CHpf
-----END PGP SIGNATURE-----

[WhonixQubes]

On 2015-02-13 12:29 pm, Axon wrote:

> Joanna Rutkowska wrote:
>> Cameras are easy to cover with a piece of tape [...snip...]
>
> This is true, but it's kind of an annoying and messy solution. Todd,
> please consider something like a simple hardware slide cover for the
> camera, integrated cleanly into the body of the laptop. This should be
> relatively cheap to implement, and a surprising number of people --
> even (especially?) non-tech-savvy users -- really want this (e.g.,
> [1]). I've seen this implemented in one or two other laptops and
> netbooks over the years (simple plastic slide cover), and I'm not sure
> why it's not more common. Right now, people who want something better
> than tape or sticky notes have few options except products like
> this[2], which don't work very well and tend to be ugly. (The idea of
> a rotating camera, which can be rotated inward, is obviously even
> better but also more complicated and expensive.)
>
> [1]https://apple.stackexchange.com/questions/87726/is-there-a-high-quality-webcam-cover-solution-for-a-macbook-air
> [2]http://www.amazon.com/Webcam-Cover-Laptops-Pad-Devices/dp/B004Z0XSY6

Agreed that camera tape is an inelegant solution that encourages user
laziness and makes one feel less good and proud about their "pure"
Purism computer.

Maybe including a simple but elegant camera cover like the "Nope" would
work well?

- https://www.kickstarter.com/projects/1893116150/nope-live-free

- https://www.bungajungle.com/products/nope

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Clever idea, but this review is scary:[1]

> Alex Olcese 1 day ago
>
> Be very careful using this product - it just ruined a MacBook Pro
> by cracking the LCD where the magnet was placed because it creates
> a pressure point when the screen is closed.
>
> Took it to the Genius Bar for service. LCD replacement is $800 and
> not covered under AppleCare it voids the warranty. In fact the
> Apple person told me I was the 2nd person they've seen in Orlando
> with this problem.
>
> This $5 part ended up costing me $800. Great idea, poor execution.

In the end, I think an integrated solution is always preferable.

[1]https://www.kickstarter.com/projects/1893116150/nope-live-free/comments
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU3004AAoJEJh4Btx1RPV8XQMQANdH+/WHmepakXCO6VXv2ysd
MMbMuTYx+D1SHqVecivb1V0BoJD8qn9LK/H0AIi2pAe62A9dGh7QhE2rEBo70n47
UF8TBcmogwsqRrjiXO1OZA1YWJLQLsdxxcorEeCSSCqkLogxheZozSxn/X6F4ga/
Dy1miFizkljwSLgfiAOojUUdbD9VQndQ+E8kPfqfSk2W8QhRcDXv9PS4ZqFM4HEi
t3sWyiB4I+053VxGBeaDLgNLw6mVM/wSAdPyaKkCQa2iVyj4PcZOCxUIvjb4CfnK
mGBh0MTwHA/M+XEdDrYkl7cLxzrVvTIzEEUtLoaKhY0oxHZ/kmHK3Tpi6MH4e0F5
LdT/LjELjQaKzy3AQhV44E291IYU2rTSTNWN/XtyIRqSme6N71fcl32tGNk5+0qG
qobyCOYCD6pvFovGtG9atN8KezDAcvDMaXt4CdTuOgtif68TPOHz8OI/VrZFQAQN
YYzYgU0vkrw4PhhDY9w5TTXVPeK08toJjL6T2wQN8qlxsL6WW7uq3wAXRrroDeZq
aipkPbEd0DR2s2xxY66jiK3V0gorZWKGpt+dov6IAQV9KSqLMhWUFjxHMqh686/F
A1myvJSDN9+0YDslKsmF412u/S1n5H5MgM9xhxGAvIVlX5NiCnsOKBUc7Dgv7u5z
idHtKvrQdC4z572xAPNe
=UPxw
-----END PGP SIGNATURE-----

[Todd Weaver]

On Fri, 2015-02-13 at 12:29 +0000, Axon wrote:
> This is true, but it's kind of an annoying and messy solution. Todd,
> please consider something like a simple hardware slide cover for the
> camera, integrated cleanly into the body of the laptop. This should be
> relatively cheap to implement, and a surprising number of people --
> even (especially?) non-tech-savvy users -- really want this (e.g.,
> [1]). I've seen this implemented in one or two other laptops and
> netbooks over the years (simple plastic slide cover), and I'm not sure
> why it's not more common. Right now, people who want something better
> than tape or sticky notes have few options except products like
> this[2], which don't work very well and tend to be ugly. (The idea of
> a rotating camera, which can be rotated inward, is obviously even
> better but also more complicated and expensive.)

A physical cover on the camera doesn't solve the microphone issue. So we
are going to (very likely) move the physical hardware switch we proposed
into a physical power cutting keyboard button (possibly Pause/Break, and
move that to a function combination) and have a corresponding case light
to show camera and mic HAS POWER or DOES NOT HAVE POWER. This is not
quite the same as a physical slider (meaning that may be more 'obvious'
to average users, so we are also considering that).

The important thing is combining both camera and mic into a single
easy-to-use physical power switch.

What you bring up would be a nice future version where a physical switch
covers the camera but also cuts physical power to both the camera and
mic, so all things are done together.

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Todd,

I'm very excited to see that the Librem 15 rev2 has many of the
features that were requested in this thread, including up to 32GB RAM
and an RF, mic, and camera hardware kill switch.

Are there any plans to have Qubes OS officially validated or tested on
the Librem 15 rev2? I'm sure many people in this community would be
eager to purchase a Librem on which to run Qubes, but given the
frequent hardware compatibility problems we encounter with other
laptops, many are probably holding back until they see some HCL-script
results, at the very least. I'm sure you can understand that it would
be a shame to purchase a several-thousand-dollar laptop only to find
out that one can't use it for the intended purpose.

Congratulations on your success!

Axon
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVcSe4AAoJEJh4Btx1RPV8grUP+QF/hstjZ95ZTEfZxpCv0r40
LpczYWP1ESZVB4wbpCwvUCM1LlmkZqbTd+/SzhcIVsqnUWQctapG4SEFJPOKOOJ2
X1caEZzYJqB95FR7WesW+cNDZKLbvoP+STcUZappj0okkMZaTHs/KQmsdujs1+yW
NA8yvNJ4rJOhAyFO5XqvAFM0+EGJwPS9IgslWWYt3mvolAxPDS6ro3aPqvfs3viS
6UEi6DHgfh8z1Vv3EhznNxuUifllbifBtUN1ll50OBSVFkagbq2xVzkjY8TL8541
YZpHEh54eASR3/SG1bs5ljsj/Q6l156/83eOgH7kbsMDQfT4Ju1QTqGRJxun8KDA
LiAS/cM8eIaLqA8STDhvoPnVCGQexdcbeL1q5qVuiFQ7NyXsc/xZzwvI9yN6fDDd
Z3x7Mv72+fM82cJZFsFcWBTCX5xatMV1zXa2J3nESlF5b0UvOrZ7XAEL1IvoeANk
G2VWS9Qhu5dvcdk1mWjm9HmPZNvUTdwba1dyHaE9xiIOyuxVS+9vSaH4ByvPxbAG
lxozUfi4tFxb/aF6oBrOaHePzAHuBgU7D/z+yR/L6eQy64XqK4frafQDLODl5RHz
R6+tCGVnssc9+ggdX478OGSYCOUwiQWmh0I28QXXV47VtM0OdZECmOtaFI0ftl1J
amCjUsrfRYqXZdYMbpEi
=9x/r
-----END PGP SIGNATURE-----

[Alex]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/05/2015 06:38 AM, Axon wrote:
> Are there any plans to have Qubes OS officially validated or tested
> on the Librem 15 rev2? I'm sure many people in this community would
> be eager to purchase a Librem on which to run Qubes, but given the
> frequent hardware compatibility problems we encounter with other
> laptops, many are probably holding back until they see some
> HCL-script results, at the very least. I'm sure you can understand
> that it would be a shame to purchase a several-thousand-dollar
> laptop only to find out that one can't use it for the intended
> purpose.

+1, I'd love to have a laptop which just works 100% with Qubes OS.

I'm coping with some minor problems on my asus K550JD (this model does
not even appear to exist on asus website), like the
multitouch-touchpad not working (only single-touch behavior) or the
function keys not working (volume +/-/mute, brightness up/down) even
if they worked with Qubes 2 on a Zenbook. I'm not reporting those
problems to the Qubes team because they are quite minor annoyances,
and I know they are working hard on more important things. Those bugs
may also be related to the dom0 Fedora, which then makes them out of
scope for the project.

But if I knew that some laptop has everything that just works with
qubes, say also because of contributions (e.g. open source driver
debug?) to upstream projects, that would be great.

- --
Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVcTcWAAoJENNOJZnNP8uDXKoP/jUUv9GQqYL4ApLb47jdH9ri
+6CJ5Ty0hF2ZtgsIRhkMfVjNMZeVHh6ydWh0DpbqPHYz6a1pNOhZDLDupSpX8bNS
W/xhmB2w3hl2twGlSoZutOBJP/iORZ40PWb4tp36z6NsABLXP/XPRm7om5GhHpB+
Oq/cUbyVSe/A879yo10DRRBeZDbensXBCWj0MiMYzlWT1lA4sECqDQbZ3rWqI3yu
XZ2pxSfk8wlyeMOfNuwxp00PSCdbzZJkZoECwBYF9/fqH6aCFrCE9GWyRJu/qlAl
2fy9/oVA44e7lVPSCZjmo/pk9q24S/9UnlF0lbibKFR852wIcgNSSXlpGWasxCN5
//ViHkgKTJFcyzNAONBE7fvq73SzM6mYunt9iQz0HvfOdOBvZ/s2V/DbqgqJsLu4
EWqQ8R32N+pflghb3pITjlFkJ2x6IWbApjjXEIjcRGUz9NJUBrVn41dGjBPONXrX
JZbIQFmJ01jnObDr7VQAfKIyVWhW+aXZCvFzEQ5CgxER/HcsRO9QRYY8kRPQrFcd
kPmgUGQbLWqx8iOtOX52BVW7Mxv/rQ5cGHh53ASkA1ppjEP7z5wI3YFWfsXBU2Pq
j3LMRI6nfXAxhPV1FIplFA2pdOqS0HF5RvZC1HGGqBXO2Nfu1QkXRhwecI6wBBDB
tGckwYeE98bUS0y9Q9b7
=v388
-----END PGP SIGNATURE-----

[Todd Weaver]

On Fri, 2015-06-05 at 04:38 +0000, Axon wrote:
> I'm very excited to see that the Librem 15 rev2 has many of the
> features that were requested in this thread, including up to 32GB RAM
> and an RF, mic, and camera hardware kill switch.

Thanks! We're excited as well!

> Are there any plans to have Qubes OS officially validated or tested on
> the Librem 15 rev2?

Our plan, with QubesOS as well as other validation/certifications (such
as Tails), is to work with the community for each to have them
validate/certify. Such as providing a unit to the community for
validation/certification for a short period.

> I'm sure many people in this community would be
> eager to purchase a Librem on which to run Qubes, but given the
> frequent hardware compatibility problems we encounter with other
> laptops, many are probably holding back until they see some HCL-script
> results, at the very least.

I understand that. There is a balance between supporting us early so we
can get to the point of product shipping, and waiting for validation.
Which is why all the early support has been instrumental for us.

> I'm sure you can understand that it would
> be a shame to purchase a several-thousand-dollar laptop only to find
> out that one can't use it for the intended purpose.

Correct, and the intended purpose for us is not (at this time) QubesOS
as primary. However, we love what you're doing, and it is so very close
to alignment, we will continue to collaborate.

> Congratulations on your success!
>
> Axon

Thanks Axon!

Todd Weaver
to...@puri.sm