Hlavní navigace

Vlákno názorů ke zprávičce Odteď jsou pro Chrome všechny HTTP stránky ne-bezpečné od RDa - Chudak AVR, ted na nej musim doimplementovat SSL.....

  • Aktualita je stará, nové názory již nelze přidávat.
  • 26. 7. 2018 12:21

    RDa

    Chudak AVR, ted na nej musim doimplementovat SSL.. nebo pouzivat normalni prohlizec, ktery nezneuziva sveho monopolu.

  • 26. 7. 2018 13:41

    Petr M (neregistrovaný)

    Gratuluji ke skvělýmu rozhodnutí implementovat web server do něčeho s pár kilama RAM a pár desítkama kilo ROM bez crypto modulu, ale zato s 8b int aritmetikou a bez FPU/VPU. Ve kterým století že to rozhodnutí bylo učiněno?

  • 26. 7. 2018 14:13

    misaz (neregistrovaný)

    V 21 století. 16 Mhz (zhruba 16 000 000 instrukcí za sekundu) na webový server i v roce bohatě 2018 stačí. Navíc tento jednoduchý a přímočarý čip není náchylný na chyby typu meltdown, specter a obdobné chyby, které se v komplexních procesorech ještě objeví. Nakonec třeba za 10 let zjistí (AVR je dostatečně spolehlivý na to aby dokázal fungovat více než 10 let), že jeho vlastnoruční implementace HTTP(S) je už z principu bezpečnější než implementace pomocí crypto modulů vašeho procesoru ve kterých se tou dobou objeví nějaká bezpečnostní díra o které třeba nikdo zatím neví. Byť to samozřejmě není zrovna efektivní.

    Jednoduché a přímočaré čipy budou mít vždy svoje místo, ať je libovolné století.

    // P.S. pár kil RAM je luxus, dodnes se vyrábějí a vydávají AVR se stovkami nebo i desítkami bajtů RAM. Třeba nové ATtiny204

  • 26. 7. 2018 15:45

    Petr M (neregistrovaný)

    "16 Mhz (zhruba 16 000 000 instrukcí za sekundu) na webový server i v roce bohatě 2018 stačí."

    Motor ze sekačky na trávu taky stačí na to, aby utáhl auto. Že to auto bude muset mít kastli z balzy a cestující půjdou vedle auta, nebude tam topení a startovat budeš taháním za špagát je přece detail.

    První věc, 16MHz != 16MIPS, ale v reálu uvažuj tak 12 MIPS. Nemá to díky jednoduchosti predikci skoků a zahazuje tak pipeline.

    "Navíc tento jednoduchý a přímočarý čip není náchylný na chyby typu meltdown, specter a obdobné chyby, které se v komplexních procesorech ještě objeví."

    Další výborná vlastnost je to, že je to Harvard, tj. instrukční sběrnice (16b) oddělená od datové sběrnice (8b). Jakýkoliv výstup na LAN (nebo displej, sériovku,...), pokud je složený z konstantních dat a proměnných, tak máš dvě možnosti. Buďto výstupní funkci mít 2x (SendFromRam(), SendFromFlash() ), nebo bufferovat komplet data v RAMce. Kolik že jí má? Max. 16kB? Good luck.

    Vem si, že MTU je na Ethernetu 1500B. + hlavičky + režie ve stacku (stavový proměnný,...). Pokud budeš chtít pro jedno spojení mít buffer na dva pakety pro každý směr, pod 6kB RAM se nedostaneš. K tomu povinný protokoly jako ICMP, DHCP,... Počítej tak minimálně 4kB RAM na IP adresu, MAC aderesu, parsovaný data requestu. Pro připojení jednoho klienta, konfiguraci atd. Dva sokety nedáš, kdyby ses na ptáka stavěl. Resp. dáš, 4+2*6=16kB, akorát jaksi nebudeš míst stack. Blbý, co? A to je zatím jenom HTTP.

    Pak je tady šifrování. Základem jsou operace sčítání, násobení, modulo a lookup tabulky. U sšítání s prací po bytech by to asi nějak šlo. Násobení, tam už jde výkon exponenciálně dolů (8bx8b=16b, 4x operace násobení + 4x sčítání; 16bx16b=32b, 16x násobení + 16x sčítání,...). To platí i pro modulo. Tabulky nedáš do RAMky ani do FLASH

    "Navíc tento jednoduchý a přímočarý čip není náchylný na chyby typu meltdown, specter a obdobné chyby, které se v komplexních procesorech ještě objeví."

    Ne, tam jsou totiž úplně jiný chyby, ale o těch se moc nepíše... Meltdown ani Spectre by mě v takové aplikaci opravdu asi netrápilo, ani kdyby byly HW dispozice, protože tam stejně není MPU, MMU, cache a další blbiny, tak bych si pro to mohl sáhnout přímo.

    "Nakonec třeba za 10 let zjistí (AVR je dostatečně spolehlivý na to aby dokázal fungovat více než 10 let), že jeho vlastnoruční implementace HTTP(S) je už z principu bezpečnější než implementace pomocí crypto modulů vašeho procesoru ve kterých se tou dobou objeví nějaká bezpečnostní díra o které třeba nikdo zatím neví."

    Security by obscurity? A kdo zajistí, že to nebude naopak? Navrhnout to na první dobrou líp, než u Linuxu s desítkama let vývoje a stovkama párů očí je opravdu majstrštyk. Až to uvidím, uvěřím.

    "Jednoduché a přímočaré čipy budou mít vždy svoje místo, ať je libovolné století."

    Jistě, ale ten si můžu dovolit třeba na generování PWM v LED svítidle, nebo časový relé nastavený poťákem, ... Nemůžu designovat na něčem, kde už dneska musím dělat brutální kompromisy a optimalizace na hranici možnýho a pak počítat, že za 10 let to ještě bude vyhovovat.

  • 27. 7. 2018 9:21

    Trident (neregistrovaný)

    Nekdy neni duvodem jednoduchosti omezenost vyvojare, ale omezene pozadavky. Napriklad spotreba v radech pikoamper max jednotky miliamper. Jednoduchost ladeni, potreba nizke intregrace(napr kvuli radiaci), nizky teplotni sum a tim padem nizsi naklady na izolaci/chlazeni kvuli presnosti mereni, levne nahradni dily, predikovatelnost chovani na urovni signalu.
    Mezi soft kriteria muze patrit i treba zkusenost vyvojoveho tymu, overena konstrukce daneho modulu a funkcni dodavatelsky retezec.

    Ja uz jsem starej. Oficialne studovanej nejsem, ruzovou kosili nenosim, teplej nejsem, do posilovny nechodim,nage­lovanej nechodum a na tzv. "startup meetingy" v nasi firme se koukam s despektem ( i presto ze jeden neco jako startup vedu ale to je jina story... ). Cili jak vidite ze nejsem zcela kvalifikovan se v teto oblasti vyjadrovat takze berte me vyjadreni s rezervou.

    Nicmene...

    Nicmene obvykly setup je ze mam hloupy podrazeny system ktery splnuje me naroky na omezeni dana zdroji/prostredim a nad to napojim treba pres UART/RS485/CAN/­SPI... nebo jine rozhrani nejakou inteligentnejsi krabici ktera v pohode da TCP/IP i s SSH/HTTPS .
    Hierarchie systemu dle slozitosti...

    Pripadne si k tomu dokoupim terminal koncentrator ktery to s vice skatulemi udela za mne.

    Pripadne si k tem hloupym HTTP vecem poridim nejaky VPN koncentrator ktery mi to cestu zabezpeci.

  • 27. 7. 2018 10:44

    Petr M (neregistrovaný)

    Nemám nic proti jednoduchým broukům, kde je jejich aplikace adekvátní, ale musím vědět, kde si ten luxus můžu dovolit.

    "Napriklad spotreba v radech pikoamper max jednotky miliamper."

    Potom tam automaticky nedávám Ethernet ani WiFi. Ani nic od Atmela.

    "Jednoduchost ladeni,..."

    U jednoduché předpotopní x51 jsi v ASM, standard je ladění osciloskopem a šmrdlání pinem. Nadstandard je výpis na UARTu, pokud je volný. U normálních MCU máš nějaký emulátor apod., kde si můžeš krokovat kód. Zcela překvapivě je to další modul na čipu, který s jednoduchostí nejde moc dohromady. A teď si představ, že jsou embedded systémy, kde ani ten JTAG nepotřebuješ, jenom připojíš Ethernet a spustíš GDB (většinou desky s ARM9, ARM11, Cortex-A, SH3, SH4, SH4A, MIPsy, PowerPC,...) Takže tenhle argument hodně pajdá. Čím složitější, tím líp se ladí.

    "... potreba nizke intregrace(napr kvuli radiaci), ..."

    To je jiná kategorie, tam napříkla dnesmíš mít FLASH paměti nebo (E)EPROM,... Takže tam jsou na to speciální brouci. A Ethernet PHY s nějakým bufferem a IP stack ve velké paměti programu je taky docela problém. Takže hádám, že tohle taky nebude ten případ.

    "... nizky teplotni sum a tim padem nizsi naklady na izolaci/chlazeni kvuli presnosti mereni, ..."

    Přesný měření se nedělá na MCU, ale mimo něj. S galvanickým oddělením, nezávislým zdrojem, systematicky oddělenou zemí atd. A AVRko má ADC ve stavu, že si nedokáže změřit ani to, jestli má na vstupu do desky 18 nebo 25V. Z vlastní zkušenosti. Takže zase argument mimo.

    "... levne nahradni dily,..."

    Aha. Od kdy že se zase mění procesory v paticích u embedded věcí? Ona práce je prakticky vždycky dražší, než měněná součástka (a pro info, v kusovce máš 200MHz 32b procesor pod 300, to je cena za hodinu práce zaměstnance, který ho má otestovat, vyměnit, vypálit program a ověřit funkčnost).

    "...predikova­telnost chovani na urovni signalu."

    Pokud chci, aby se digitalizovaný signál choval predikovatelně (malý jitter, minimální zpoždění,...), tak to není o jednočipu, ale o kombinaci ADC-FPGA-DAC. Případně ADC-DSP-DAC. Když je nejhůř, tak ADC-MCU-DAC, ale MCU s takovým výkonem, že přes 80% času tráví v IDLE, aby byla rezerva pro případ, že se třeba potkají tři přerušení. A iap k je to bez garance čehokoliv. Dát do takové aplikace mrchu, která při přerušení od tlačítka bude mít 10ms výpadek, je pěkně na pytel.

    "Mezi soft kriteria muze patrit i treba zkusenost vyvojoveho tymu, ..."

    Měl jsem jako FAE jednoho zákazníka. 20 let dělal s x51. Všechno v ASM, docela komplexní software. Jedna iterace ladění znamenala vyškubnout brouka ze zařízení, smazat, naprogramovat, zapojit do desky, připojit logický analyzátor, spustit program, prohrabat se výsledkama, upravit program, zbuildovat a repete (cca 35 minut). Jednou jsme mu ukázali jinou řadu MCU, s programováním v Cčku a laděním pomocí emulátoru. Koukal jak žaba z křa a hned ten den jsme měli objednávku.

    "overena konstrukce daneho modulu"

    Ověřená konstrukce je modulární konstrukce, na novým projektu používáš moduly ze starýho. To s výběrem CPU nijak nesouvisí - pokud je analogový front end na SPI, je jedno, jestli tam dáš AVRko, Cortex-A nebo FPGA. MCU je jenom jeden z modulů, nic víc.

    "a funkcni dodavatelsky retezec."

    Víš, proč AMD a Cyrix mají licence na x86? Proto, aby tehdá IBM neviselo jenom na jednom dodavateli.

    Kdo ti zaručí 2nd source pro PIC16, PIC18, AVR, S3Fxxxx, RC8, H8 nebo třeba MSP430?

  • 26. 7. 2018 14:16

    Pavel Snajdr

    A o co jsi lepsi, ze mas pravo mu mluvit do toho, na cem implementuje otevrene standardy?

    Kdyby posilal odpovedi na dernych stitkach, tak ma porad velmi validni pointu, ze ho nejaci frajeri nuti svym monopolem k necemu, co by vubec vubec nemusel hrotit.

    Nejste trosku padli na hlavu, jeste monopolu takhle tleskat za jednostranny rozhodnuti?

    Borci, co tu melou neco o meneni obsahu a jak je HTTP nebezpecne maji sami jiste davno uplne vsechna svoje spojeni ven sifrovana a do netu nejdou jinak, nez pres Tor nebo neco podobneho, ze?

    Jinak jste totiz pokrytci a ja jsem na vas nasrany za to, ze davate Googlu dalsi a dalsi mandat, chovat se, jak se mu zlibi.

    K*rvite svym pristupem netovy prostredi i mne a tim mne fakt tocite.

    Pokrytci.

  • 26. 7. 2018 15:11

    Petr M (neregistrovaný)

    Tak jasně, má právo dělat předpověď počasí na měsíc dopředu na jednom Am80386SX/33MHz, ale pak se nesmí divit, že tu předpověď dostane 10 let po konci období, na který ji dělá. Stejně tak má právo řezat dřevo na zimu pilníkem, zatloukat hřebíky skleněným těžítkem, dát si na kovadlinu gumovou podložku, nechat si ho vykouřit od hladové kanibalky,... Blbosti se meze nekladou.

    Ostatní zase mají právo jeho snahu ocenit smíchem.

    "Nejste trosku padli na hlavu, jeste monopolu takhle tleskat za jednostranny rozhodnuti?"

    Ne, není to o monopolu. Pořád je mezi prohlížeči volba.

    A pokud jde o jednostranný rozhodnutí, pokud se komerční firma rozhodne upravit nějak část jejich programu, kterou neupravuje žádný standard, tak je to jejich právo a je za zákazníkovi, jestli to bude používat. O úpravách komerčního SW se hlasuje peněženkou.

    Btw, rád bych viděl aktuálně platný RFC pro podobu adresního řádku prohlížeče v GUI...

  • 27. 7. 2018 11:25

    Přezdívka: * (neregistrovaný)

    Ano, protoze toto upozorneni jsem si v chrome://flags zapl uz v roce 2015. Moje API jedou pres HTTPS + Auth hlavicka -> Base64(Autorizacni kod + HOTP kod) + domain spoofing.

    Tor pouzivam jen omezene.

    Ted uz jsem zapl finalni podobu kde Not secured sviti cervene s vykricnikem.

    Resite kraviny a pritom jde jen o blby text v URL = uzivatel vaseho SW je informovan ze jste ignorati, ale aplikaci muze nadale pouzivat.

    "monopolu takhle tleskat za jednostranny rozhodnuti"
    Ze jste nenadaval na Google ze si vubec v Chrome dovoli pouzivat HTTP, ja jsem treba chtel zobrazovat stranky pres postovni holuby, ale ten velky zly google, ktery z nasazeni HTTPS nema absolutne nic protoze ani nevlastni certifikacni autoritu se proto rozhodl a ja utrel.