A Microsoft szerint a C++ nem biztonságos mission-critical rendszerekhez, inkább a Rust felé fordul

Titkosítás, biztonság, privát szféra
No matter how much investment software companies may put into tooling and training their developers, “C++, at its core, is not a safe language,” said Ryan Levick, Microsoft cloud developer advocate, during the AllThingsOpen virtual conference last month, explaining, in a virtual talk, why Microsoft is gradually switching to Rust to build its infrastructure software, away from C/C++. And it is encouraging other software industry giants to consider the same. [...] In fact, Microsoft has deemed C++ no longer acceptable for writing mission-critical software. The industry sorely needs to move to a performant, memory-safe language for its low-level system work. And the best choice on the market today is Rust, Levick said. [...] Today, C and C++ are the go-to languages for writing core system software. It is fast, with the only assembly between the code and the machine itself. But the industry is being crippled by all the memory-related bugs — many of which are security hazards — caused by these languages. Now, 70% of the CVEs originating at Microsoft are memory safety issues, Levick said.

Részletek itt.

( Caro | 2020. 06. 14., v – 09:39 )

Onnan hogy a C-t és a C++-t egy mondatban említilk, már látszik hogy nem jól használják.

Vagy C

vagy C++

Nincs C/C++, vagy ha igen, az nagy baj. Mindkettő egyébként egy jól használható nyelv, de ha keverjük őket, akkor pont a felsorolt problémák jönnek elő.

Pedig az is volt. Keress rá, volt egy olyan tipikus hiba, hogy vmelyik gyári app beragadt, és megette az akksit. Ennek mellékhatása volt, hogy reggel nem ébresztett a telefon. Aztán voltak még elmulasztott hívások, amiket állítólag kijavítottak, de időről időre újra előjöttek.

Pedig az is volt. Keress rá, volt egy olyan tipikus hiba, hogy vmelyik gyári app beragadt, és megette az akksit.

Ilyet én már androidos és iOS-es telefonnal is csináltam, ez nem kunszt :D

Aztán voltak még elmulasztott hívások, amiket állítólag kijavítottak, de időről időre újra előjöttek.

Ez előfordult velem is egyszer, a pontos okát nem tudom, de egy SIM csere megoldotta. 

Alapvető filozófia váltással lehet csak kiírtani a programozó által elkövethető alacsony szintű hibákat.

Azért én már láttam olyan céget is, ahol C++ nyelvi elemek használatával (pl. new és delete operátorok felülítása) sikerült kiirtani a programozó által elkövethető alacsony szintű hibákat.

Mondjuk lehet a nyelvi elemek által adott lehetőségek kihasználását alapvető filozófiaváltásnak hívni, mert valóban, a legtöbb helyen nincs így.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( hokuszpk | 2020. 06. 14., v – 13:41 )

hatize. asszem ugy 20 evvel megeloztem az ms -t :D

HUP te Zsiga !

( tr3w v | 2020. 06. 14., v – 13:51 )

Levick admits that Microsoft core developers won’t stop using C/C++ anytime soon.

“We have a lot of C++ at Microsoft and that code is not going anywhere,” he said. “In fact, Microsoft c++ continues to be written and will continue to be written for a while.”

Köszönjük, leülhet. 

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Akkor most jön az, hogy már JavaScriptben is írtak komplett oprendszert, sőt számítógép/processzor emulátort is, és hozok be csipsz-kólát...

 

Mellesleg az egész problémakör perfektül kezelhető lenne azzal, ha a programozókat minden slamposság (amiből ezek a security vulnerability-k keletkeznek) után suhogós acélvonalzóval pár pontos körmössel nevelnék rá egyes alapvető iránymutatás betartására.

( st3v3 v | 2020. 06. 14., v – 14:36 )

" is not a safe language"

nagyon nem hülye biztos. cserébe megengedi azt is, hogy lábon lődd magad :). 

Vannak 10 évesnél fiatalabb "gyerkőc"ök akik a faragókést sokkal magabiztosabban használják mint egyes felnőttek. Sőt egyes felnőttek.. hagyjuk.

( elod v | 2020. 06. 14., v – 15:11 )

A Mission Critical részt nem értem. Ott nem az Erlang bizonyított? És alapvetően nem procedurális hanem funkcionális programozást kéne használni?

Egy általános célokra került oprendszerben nem tudom mi a kritikus. Elszáll az OS, ott a másik...

( xc0m v | 2020. 06. 14., v – 22:07 )

A Linux kernelt is újra kell írni Rust-ban?

Nem biztos, hogy ordas baromság lenne mondjuk a top X driver kódjával egyetemben, aztán szépen sorra a többit is. Pár évtized tapasztalataival, kis refaktoringgal, satöbbi. Érdekes lenne, ha valaki meg POC-olná, mennyi erőforrást kellene bele tenni és mit hozna cserébe.

( trey | 2020. 06. 15., h – 07:38 )

