Re: [PATCH 7/7] gnu: Enable CONFIG_HOTPLUG_PCI.

[David Craven]

> Could you clarify the commit log (like “Add CONFIG_HOTPLUG_PCI=y.”), and
> mention “For USB-C/Thunderbolt devices. Tested it with an USB-C to HDMI
> adapter.” in the log as well?

It's actually a duplicate definition. Missed it when searching the
file, it was probably missing from my custom buggy kernel
configuration so I concluded that it wasn't in the original... :-)

Re: [PATCH 7/7] gnu: Enable CONFIG_HOTPLUG_PCI.

[Ludovic Courtès]

David Craven  skribis:

> * gnu/packages/linux-libre-4.9-x86_64.conf
> * gnu/packages/linux-libre-4.9-i686.conf

Could you clarify the commit log (like “Add CONFIG_HOTPLUG_PCI=y.”), and
mention “For USB-C/Thunderbolt devices. Tested it with an USB-C to HDMI
adapter.” in the log as well?

Thanks!

Ludo’.

Re: [PATCH 7/7] gnu: Enable CONFIG_HOTPLUG_PCI.

[David Craven]

Mmh, I think that forcing binary blobs out of the linux kernel is only
useful if vendors move more work into the driver and silicon instead
of firmware that cannot be updated, since each flash device is a
security risk. But it could also backfire. The thunderbolt firmware
for example is only updateable from windows. That leaves me with a
crashy hdmi output and doesn't stop the NSA from flashing it anyway
and getting access to my PCIE bus - definitively not an improvement
over a binary blob...

I'll push these patches if there are no objections then. Can I
regenerate a pgp key? I think my keys where in the gnome keyring or
something, backing up ~/.gnupg/secring.pgp didn't keep my keys :/

Re: [PATCH 7/7] gnu: Enable CONFIG_HOTPLUG_PCI.

[David Craven]

Hi Danny,

> For example, let's say Intel had non-updateable microcode on its CPUs and it 
> included a backdoor. If anyone *ever* found it, nobody would trust Intel ever 
> again - and Intel couldn't sweep it under the rug because millions of 
> physical chips that include the backdoor would be in the hands of different 
> people. What could they do?
>
> On the other hand, if firmware is updateable by a (possibly automated) 
> program, that program could easily check whether it's running on *your* 
> computer specifically and then give you a special firmware. Now nobody but 
> you has a chance to find it. Not to mention checking the date etc.
>
> With all the spying going on that's a *real* possibility. Also, many people 
> already found backdoors in BIOS updates for example - so it's not theoretical.

But you can check the hash of the firmware. If a device doesn't have
internal flash we at least know that it's running the firmware we are
giving it. If the device has internal storage and if someone wanted to
target you and did have the resources to do so, they could reflash the
chip and you'd never know. Isn't human error just as scary as the NSA?

Re: [PATCH 7/7] gnu: Enable CONFIG_HOTPLUG_PCI.

[David Craven]

> I don't think the firmware needs to be uploaded at all to the AR9285 device.

I don't understand:

1. free firmware - anyone can update the firmware
2. binary blob - the vendor can update the firmware
3. fixed at manufacturing time - no one can update the firmware

Option 1 is obviously superior to the other two. But how is option 3
better than option 2?

Re: [PATCH 7/7] gnu: Enable CONFIG_HOTPLUG_PCI.

[Danny Milosavljevic]

Hi David,

I have an Atheros AR9285 in GuixSD and it works. 
/sys/class/net/wlp2s0/device/driver says it's using the driver ath9k PCI.

On Thu, 2 Feb 2017 18:07:22 +0100
David Craven  wrote:

> I'm having trouble finding information. The opened atheros firmware is
> only for the AR7010 and AR9271 USB dongles if I understand correctly?
> The other thing that was opened are the C headers including the
> register definitions for a subset of the AR9300 chipset, but it would
> still require implementing the firmware to be useful to linux-libre?

I don't think the firmware needs to be uploaded at all to the AR9285 device.

It probably does have a firmware on-chip - I don't know.

Anyway, it worked out of the box without any extra firmware files on my 
computer.

Re: [PATCH 7/7] gnu: Enable CONFIG_HOTPLUG_PCI.

[David Craven]

> I was surprised that linux-libre works on the dell xps 13. I'm
> considering buying an atheros wifi card, since that's the only thing
> that does not work. Does anyone know how to find out if there is a
> BIOS whitelist/blacklist? So it's just ARM boards that don't work with
> linux-libre?

I'm having trouble finding information. The opened atheros firmware is
only for the AR7010 and AR9271 USB dongles if I understand correctly?
The other thing that was opened are the C headers including the
register definitions for a subset of the AR9300 chipset, but it would
still require implementing the firmware to be useful to linux-libre?

Re: [PATCH 7/7] gnu: Enable CONFIG_HOTPLUG_PCI.

[David Craven]

I was surprised that linux-libre works on the dell xps 13. I'm
considering buying an atheros wifi card, since that's the only thing
that does not work. Does anyone know how to find out if there is a
BIOS whitelist/blacklist? So it's just ARM boards that don't work with
linux-libre?

Re: [PATCH 7/7] gnu: Enable CONFIG_HOTPLUG_PCI.

[David Craven]

This is for new USB-C/Thunderbolt devices. Tested it with an USB-C to
HDMI adapter.