Branch Privilege Injection (CVE-2024-45332, Paper) je nejnovější bezpečnostní problém procesorů Intel. Intel jej řeší ve včerejším opravném vydání 20250512 mikrokódů pro své procesory. Neprivilegovaný uživatel si například může přečíst /etc/shadow (YouTube).
Dle plánu byl vývoj Firefoxu přesunut z Mercurialu na Git. Oficiální repozitář se zdrojovými kódy je na GitHubu.
V terminálovém multiplexoru GNU Screen byly nalezeny a v upstreamu ve verzi 5.0.1 už opraveny bezpečnostních chyby CVE-2025-23395, CVE-2025-46802, CVE-2025-46803, CVE-2025-46804 a CVE-2025-46805. Podrobnosti na blogu SUSE Security Teamu.
Training Solo (Paper, GitHub) je nejnovější bezpečnostní problém procesorů Intel s eIBRS a některých procesorů ARM. Intel vydal opravnou verzi 20250512 mikrokódů pro své procesory.
Byla vydána nová verze 25.05.11 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Svobodný elektronický platební systém GNU Taler (Wikipedie, cgit) byl vydán ve verzi 1.0. GNU Taler chrání soukromí plátců a zároveň zajišťuje, aby byl příjem viditelný pro úřady. S vydáním verze 1.0 byl systém spuštěn ve Švýcarsku.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 209. brněnský sraz, který proběhne tento pátek 16. května od 18:00 ve studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Jelikož se Brno stalo jedním z hlavních míst, kde se vyvíjí open source knihovna OpenSSL, tentokrát se OpenAlt komunita potká s komunitou OpenSSL. V rámci srazu Anton Arapov z OpenSSL
… více »GNOME Foundation má nového výkonného ředitele. Po deseti měsících skončil dočasný výkonný ředitel Richard Littauer. Vedení nadace převzal Steven Deobald.
Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Zdravim,
potreboval bych zporvoznit udev na embedded zarizeni bezici na kernelu verze 2.6.19.2. Zarizeni ma 2 USB porty, na ktere bych potreboval pripojit 2 USB gprs modemy. Problem je v tom, aby kazdy modem byl identifikovat podel pripojeni (port1 - zarizeni /dev/modem1, port2 - zarizen /dev/modem2). Pro tyto ucely jsem nastavil udev, pridal mu pravidla pro jednotlive modemy:
KERNELS=="1-1:1.0", SUBSYSTEM=="tty", SYMLINK+="modem1"
KERNELS=="1-2:1.0", SUBSYSTEM=="tty", SYMLINK+="modem2"
Udaje jsem opsal z vypisu udevinfo. Problem je, ze symlinky se nevytvori a dokonce udevtest na /class/tty/ttyACM0 nevypise nic, ze by provadel nejakou akci. Pokud do udev.rules pridama pravidlo:
KERNEL=="eth0", SYMLINK+="test_sit"
a spustim udevinfo /class/net/eth0 pak se vypise, ze by se vytvoril symlink test_sit, cili udev jako takovy funguje. Nemate nekdo tuseni, proc udev nefunguje na usb zarizeni, ale funguje na sit? Pripadne jak rozlisit 2 usb modemy podle toho, do jakeho portu jsou pripojeny?
KERNELS=="1-1:1.0" vs KERNEL=="1-1:1.0"?
Zkousel jsem i SUBSYSTEM=="usb", ale ani tak to nereagovalo. Nechapu, ze napr. pro sit to funguje, ale usb udev nejak odmita. Zkousel jsem vytvaret pravidla pro disk KERNEL=="hda1" (pripadne SUBSYSTEM=="block") a taky nic (i kdyz podle vypisu udevinfo by to melo byt spravne).
udevinfo vypisuje KERNELS, primo u zarizeni je KERNEL=="ttyACM0", ale z toho nejsem schopen rozpoznat, na ktery USB port je zarizeni propjeno. Prvnich nekolik zaznamu v udevinfo:
$ udevinfo -a -p /class/tty/ttyACM0
looking at device '/class/tty/ttyACM0':
KERNEL=="ttyACM0"
SUBSYSTEM=="tty"
DRIVER==""
ATTR{dev}=="166:0"
looking at parent device '/devices/pci0000:00/0000:00:0f.0/usb1/1-2/1-2:1.0':
KERNELS=="1-2:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="cdc_acm"
ATTRS{modalias}=="usb:v0681p0034d0000dc02dsc00dp00ic02isc02ip01"
ATTRS{bInterfaceProtocol}=="01"
ATTRS{bInterfaceSubClass}=="02"
ATTRS{bInterfaceClass}=="02"
ATTRS{bNumEndpoints}=="01"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bInterfaceNumber}=="00"
looking at parent device '/devices/pci0000:00/0000:00:0f.0/usb1/1-2':
KERNELS=="1-2"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{product}=="MC75"
ATTRS{manufacturer}=="Siemens AG Wireless Modules"
ATTRS{maxchild}=="0"
ATTRS{version}==" 1.10"
ATTRS{devnum}=="12"
ATTRS{speed}=="12"
ATTRS{bMaxPacketSize0}=="8"
ATTRS{bNumConfigurations}=="1"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceClass}=="02"
ATTRS{bcdDevice}=="0000"
ATTRS{idProduct}=="0034"
ATTRS{idVendor}=="0681"
ATTRS{bMaxPower}==" 0mA"
ATTRS{bmAttributes}=="e0"
ATTRS{bConfigurationValue}=="1"
ATTRS{bNumInterfaces}==" 2"
ATTRS{configuration}==""
....
# USB device by USB bus KERNEL=="sd?1", KERNELS=="3-3", ATTRS{busnum}=="3", SYMLINK+="usb_left" KERNEL=="sd?1", KERNELS=="7-2", ATTRS{busnum}=="7", SYMLINK+="usb_right_top" KERNEL=="sd?1", KERNELS=="7-1", ATTRS{busnum}=="7", SYMLINK+="usb_right_bottommyslím že to funguje dobře. Ale busnum u vás nevidím...? Očekával bych to tam co
KERNELS=="1-2"
:(
SUBSYSTEM=="usb", ATTRS{serial}=="nejakyserial", SYMLINK+="modem1"Ještě bych se podíval, jestli někde v jiných udev pravidlech není použita podmínka last_rule pro tento typ zařízení, to by pak tvoje další pravidla nebyla brána v potaz. Hledej něco jako (například):
KERNEL=="ttyACM[0-9]*", GROUP="modem", OPTIONS+="last_rule"
No on momentalne hlavni problem je ten, ze se na usb zarizeni neaplikuje zadne pravidlo (ani bez serioveho cisla). Ani s pravidlem:
SUBSYSTEM=="usb", SYMLINK+="modem1"
(coz by podle me melo platit pro vsechna usb zarizeni) se neprovede nic.
Pravidla popsana v puvodnim prispevku jsou jedina, co tam jsou, jine soubory s pravidly tam nemam.
Možná hloupá otázka, ale není ten udev na embedded routeru třeba nějaký ořezaný?
On to neni router. Ten udev jsem tam kopiroval rucne a je dost mozne, ze jsem neco vynechal. Nakopiroval jsem binarky udevd, udevinfo, udevtest, udevtrigger, udevmonitor a udevcontrol + knihovny nutne pro spusteni techto programu. V adresari /etc/udev/rules.d/ jsem vytvoril soubor s pravidlama, v kernelu je podpora pro sysfs, ktery se po nabootovani primountuje do /sys. Nevim, jestli nejsou pri prekladu kernelu nejake volby, ktere by mely zasadni vliv na funkci udev (krome hotplug).
Adresar /lib/udev tam mam, obsah je nasledujici:
-rwxr-xr-x 1 root root 7684 Apr 21 11:29 ata_id
-rwxr-xr-x 1 root root 7140 Apr 21 11:29 cdrom_id
-rwxr-xr-x 1 root root 499 Apr 21 11:29 check_driver
drwxr-xr-x 2 root root 1024 Apr 21 11:29 devices
-rwxr-xr-x 1 root root 9012 Apr 21 11:29 edd_id
-rwxr-xr-x 1 root root 496 Apr 21 11:29 firmware.agent
-rw-r--r-- 1 root root 3105 Apr 21 11:29 hotplug.functions
-rwxr-xr-x 1 root root 1259 Apr 21 11:29 ide-devfs.sh
-rwxr-xr-x 1 root root 688 Apr 21 11:29 ide.agent
-rwxr-xr-x 1 root root 614 Apr 21 11:29 logger.agent
-rwxr-xr-x 1 root root 2042 Apr 21 11:29 net.agent
-rwxr-xr-x 1 root root 11717 Apr 21 11:29 path_id
-rwxr-xr-x 1 root root 1298 Apr 21 11:29 raid-devfs.sh
-rwxr-xr-x 1 root root 1576 Apr 21 11:29 scsi-devfs.sh
-rwxr-xr-x 1 root root 559 Apr 21 11:29 scsi-re-add
-rwxr-xr-x 1 root root 20156 Apr 21 11:29 scsi_id
-rwxr-xr-x 1 root root 7412 Apr 21 11:29 udev_run_devd
-rwxr-xr-x 1 root root 7280 Apr 21 11:29 udev_run_hotplugd
-rwxr-xr-x 1 root root 13912 Apr 21 11:29 usb_id
-rwxr-xr-x 1 root root 14036 Apr 21 11:29 vol_id
-rwxr-xr-x 1 root root 2784 Apr 21 11:29 write_cd_rules
-rwxr-xr-x 1 root root 3477 Apr 21 11:29 write_net_rules
Tiskni
Sdílej: