Uncorrectable freedom and security issues on x86 platforms

[Daniel Pocock]

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



On 23/04/16 23:05, Timothy Pearson wrote:
> On 04/23/2016 03:34 AM, Daniel Pocock wrote:
>> There are also various other ways to approach this, for example,
>> I started a discussion about ARM-based NAS devices on the
>> debian-arm list[1].  This is one market where the hardware is
>> readily available and the fact it is low power is considered a
>> virtue by most purchasers.
> 
> The other thing I would encourage is MIPS-based platforms for
> routing devices.  There are a number of options on the market
> already, some with quite a number of GbE network ports built in.
> 
>> The ASUS C201 appears very weak in the specs.  Some things that
>> bother me are the screen resolution (only 768 pixels high) and it
>> is USB 2 only.  I don't like the Chrome logo on it either (or is
>> that a sticker that comes off?).  Are there slightly stronger
>> alternatives?
> 
> It is fairly weak; there hasn't been a lot of push to create
> stronger alternatives that still respect the owner's rights.  The
> POWER systems are the only real option on the high end, leaving
> middle-ground users (including higher-end laptop users) without any
> options.  This probably won't change for a while due to razor-thin
> margins in the mid-range arena and lack of overall demand.
> 
> That all being said, there are some stronger ARM Chromebooks coming
> down the line this year.  Google Oak is one platform to watch; the
> SoC used in those machines gives you ARM64 plus virtualization, but
> sadly that machine is not yet available to the public.
> 
>> Another strategic topic on this theme: people won't necessarily
>> see this thread and throw away all their x86 equipment the same
>> day. However, how can these ideas be introduced to people at the
>> times when they are making purchasing decisions?
> 
> You're correct, and we're not advocating that people dump their
> existing machines, only that this is considered when purchasing
> another machine. What I personally would like to see is the major
> FOSS projects and distros starting to think beyond x86, perhaps by
> compiling and testing their software on ARM / POWER as well as x86,
> even if they are continuing to develop on older x86 machines for
> the time being.  In the case of router distributions (pfSense comes
> to mind) the developers should start focusing on providing (at
> minimum) an ARM or MIPS port; this would also have the bonus of
> lowering the power consumption of the router package.
> 

Debian already does that:

https://buildd.debian.org/
  (see the list of CPU architectures across the top of the table)

Here is an example for one of my own packages built on all
architectures.  The build also runs the unit tests on every
architecture, to catch any big endian issues, etc:

https://buildd.debian.org/status/package.php?p=resiprocate&suite=sid

Another thing that comes to mind: getting some of this hardware out in
public at events.  What would it take to have some POWER-based systems
on display at LinuxWochen and MiniDebConf Vienna (28 April - 1 May)
this week, or at DebConf in July?

Vienna would be good because there is a lot of official interest in
reducing the dependency on US technologies:
http://techrights.org/2009/12/11/osor-updates/

and there are various projects going on there already.


> As you say, the current Opteron 4xxx/6xxx series devices are
> currently adequate for most work.  The danger is complacency; 5 -
> 10 years from now those chips will be wholly inadequate for many
> common tasks and there may be no way to upgrade in performance
> without also sacrificing freedom.
> 
> I should also point out that all recent AMD chips, including the 
> upcoming Zen Opteron CPUs and the modern FX-series devices,
> require signed binary blobs to boot.  They are not free and, worse,
> by design, they can never be freed.  AMD has also refused to
> release any documentation on the A1200 series devices, and it is
> highly likely they will also require a signed TrustZone binary to
> boot.
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXHHXzAAoJEGxlgOd711bEtEkQAIIqxOsyxNR4hJQpVQFM7qLp
iHHhnDr4IDcwNEUkjzxHpHakaBHeFQ6UZf2XvtLFOi5PmSaPbS83gks62t92BGEQ
zBAZl3kZZCfmznTanco33cg9h0VOkUkBwT7K31N5o+beBq+zsbFbp6ASzxAcByS2
qE2qwNXQYLRxIifrKcPSL2vPihTKka2Ktk4dQhVEwaLIUA3IivxVtWzXg50WMxJL
y8FvdQfADzoJtyw0jjMcZmghdIWGB/6sqOalnQs0vu4JowKhMPvicBkZO3SvecKI
6c/+oz5qs6in+zAHCr86nUZvnos9lbusTOaBNBNVLGjoBTKqV1X72JqhS0bb98Ap
5slayW+n02xG7FPlrPR4c8hfkNhrHPd6w5AOj9WQlYfeVz5XZA6Vaql2KqIQsaVr
vfwk1Q9ALp2lwH7KCc8DYOSIJGCYDsnhsBUmY2uALFtSOtgVR6KB6FTsfk6A7/0q
hc54fg3oXjq+HP/Tl/LEQdgQiMKK3HQ4oJsSwxGbaLpd2tNlwfqWBLjNtqdQrKTN
Tkd9nUWgX/b9rZ0K/3zPwLFskOGGyExoVWU3E9chSxIbg4wIS9H8c/AoMPsmPLxG
kD4YkUJPSk7dxQSn2qRFEZyDi5zlt9bY/issEtkpd9IjLKbECcy7kxVl76opxY9r
ew8pN33Cv6ONVi+dzz0P
=GtKr
-----END PGP SIGNATURE-----