3 3
sgjava

Meltdown and Spectre

Recommended Posts

16 minutes ago, sgjava said:

 

 To quote the most important sentence there (emphasis by me):

Quote

Only affected cores are listed, all other Arm cores are NOT affected

 

So how is Armbian affected?

  • Allwinner A10 boards (Cortex-A8): easy solution, stop supporting them, it's only one board left AFAIK
  • Micro-USB powered support nightmares called MiQi and Tinkerboard (Cortex-A17): in my personal opinion support for power hungry boards with Micro-USB for DC-IN should be phased out. Once this is done problem solved
  • ODROID-XU4 (Cortex-A15): stop supporting legacy kernel and switch next from 4.9 to 4.14 (in the hope of an upstream fix arriving soon)

That's it.

 

BTW: it's frustrating how much attention Meltdown and Spectre get compared to more severe security issues :( 

 

Edit: I forgot i.MX6 (Cortex-A9). Given how 'popular' these boards are these days the most easy 'solution' would also be to phase support out.

Share this post


Link to post
Share on other sites

Ok, Cool, BTW the NanoPi Duo V1.1 is supposed to support OTG unlike the v1.0 boards. We chatted about this on another post. This means I should be able to power off the rail and use the micro USB for something besides power.

Share this post


Link to post
Share on other sites
10 hours ago, tkaiser said:

 

BTW: it's frustrating how much attention Meltdown and Spectre get compared to more severe security issues :( 

 

 

Frustrated yes, but also a positive step forward.    Sometimes the FUD for stuff like this scares organizations to patch.    I've been trying to get the blessing to do bulk patching for 2 years and finally my company is ready to do it!.

Share this post


Link to post
Share on other sites

Only a handful of newer ARM cores are affected and to be honest neither Meltdown or Spectre are BIG problems in most contexts anyway. Im not saying they are not serious, Spectre can be used to evade ASLR on ARM which can help to create buffer overflows and read / guess at other process data but we have plenty of vectors already for that already. Meltdown is a bigger problem and can be vectored into revealing large amounts of kernel level data.

 

For the SoC's we support that are vulnerable (A17, A57, A72) we have patched but its more a PR excercise than a real concern for most contexts. Spectre isnt even a security bug technically speaking. Its an intentional performance feature (badly designed maybe), the behaviour has been known about for 10+ years. Im really not sure why suddenly everyone is panicking about it now.

 

If you were running VM hosts with lots of guests then Spectre & Meltdown together is a much bigger problem (you could get kernel and user data belonging to other VM's that should be isolated) but very few people are doing that on ARM right now. 

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

Big digression but:

 

In regards to @tkaiser negative and pessimistic suggestions to keep dropping board support for problem boards,  I think he is absolutely correct.

 

While Im not a big Armbian user (we have our own linux based OS stack that we created from scratch and an ubuntu 16.04 derivative we tailored), I do follow its progress quite closely and its clear that there isnt enough engineering resource to support the list of boards that you try to support. Thats not a criticism, its just the reality of any open project. Once you have a board up and running, even at just 25% of completion, every TV Box shitter and their dog wants it all working, right now, on mainline, with 8K support, running from a nokia 3210 charger, etc, etc.

 

There seems to be enough engineering resource to support about 10 major boards with minor variations. To my mind it would make much more sense and make Armbian a much more valuable project to support less boards to a higher level and to have fully standardised functionality across all "officially" supported boards. Officially supported boards get support for 3/4/5 years or whatever. You dont even try to support a board unless every critical dev on the project has at least one of them.

 

By standardised Armbian functionality, I mean things like:

  • standard Armbian GPIO (+i2c, spi, 1wire, etc) library (@Larry Bank already made a good start here)
  • standard RTC interface, utils and device (we only support 3 RTC drivers)
  • standard NAND interface, layout, device
  • standard GSM interface, utils and device (we only support 5 drivers)
  • standard and predictable network interface naming, handling and utils
  • standard hardware / psu stress test
  • standard sound and video in / out / process utils (standard interface is pretty difficult here I accept)
  • standard remote access interface for cloud control
  • standard config utility
  • standard base OS. pick debian 9 or ubuntu 18.04 for future dev, stop trying to support both (my personal preference is debian but there are good commercial reasons to stick with ubuntu LTS)
  • limited SD card support. dont support any re-badgers (Kingston, entry level sandisk, toshiba, etc ). we only use sandisk extreme plus and sandisk high endurance and have a failure rate of approx 2 in 1000

 

That doesn't mean you cant have another 15 "community" supported boards, but with those there is no promise of full functionality and no official support offered. Those boards need to have community champions (individuals that want to help support specific boards, probably because they have them at home) and automated builds of community supported boards, its just means they dont get factored into long term development planning, support and testing.

 

What would you rather see from Armbian?

1) 30+ boards with levels of completion from 20%-95% and different functionality on each (think GPIO, NAND, RTC, GSM, etc)

2) 10 boards with 90%+ level completion and with standardised Armbian specific functionality across all of them? With 20 more community supported unofficial boards. 

 

Once you have structure 2 in place then you also have the correct structure to start making money from commercial support offerings. Think Armbian Gold / Pro whatever where you sell commercial support delivered via a cloud interface where the customers can manage all their devices (1-1M) from a web browser. This is what we do.

 

Controversial suggestion but you should support at least 1 variant of the RasPi. I know the hardware is shit and the RasPi foundation is full of shit but its also the most common SBC on the market. For that reason we do support the RasPi 3 only and while there are concessions to be made we also have roughly 6500 of them on support with our own OS stack at £5/€5 per month per device. We normally manage to get clients off them and onto something better at the next platform refresh.

Edited by botfap
Fix 3am returning from the pub typos

Share this post


Link to post
Share on other sites
On 1/5/2018 at 4:56 PM, tkaiser said:

Edit: I forgot i.MX6 (Cortex-A9). Given how 'popular' these boards are these days the most easy 'solution' would also be to phase support out.

 

I've got three Cuboxes around the house running on Armbian quite happily – it would be sad to see support 'phased out'.

Share this post


Link to post
Share on other sites
On 6.1.2018 at 4:20 AM, botfap said:

I do follow its progress quite closely and its clear that there isnt enough engineering resource to support the list of boards that you try to support. Thats not a criticism, its just the reality of any open project.

Then you also saw, that each of them have their favorites and they do it for fun.

Name me who of them cares about: GSM, NAND, RTC, Sound, Video, Resolution?  If there is no interest or fun in doing it, then there is simply nobody.

How do you want to overcome this situation?

 

Share this post


Link to post
Share on other sites
 
I've got three Cuboxes around the house running on Armbian quite happily – it would be sad to see support 'phased out'.
My udoo quad is the most important machine at home :(

Sent from my Redmi Note 4 using Tapatalk

Share this post


Link to post
Share on other sites
On 1/6/2018 at 3:20 AM, botfap said:

There seems to be enough engineering resource to support about 10 major boards with minor variations.

 

I guess it's up to Igor to decide this. I think even 10 boards is too many. Perhaps the Top 5 get priority. I suspect this would mean most of the Orange PI derivatives would be the focus - but one only needs to look at the forums to see they already are.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
3 3