• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    SPIRALIRust - Programovací jazyk

    A language empowering everyone to build reliable and efficient software.

    The Rust Programming Language - The Rust Programming Language
    The book of Rust
    Idiomatic rust
    GitHub - usagi/rust-memory-container-cs: Rust Memory Container Cheat-sheet
    Memory container cheat sheet
    rozbalit záhlaví
    SPIRALI
    SPIRALI --- ---
    NYX: Nevim jestli rozbiti na vice crate az tolik pomuze. Pro pri vyvoji vice crate najednou stejne chce clovek workspace a zase tam bude jen jeden cargo lock. Alespon me nejaka takova kolize trapila davno s nejakou tehdejsi verzi RLS a vice crate mi moc nepomohlo.
    NYX
    NYX --- ---
    SPIRALI: No rust-analyzer mam vypnuty, nejak mi to kolidovalo s buildem (vyrobil ten cargo lock a build na nej pak ceka). To pouzivam jako pomerne tupy editor :) Takze asi nejsem schopny odpovedet.

    Kdyz me to bude dlouhodobe stvat, dam si tu praci a rozbiju to na vic nezavislych crate. Nemelo by to byt moc slozite.
    MARASAN
    MARASAN --- ---
    SPIRALI: pouzivam vim s nejakyma pluginama, ale uvazuju, ze zkusim MS VS Code, hlavne kvuli debuggeru.
    SPIRALI
    SPIRALI --- ---
    NYX: Rust Enhanced jsem mel v planu take vyzkouset. Nejaky konkretni zdroj nespokojenosti?

    btw: Umi uz RLS nebo rust-analyzer nejake vetsi refaktorizace? (napr. kdyz presunu soubor tak to opravi vsechny importy?)
    NYX
    NYX --- ---
    SPIRALI: Ja jedu v sublime + rust enhanced + rustfmt. Ale nejak zvlast spokojeny s tim nejsem teda.
    SPIRALI
    SPIRALI --- ---
    Otazka pro vsechny: Jake pouzivate pro Rust IDE?

    Ja jsem prosel cestou Spacemacs -> vscode -> pycharm + rust plugin. Pycharm je pro mne horsi editor nez ty predchozi dva, ale k diky moznost refaktorizatorizace a obecne analyzy kodu u mne vyhrava. (Navic kolega byl jednu dobu nejaktivnejsi prispevatel do Rust pluginu, takze mam 1st-class support coz dost pomaha:)
    SPIRALI
    SPIRALI --- ---
    UETOYO: I kdyz to neni u zadne ISO-like organizace, tak jak to chapu ja, tak je specifikovano vse pomerne presne az na memory model. Coz je trochu problem pri psani unsafe kodu, ale trapi to primarne autory verifikacnich toolu, v praxi se uvazuje LLVM model (~ C++ model), na kterem ted stoji hlavni prekladac.
    FALL
    FALL --- ---
    UETOYO: pardon, moje chyba, špatně jsem to přečetl. Předpokládal jsem, že tam popisují cestu Rustu k RFC procesu u nějaké mezinárodní organizace typu ISO nebo IEEE, ale to je pouze popis interního RFC mechanismu v Rust "komunitě".

    Nicméně ta odpověď je hned o pár kliků vedle: https://doc.rust-lang.org/stable/ a https://github.com/rust-lang/rust

    Ano, není na tom nikde razítko nějaké "modré" organizace, ale jako specifikace všech částí mi to příjde dostatečné. Například C++ to dělá stejně (draft standardu je na githubu a konkrétní vydýání pak jen "otiskne" ISO).
    ELHO_CID
    ELHO_CID --- ---
    FALL: souhlasím, jsme tu trochu OT, ale kde je tu diskuze o MCU security? O žádné nevím.
    Fyzické útoky jsou oblast, kde klasické MCU končí a nastupují secure produkty, souhlasím. Ale i tam je ta hranice jen o kus dál a pokud má útočník k dispozici neomezený přísun virgin čipů, které si může rozlámat, tak se tím otvírají další možnosti. Nedostupnost těch čipů mimo okruh ověřených zákazníků je prostě součást security.
    FALL
    FALL --- ---
    FALL
    FALL --- ---
    ELHO_CID: uff, tahle diskuze se beojím odehrává ve špatném klubu, ale moderátor snad promine. Já mluvím o opravdovém kontaktním útoku, kdy má útočník fyzický přístup k té věci (čipu). Pro IoT zařízení a útoky z vnějšku "krabice" nebo dokonce útok na dálku přes internet/Bluetooth/atd. jsou ochrany typu secure boot, attestation atd. rozhodně dobrá věc a pokud je to napsané správně, můžou i při děravém stacku nebo chybě v aplikaci zabránit, aby útočník dostal data ven nebo aby dokázal nahrát vlastní firmware.

    Nicméně jakmile do obrazu přidáme útoky, kdy si to zařízení může útočník na pár dní půjčit domů a rozebrat, začíná být většina dnešních TrustZone implementací bezbranná, protože ty čipy nejsou stavěné na věci jako side channel/power analysis, glitching, probing atd. Takže s vybavením v řádech stovek až ticíců dolarů se útočník dostane "dovnitř" a ani TrustZone ani FW/loader/kernel napsaný v Rustu ti nepomůže. Viz například tato historka (nRF52840 má TrustZone a je mu to na nic):

    nRF52 Debug Resurrection (APPROTECT Bypass) Part 1 - LimitedResults
    https://limitedresults.com/2020/06/nrf52-debug-resurrection-approtect-bypass/

    Ano, určitě jde vývoj dopředu a v kombinaci TrustZone + unmutable OTP paměť + PUF a podobné věci budou tyto útoky stále těžší, ale bez opravdu bezpečného návrhu daného čipu aby ustál ty běžné útoky (hádání klíčů za běhu z EM záření nebo spotřeby, glitching a aktivní útok na startovací sekvenci za běhu, přímé čtení paměti když se otevře pouzdro...) můžeš jen těžko vymyslet byznys model, ve kterém bys mohl garantovat ochranu věcí, které mají hodnotu větší, než řekněme 1000 dolarů (protože to bude cena, za kterou ti X lidí ochotně takový "běžný" čip vyláme v laboratoři, t.j. dostaneš veškerý kód a data a můžeš vesele začít dumat, jakou další chybu tam mají a jak jí využít už relativně levně na zbytku těchto zařízení rozesetých po světě...)
    RUDOLF
    RUDOLF --- ---
    btw.. kdyby někoha vývoj v rustu na game jamy, tak vyšel nový release bevy

    Bevy - Bevy 0.5
    https://bevyengine.org/news/bevy-0-5/
    ELHO_CID
    ELHO_CID --- ---
    FALL: troufám si tvrdit, že consumer čipy s TrustZone už jsou i pro zkušeného útočníka oříšek, pokud je ten secure boot v produktu uživatelem nakonfigurovaný dobře. Vlastně stačí správně použít ARMovský TF-M. Ale ve výsledku jistota není, dokud na tom někdo nezaplatí hodně drahý penetration testing v nějaké renomované laboratoři. A v tom to právě je, vývoj a testování seure aplikací je drahá záležitost, takže to opravdu dělají jen velcí hráči, zatímco firmám střední velikosti vychází jako nejlepší použití JavaCard. Koupit si čip s vlastnostmi SC000/SC300 v GM je pak úplná utopie. Proto bude průnik Rust do tohohle konzervativního odvětví běh na dlouhou trať.
    Nejlepší by asi bylo začít se srovnávat s tím TF-M.
    FALL
    FALL --- ---
    A aby tu byly i názory z "druhé stran, tak je dobré zmínit, že né všichni sdílej Bryanovo nadšení...

    Back to Go, Rust is Slow (in Ways That Matter to the Most People)
    https://www.youtube.com/watch?v=5cEunr8hPE0
    FALL
    FALL --- ---
    A když už to tu tapetuju, tak ten coming out dokončím: o Rustu jsem slyšel poslední 4 roky od několika lidí, ale nikdy jsem neměl moc čas se dotoho pustit. To se změnilo před pár měsíci a jeden ze spouštěčů bylo několik přednášek od Bryna Cantrilla, který téma bezpečného HW a SW (od low-level FW až po operační systém a aplikační vrtvy) otlouká už delší dobu z mnoha úhlů. Pokud jste na takové věci tak doporučuji, Bryan je zábavný řečník (nicméně má tendenci stejné přednášky opakovat, takže je dobré si je vybírat:)

    Is It Time to Rewrite the Operating System in Rust?
    https://www.youtube.com/watch?v=HgtRAbE1nBM
    FALL
    FALL --- ---
    ELHO_CID: Ano, ST33 je asi komerčně nejúspěšnější čip implementující SC300, de-fakto všechny eSE/eUICC v telefonech používají ST33 HW, ale k dokumentaci a samotnému čipu se dostanou jen velcí hráči jako Thales/Gemalto, G&D, Idemia... Malý podíl má i NXP (jejich eSE v iPhonech podle mě také používá SC300) a Infineon (SLC37, SLE97 jsou oba založené na SC300).

    Já osobně doufám, že někdo udělá v zásadě dostupný čip založený alespoň na SC000, třeba příští iterace RPi2040. Ty ARM TrustZone a CryptoCell jsou krok správným směrem, ale stále to pro trochu zkušeného útočníka nic není (= dostane se do čipu oklikou skrz jakoukoliv HW chybu a vysype FW i s daty a klíči, aniž by musel překonávat nějaký secure boot s TrustZone a podobně).

    Ale zpět k tématu: Rust a ARM Cortex-M podle mě má budoucnost a snad budu mít výhledově čas si s tím alespoň pohrát a vyzkoušet to na něčem reálném (jako jsou ty STM32F nebo L generické čipy).
    GIOMIKY
    GIOMIKY --- ---
    Rust Programming Language Raises Privacy Concerns
    https://heimdalsecurity.com/blog/rust-programming-language-raises-privacy-concerns/

    According to StackOverflow’s 2020 developer survey, Rust has taken the top spot as the most loved programming language.

    Nevertheless, for the past five years, developers have been concerned by their production builds leaking potentially sensitive debug information, writes Ax Sharma.

    Back in 2017, a Rust developer posted an issue on the Rust lang’s GitHub asking, “How can I stop rustc [from] including system specific information such as absolute file paths of the source it’s compiled from in the binaries it generates?”
    ELHO_CID
    ELHO_CID --- ---
    FALL: na SC300 je založena rodina ST33, ale bojím se že není normálně na prodej koncovým zákazníkum. Ale STM32 L5 používá Cortex-M33 a ten má TrustZone.
    RUDOLF
    RUDOLF --- ---
    REDGUY: to je i benefit, někteří tvrdí že ten compiler tě nutí lépe programovat.
    RUDOLF
    RUDOLF --- ---
    SATAI: V angelcamu, kolega tam napsal několik služeb na kterých to běží, plus dělá ještě v jedný firmě, kde řeší customizaci kamer. Chvilku tam pracoval zrzka na vyučenou a napsal si tam službu na nahrávání rtsp do AWS. Myslím, že si to přitáhl do firmy kde pracuje.

    Ale Angelcam zatím spíš přežívá svoji téměř smrt, ale teď zase pomaloučku ožívá.
    FALL
    FALL --- ---
    Tohle vypadá jako ta správná aplikace v "embedded" světě: bezpečnostní token (FIDO a PIV), potenciálně i na temper resistent chipu (ten SoloKey je bohužel jen standartní STM32L4, ale dalo by se to potentiálně přeportovat i na čipy, které mají sofistikovanější HW ochrany a jsou ARM Cortex-M0/3/4 kompatibilní, t.j. třeba ARM SC000 nebo SC300)

    Trussed® Announcement - Trussed®
    https://trussed.dev/blog/trussed-announcement/
    Kliknutím sem můžete změnit nastavení reklam