"This Tweet is unavailable."

Hm....

trey @ gépház

( kisg v | 2020. 06. 15., h – 13:02 )

Azért szerintem az MS-nél dolgoznak elég sokan olyanok, akik többet felejtettek a C++-ról, mint itt a Hupperek többsége valaha is tudott róla...:)

Egyébként ha functional safety környékén elkezdetek nézelődni, akkor az fog kijönni, hogy míg C++-ra vannak olyan iparban elfogadott szabványok, amiknek a betartásával lehet safety critical kódot írni C++-ban (pl. MISRA C++) úgy, hogy mondjuk lehet rá ASIL D tanúsítványt kapni. Ez a munka Rust-ra már elkezdődött, de még nem tudok olyan projektről (ettől még lehet hogy van ilyen), ami már sikeresen átesett egy hasonló tanúsítási folyamaton.

Ezzel nincsen semmi baj, ezek a bejelentések nem arról szólnak, hogy holnaptól mindent Rust-ban írnak, hanem kijelölnek egy irányt, és szerintem a Rust egy jó irány.

( Gyuszk v | 2020. 06. 15., h – 16:53 )

Kicsit a JS -t is üthetnék nyilvánosan. Oké hogy JSben meg C++-ban is lehet hibátlan dolgokat megalkotni csak ugye ha nekiesik egy csapat ork a fejlesztésnek akkor eléggé előtérbe kerül hogy a nyelv milyen hülyeségeket tud kivédeni alapból és miket nem.

https://insights.stackoverflow.com/survey/2020#technology-most-loved-dr…
Persze csak miután már készség szinten tudod használni. Addig viszont el kell jutni. Közben lesznek napok amikor "<szitokszó> hú de nem klasszikus szemléletű ez".
Én már a "szeretem" fázisban vagyok.

Ugye a kérdés az, hogy Neked érdemes-e.

> csak érdekel a dolog

Hát én pl. ezért csinálom. :)

Amúgy az eleje tényleg nehéz.  De úgy érzem, C++-ban is jobban átlátom a helyzetet, amióta megértettem a Rust-ot;  másoktól is olvastam már ilyen véleményt.

(És egyre kevésbé tolerálom az include-rendszert.  Pl. hogy választanom kell aközött, hogy header only modult írok, vagy modulonként 2 forrásfájlt, amiben duplikátumok is vannak; egyébként épp most vitázott volt csoportom azon, hogy #pragma_once-szal vagy kézi header guard-dal lehet összességében kevesebbet szívni;  hát ez innen visszanézve már megmosolyogtató...  persze nem mondom, itt is van nehézség. :) ).

A Rust OOP-ben is húz azért kereteket rendesen, de polimorfizmus van, és ez a lényeg (runtime és compile time is).

Nekem nagyjából ez volt a sorrend:

  • ismerkedés a cargo-val, a nyelvtannal és a referenciákra vonatkozó szabályokkal.
  • első néhány egyszerűbb feladat megoldása, és szkanderozás a referenciákkal.
  • Háhá, a függvény meg tudja enni a változót.  De vicces. :)
  • Folyamatosan: trait-ek, implementációk (OOP).  Újfajta szintaxis megszokása.  Sokáig tart.  Polimorfizmus.  Algebrai adattípus.
  • ismerkedés a referenciák élettartam-jelöléseivel.  1-2 hét pofozkodás.
  • kéne egy closure, no de itt is referenciák vannak, megint az a fránya borrow checker.  1-2 hét kötöttfogású birkózás.
    • Ja, hogy closure-nél kétszer kell erre figyelni...  amikor átadom, és amikor hívódik.
  • "Tudok úszni", szuper.
  • Node akarok olyan generic metódust, ami T=erre &mut self, T=arra pedig csak &self.
    • bugybugybugy

( bodobacs | 2020. 06. 16., k – 22:43 )

Talán az a legnagyobb problémájuk, hogy nekik egy management seggét kinyaló nyelv kell.

( bocs | 2020. 06. 17., sze – 23:28 )

Sajna egyet kell hogy értsek, pár évtized C++ fejlesztés után hogy ez így van.

A biztonság, programozói kényelem, meg a teljesítmény sajnos ellentétes követelmények.
Nekem pl hatalmas felüdülés volt a c után a c++, majd a c++ után a c#.

De belátom, hogy ha a Moore törvény megbukott, akkor ki kell facsarni az utolsó órajelet is a CPU-ból egy komolyabb számolási feladathoz, és jelenleg nem ismerek más közepesen kényelmes, viszont szuper hatékony nyelvet.

A Rust elegánsabb, és erősen multi-cpu kihasználó, szóval a jó irányba tett lépés - de talán túl alacsony szintű ahhoz, hogy minden problémát hatékonyan megoldjon.
Még várok valami ütősebb nyelve, pl valami julia-szerűség?, ami képes elosztott rendszerekig biztonságosan és hatékonyan skálázódni.