1 पॉइंट द्वारा GN⁺ 2024-02-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ThinkPad X1 Carbon 6th Gen के छिपे हुए xDCI controller को चालू करने पर laptop खुद keyboard या storage device जैसे किसी भी USB device को emulate कर सकता है
  • सुराग /sys/class/usb_role/intel_xhci_usb_sw-role-switch था, लेकिन सिर्फ xHCI role switching काफी नहीं थी; अलग DWC3-based xDCI UDC को PCIe device के रूप में expose होना जरूरी था
  • BIOS image में xDCI Support setting थी, लेकिन default Setup UI में छिपी हुई थी; enable करने के बाद lspci में xDCI 8086:9d30 और dwc3-pci driver दिखाई दिए
  • सफल तरीका Advanced BIOS page unlock और NVRAM patch था; PCH register reconfiguration केवल PMC में कुछ बदलाव तक सीमित रही और PSF lock के कारण असफल रही
  • xDCI enable करने के बाद g_mass_storage, Raw Gadget, syzkaller reproducer और Facedancer backend बिना external hardware के चले, लेकिन VBUS कटी हुई USB cable और device role switching की जरूरत पड़ी

ThinkPad में मिले USB device mode के सुराग

  • Raw Gadget एक kernel module है जो Linux kernel USB Gadget subsystem को user-space API देता है, और गलत USB descriptors देकर USB host fuzzing और exploits में इस्तेमाल किया जा सकता है
  • सामान्य PC में USB Device Controller, यानी UDC, आमतौर पर नहीं होता और यह Raspberry Pi जैसे single-board computers में ज्यादा मिलता है
    • पहले के कामों के लिए Raspberry Pi या USB 3380-based EC3380-AB जैसे external hardware की जरूरत होती थी
  • ThinkPad X1 Carbon 6th Gen में /sys/class/usb_role के नीचे intel_xhci_usb_sw-role-switch मिला
    • /sys/class/usb_role hardware USB components को host mode और device mode के बीच switch करने का interface है
    • role file में device लिखने पर भी शुरुआत में कोई dmesg message या /sys/class/udc/ entry नहीं बनी
  • xHCI वह HCD है जो x86 systems में USB host के रूप में काम कराता है, और xDCI Intel द्वारा USB device-side interface के लिए इस्तेमाल किया जाने वाला नाम है

Kernel code और mailing list से समझी गई संरचना

  • Linux kernel में intel_xhci_usb_sw दो जगहों पर दिखता है
    • drivers/usb/roles/intel-xhci-usb-role-switch.c USB Role Switch driver implement करता है, जो device या host लिखे जाने पर xHCI registers manipulate करता है
    • drivers/usb/host/xhci-ext-caps.c तब intel_xhci_usb_sw virtual platform device बनाता है जब xHCI driver XHCI_INTEL_USB_ROLE_SW quirk set करता है
  • ThinkPad का xHCI PCIe device ID 0x9d2f था और kernel के PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI से match करता था
  • Linux kernel mailing list की चर्चा से पता चला कि xHCI और DWC3 UDC अलग devices हैं और उनके बीच एक mux है
    • role switch इसी mux को बदलता है
    • अगर DWC3 UDC खुद PCI device के रूप में नहीं दिखता, तो device mode के लिए कोई UDC मौजूद नहीं है
  • DWC3, Synopsys का DesignWare Core SuperSpeed USB 3.0 Controller IP है, जिसे Intel समेत कई vendors अपने systems में इस्तेमाल करते हैं
  • ThinkPad पर lspci check करने पर शुरू में केवल xHCI 8086:9d2f दिखा, और dwc3-pci.c के हिसाब से Sunrise Point-LP का xDCI device ID 0x9d30 नहीं दिखा

ACPI और BIOS में बचे xDCI के निशान

  • ACPI DSDT में Device (XDCI) और _STA method मौजूद थे
    • /sys/bus/acpi/devices/device:33/path \_SB_.PCI0.XDCI था
    • /sys/bus/acpi/devices/device:33/status 15 था, जिसका मतलब है कि device enabled and functioning state में है
    • लेकिन lspci में xDCI नहीं था, इसलिए यह केवल ACPI के नजरिए से ठीक दिखने वाली स्थिति थी
  • Default BIOS Setup screen में xDCI या OTG से जुड़ी कोई setting नहीं दिखी
  • Lenovo BIOS Bootable CD update image download करके BIOS binary /mnt/bios/FLASH/N23ET86W/$0AN2300.FL1 extract की गई और UEFITool से check की गई
  • Setup module के PE32 image section में strings search करने पर ये entries मिलीं
    • xDCI Support
    • Enable/Disable xDCI (USB OTG Device).
  • BIOS के अंदर xDCI Support setting थी, लेकिन default UI में छिपी हुई थी

Advanced BIOS page से xDCI चालू करना

  • x1c6-hackintosh project docs के अनुसार छिपे हुए Advanced BIOS page को खोलने का तरीका आजमाया गया
  • इस तरीके में BIOS वाले SPI chip को फिर से flash करना पड़ा
    • SPI clip इस्तेमाल करने के बजाय SPI chip को socket से replace किया गया, ताकि chip को कई बार निकाल-लगाकर experiments किए जा सकें
    • FTDI FT2232H Mini Module और flashrom से SPI chip contents dump और फिर write किए गए
  • BIOS patch दो stages से बना था
    • UEFIPatch से Date/Time BIOS page GUID reference को Advanced page की तरफ बदला गया
    • अलग byte patch से TPM को MFG Mode में force किया गया ताकि Boot Guard BIOS modification detect न करे
  • BIOS 1.37 में केवल पहला patch लगाने पर laptop beep करके boot नहीं हुआ; दूसरा patch लगाने के बाद Advanced page दिखाई दिया
  • Intel Advanced MenuPCI-IO ConfigurationUSB Configuration के नीचे xDCI Support को Enabled करने पर boot के बाद xDCI expose हुआ
    • lspci में 00:14.1 USB controller [8086:9d30] दिखा
    • kernel ने dwc3-pci driver अपने-आप load किया
    • /sys/class/udc/ में dwc3.1.auto बन गया

xDCI port और cable की शर्तें

  • xDCI से connected external USB port खोजने के लिए role को device पर रखते हुए USB flash drive को हर port में लगाकर check किया गया
    • किसी खास port पर OS ने flash drive detect नहीं किया, और role को वापस host करने पर वह फिर चलने लगा
    • उसी port को xDCI-connected port माना गया
  • ThinkPad का xDCI port USB Type-A था, इसलिए host computer से connect करने के लिए Type-A to Type-A male-to-male cable चाहिए थी
  • role switching port की power VBUS बंद नहीं कर रही थी, इसलिए दोनों devices के VBUS को direct connect होने से बचाने के लिए VBUS कटी हुई cable इस्तेमाल की गई
    • शुरुआत में दो USB 2.0 cables काटकर VBUS कटी हुई male-to-male cable खुद बनाई गई
    • बाद में PortaPow USB Power Blocker और male-to-male USB 2.0 cable इस्तेमाल की गई
  • g_zero gadget driver load करने पर दूसरे laptop पर test USB device सही तरह emulate हुआ
  • 11 जून 2024 के update के अनुसार, DataPro USB 3.0 Super-Speed A/A Debugging Cable में USB 2.0 D- और D+ भी कटे हुए हैं, इसलिए SuperSpeed connection establish करने के लिए जरूरी High-Speed connection fail होता है
    • manually VBUS काटी गई LogiLink CU0038 cable SuperSpeed device emulation के लिए काम करती है

PCH registers से software activation की कोशिश

  • BIOS xDCI को कैसे enable करता है, यह समझने के लिए Kaby Lake BIOS source code का Pch/Library/Private/PeiPchInitLib/PchXdci.c देखा गया
  • BIOS का xDCI disable path xDCI को PMC और PSF में disable करने वाली संरचना रखता था
  • PMC बदलाव

    • PMC के NST_PG_FDIS_1 register offset 0x628 के bit #24 XDCI Function Disable को clear करने से xDCI power gating हट सकती है, ऐसा माना गया
    • Linux kernel के pmc_core_device और pmc->regbase mapping को reuse करने वाला kernel module लिखा गया
    • boot के तुरंत बाद ST_PG_FDIS1 का ST_FDIS_LK bit #31 set था, इसलिए NST_PG_FDIS_1 value बदली नहीं जा सकी
    • laptop को suspend करके resume करने के बाद lock bit set नहीं था, और XDCI Function Disable bit clear करने में सफलता मिली
  • PSF बदलाव

    • BIOS PID_PSF2 Port ID 0xBB के PSF2 PCR में USB Dual Role (OTG) Function Disable bit set करके xDCI disable करता है
    • PCR address PCH_PCR_BASE_ADDRESS 0xFD000000 और Port ID, offset combination से calculate होता है
    • kernel module में PSF2 PCR को ioremap से map किया गया, लेकिन read value 0xffffffff आई और बदली नहीं
    • P2SB को unhide करने पर भी result वही रहा
    • BIOS का RemoveSidebandAccess EPMASK5 से PID_PSF2 को IOSF-SB से अलग करता है और MASKLOCK से lock करता है, इसलिए OS से PSF को फिर configure नहीं किया जा सकता था
    • PCH access PMC की कुछ settings में सफल रहा, लेकिन PSF reconfiguration fail होने से यह xDCI enable करने का तरीका नहीं बन पाया

NVRAM patch से Boot Guard bypass के बिना activation

  • BIOS settings SPI chip के NVRAM area में store होती हैं, इसलिए hidden Advanced page खोले बिना केवल xDCI Support value बदलने का तरीका आजमाया गया
  • IFRExtractor-RS से Setup module की UEFI IFR information extract की गई
  • xDCI Support setting PchSetup UEFI variable के अंदर store थी
    • VarStore GUID: 4570B7F1-ADE8-4943-8DC3-406472842384
    • VarStoreId: 0x5
    • VarOffset: 0x40
    • value range: 0x0 या 0x1
  • Linux के efivarfs में /sys/firmware/efi/efivars/PchSetup-4570b7f1-ade8-4943-8dc3-406472842384 check किया गया
    • efivarfs file के पहले 4 bytes header होते हैं, इसलिए actual xDCI Support value file offset 0x44 पर है
    • xDCI disabled state में value 00 थी, और BIOS Advanced page से enable करने के बाद 01 हो गई
  • user space या EFI Shell से उस variable को direct write करने पर EFI_WRITE_PROTECTED error आया
    • efivarfs का immutable attribute हटाने पर भी Read-only file system error आया
    • chipsec से EFI Shell में बदलने पर भी वही error आया
  • SPI programmer से पढ़ी गई original BIOS image में PchSetup के आसपास की byte sequence खोजकर केवल xDCI Support bit को 01 में patch करके फिर flash करने पर xDCI enable हो गया
  • इस तरीके में अभी भी SPI chip reflashing चाहिए, लेकिन Advanced page patch और Boot Guard bypass की जरूरत नहीं है और TPM भी नहीं टूटा
  • BIOS 1.37 में NVRAM patch करने के बाद 1.61 पर update करने पर BIOS setting value बनी रही, इसलिए patch दोबारा लगाने की जरूरत नहीं पड़ी

xDCI से USB device emulation

  • सभी examples यह मानते हैं कि xDCI BIOS में enabled है, intel_xhci_usb_sw-role-switch को device पर switch किया गया है, और VBUS कटी हुई cable से xDCI port और USB host connected हैं
  • Legacy gadget drivers

    • Linux USB Gadget subsystem के legacy gadget drivers module load करने पर किसी खास USB class device को emulate करते हैं
    • g_mass_storage file system image को USB mass storage device के रूप में expose करता है
    • FAT image disk.img बनाकर file.txt में Hi from xDCI डालने के बाद sudo modprobe g_mass_storage file=./disk.img stall=0 से load किया गया
    • USB host पर drive automatically mount हुई और file contents verify हुए
  • Raw Gadget

    • Raw Gadget को xDCI के साथ चलाकर USB keyboard example try किया गया
    • शुरुआत में यह SET_CONFIGURATION handling के दौरान रुक गया
    • वजह यह थी कि dwc3 और कुछ UDC drivers मानते हैं कि 0-length control request को gadget driver से confirm किए बिना तुरंत acknowledge किया जा सकता है
    • Raw Gadget में workaround patch लगाने और GadgetFS को भी fix करने के बाद keyboard emulation सफल हुआ
    • संबंधित behavior को documentation patch commit में整理 किया गया

syzkaller और Facedancer का उपयोग

  • syzkaller Raw Gadget का उपयोग करके Linux kernel USB stack की external fuzzing कर सकता है
  • Default syzkaller USB fuzzing kernel के अंदर virtual USB Device और Host controller को connect करने वाले Dummy HCD/UDC का इस्तेमाल करती है
  • xDCI इस्तेमाल करने के लिए syzkaller के UDC selection code को dummy_udc की जगह dwc3-gadget, dwc3.1.auto में बदला गया
  • syzkaller द्वारा पाए गए WARNING in smsusb_start_streaming/usb_submit_urb bug के reproducer को syz-execprog -enable=usb से चलाया गया
    • Ubuntu 5.15.0-91-generic kernel को host बनाने वाले laptop पर usb_submit_urb warning reproduce हुई
    • यह bug smsusb driver द्वारा USB endpoint type validation छोड़ देने से हुई WARNING थी, और harmful behavior नहीं था
  • Facedancer Python-based USB device emulation framework है
    • Raw Gadget-based Facedancer backend अभी prototype है और out-of-tree Raw Gadget patch पर निर्भर करता है
    • BACKEND=rawgadget, RG_UDC_DRIVER=dwc3-gadget, RG_UDC_DEVICE=dwc3.1.auto set करके rubber-ducky.py example चलाने पर यह सही चला
  • Raw Gadget-based USB Proxy भी xDCI के साथ चला, और xDCI का इस्तेमाल करके laptop को USB sniffer या USB Man-in-the-Middle tool की तरह इस्तेमाल किया जा सकता है

दूसरे devices और software तरीकों की संभावना

  • ThinkPad X1 Carbon 6th Gen के अलावा दूसरे PCs में भी xDCI activation संभव हो सकता है
    • सबसे सरल स्थिति में BIOS setting से xDCI चालू करना ही काफी हो सकता है
    • ACPI और role switching support होना चाहिए और xDCI port external port तक wired होना चाहिए
  • दूसरे ThinkPad में भी xDCI BIOS setting छिपी और protected हो सकती है, इसलिए SPI chip reflashing की जरूरत पड़ सकती है
    • NVRAM तरीका Boot Guard bypass के बिना लागू किया जा सकता है
    • कुछ नए systems के SPI chips में reflashing RPMC से protected हो सकती है, और ऐसे chips के नाम में W25R128FW की तरह R शामिल हो सकता है
  • update के अनुसार Shiny Quagsire ने XPS 13 और Surface Go 1 में grub-mod-setup_var से PchSetup variable modify करके xDCI enable किया था
    • उन devices में PchSetup variable protected नहीं था, इसलिए purely software approach संभव थी
  • दूसरे software approach के रूप में BIOS vulnerability का इस्तेमाल करके xDCI-related NVRAM variables बदलना, या boot के दौरान DMA से BIOS पर attack करके arbitrary code execute करना संभव हो सकता है
  • title में “secret” का मतलब जानबूझकर छिपाना नहीं, बल्कि undocumented feature बताने के ज्यादा करीब है

1 टिप्पणियां

 
GN⁺ 2024-02-24
Hacker News टिप्पणियाँ
  • मैं हमेशा सोचता रहा हूँ कि laptop को किसी दूसरे computer के लिए general-purpose keyboard और monitor की तरह इस्तेमाल करने की सुविधा आम क्यों नहीं है
    headless machine की maintenance के लिए नया keyboard और monitor खरीदना अजीब लगता है, क्योंकि laptop पहले से ही वह भूमिका निभा सकता है

    • GPD Pocket 3 में ठीक यही काम करने वाला KVM module है: यह HDMI और USB-C input लेता है और connected machine के display, keyboard और mouse की तरह काम करता है: https://gpd.hk/gpdpocket3
      जल्द आने वाले Minisforum V3 tablet में भी video input है, इसलिए उसे external monitor की तरह इस्तेमाल किया जा सकता है, लेकिन शायद keyboard और mouse share नहीं होंगे
      ऐसी सुविधा अगर और आम हो जाए तो सच में अच्छा होगा
    • सही। मेरे एक दोस्त ने सिर्फ इसी के लिए cyberdeck बनाया था
      mouse और keyboard को external port पर switch करके cable से किसी दूसरी machine से जोड़ा जा सकता है, और side में दो HDMI port हैं—एक output के लिए, एक input के लिए
      internal switch से यह चुना जा सकता है कि monitor source deck की अपनी machine हो या external input
    • headless machines से अक्सर काम करने वाले के रूप में, laptop को monitor की तरह इस्तेमाल करने का सबसे अच्छा उपाय मेरे लिए यह product था: https://www.amazon.com/dp/B0BJ2YDV7Q
      मूल रूप से यह एक chip है जो headless machine के HDMI signal को capture करके USB के जरिए laptop पर emulated webcam की तरह expose करता है, और electronics इतने छोटे हैं कि cable के अंदर फिट हो जाते हैं
      keyboard के लिए standard wireless keyboard के अलावा, और कभी-कभार mouse की जरूरत पड़े तो trackpad built-in वाला लेने के अलावा, मुझे कोई अच्छा समाधान नहीं मिला
    • यह बात हमेशा असुविधाजनक लगी कि एक computer को दूसरे computer से बस सीधे connect नहीं किया जा सकता
      सुना है USB 4 में एक mode है जो यह संभव बनाता है
    • hidclient का इस्तेमाल करने पर laptop Bluetooth keyboard और mouse होने का दिखावा कर सकता है
      https://web.archive.org/web/20180610141436/http://anselm.hoffmeister.be/computer/hidclient/index.html.en
      https://github.com/benizi/hidclient
  • कुछ साल पहले Travis Goodspeed ने जो काम किया था, उसका एक उदाहरण याद आता है
    smart TV सामान्य USB memory में मौजूद file से firmware update लेता था, और TV digital signature verify करने के लिए file को शुरू से अंत तक पढ़ता था, फिर update के लिए उसे दोबारा पढ़ता था
    अगर कोई device USB storage होने का दिखावा करे, तो पहली read में manufacturer firmware file भेज सकता है और दूसरी में unofficial firmware

    • बढ़िया। इस तरह की गलती का एक शानदार acronym है, TOCTOU (Time of Check to Time of Use), और यह चौंकाने वाली संख्या में जगहों पर मौजूद है
      https://en.m.wikipedia.org/wiki/Time-of-check_to_time-of-use
  • वाकई दिलचस्प। मैं इसी तरह के संभव विकल्पों की पड़ताल कर रहा था
    मेरे पास एक powerful NAS server है जिसके इस्तेमाल का बहाना मैं लगातार ढूँढ रहा हूँ, और घर में अलग-अलग जगहों पर 40G और 10G connections भी लगा रखे हैं
    PS5 और XBox extra storage के लिए USB hard disks इस्तेमाल करते हैं
    यह पता लगाया कि क्या NAS storage को PS5 और XBox पर expose किया जा सकता है, और यह संभव था। NAS share को iSCSI या NFS के रूप में mount करके, g_mass_storage module से USB storage device emulate कर उस storage को USB host पर expose करना होगा
    अभी समय और लागत के अलावा बड़ा अड़ंगा ऐसे system द्वारा मिलने वाली bandwidth है। upgrade उतना बड़ा नहीं है
    Raspberry Pi USB-OTG support के लिए मशहूर है, लेकिन USB 2.0 speed तक सीमित रहता है, और मैंने जिन इसी class के दूसरे SBCs को देखा उनमें भी ज्यादातर यही हालत थी। अपवाद RockPi4 था, और RockPi में gigabit Ethernet port है, इसलिए Ethernet को पूरी तरह भरने पर PS5 और Xbox दोनों को स्थिर HDD speed दे सकता है
    custom PCIe network card या express card लगाकर 1GbE से आगे जा सकने वाला समाधान बनाया जाए, तो USB 3.0 interface को सचमुच saturate किया जा सकता है, जो काफी दिलचस्प होगा

    • मेरे पास मिलता-जुलता homelab setup है, और https://www.virtualhere.com के साथ IP-based USB पर experiment कर रहा हूँ
      server से communicate करने के लिए client चाहिए होता है, लेकिन यह काफी अच्छा काम करता दिखता है
      मैं desk पर एक “thin USB client” रखने, USB devices को उससे जोड़ने, और फिर उन्हें lab के मनचाहे physical host या VM host से attach या switch करने की configuration सोच रहा हूँ
    • जानना चाहूँगा कि PS5 और NAS को physically कैसे connect किया जाएगा
      मेरा अंदाजा है NAS → SBC → PS5, या फिर NAS को USB cable से सीधे PS5 से connect करने की बात है?
      PS5 पर content playback कैसे होगा, यह भी जानना चाहूँगा। internal NVMe को खास speed satisfy करनी होती है, ऐसा समझता हूँ; क्या यह external drives पर लागू नहीं होता?
    • Raspberry Pi 5 में gigabit Ethernet port है, और FriendlyElec की NanoPi series जैसे दूसरे SBCs में भी यही है
      दरअसल NanoPi R6S में 1 gigabit port के अलावा दो 2.5G Ethernet ports हैं
  • इतने detailed लेख के लिए धन्यवाद। quality अच्छी है
    यह संभव था, इस बात से उम्मीद जगी है कि सिर्फ modified USB cable से बिना network वाला Synergy / Mouse Without Borders जैसा setup संभव हो सकता है
    जिन्हें एक साथ कई computers operate करने पड़ते हैं, उनके लिए यह बहुत अच्छी दिशा है

    • KVM switch मौजूद हैं, और video के बिना सिर्फ USB keyboard/mouse switch करने वाले devices भी हैं
      फिर भी आपका सुझाया तरीका दिलचस्प लगता है
  • हाल ही में मैंने कुछ ऐसा ही देखा था; मैं दो USB-C मशीनों को एक USB-C केबल से जोड़कर 10Gbps communication करना चाहता था
    अफसोस, ज़्यादातर Ryzen boards में अभी Thunderbolt नहीं है, और Thunderbolt हो तो यह इसे native तौर पर आसानी से support करता है
    “dual-role” USB controllers भी USB 3.2/4.0 से पहले काफी दुर्लभ थे, और जैसा इस लेख में बताया गया है, संभव होने पर भी कई बार support नहीं मिलता था
    Thunderbolt के बिना USB-C केबल से दो मशीनों को network में जोड़ना इतना मुश्किल है, यह पूरी तरह अजीब लगता है
    suspend के बाद lock bit clear होने वाला हिस्सा भी अच्छा था। ऐसी समस्याएँ सच में बहुत आम हैं। उदाहरण के लिए, SATA device को उस state से बाहर लाने में भी यही बहुत आम तरीका है जहाँ वह secure erase को रोक रहा होता है

  • गहराई वाकई प्रभावशाली स्तर की है
    PC को USB device की तरह इस्तेमाल कर पाना कई दिलचस्प संभावनाएँ खोल देता है
    यह थोड़ा अफसोस की बात है कि ज़रूरी xDCI option इस device के hardware में तो है, लेकिन expose नहीं किया गया है, और उस तक पहुँचने के लिए firmware hacking करनी पड़ती है
    यानी hardware सक्षम है, लेकिन manufacturer ने बस उसे बंद करके control feature lock कर दिया है

  • सोच रहा हूँ कि क्या Lenovo एक ThinkPad से दूसरे ThinkPad को debug करने के रास्ते के तौर पर इसका इस्तेमाल करता है
    https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/intel-debug-technology.html
    अपडेट: शायद हाँ
    https://www.youtube.com/watch?v=ExUvQa_jB7c
    यह Intel Firmware को DCI और USB 3.0 से debug करने वाला video है

  • “लेकिन Raspberry Pi से निपटना झंझट है: wires जोड़ना, board boot करना, shell में connect करना वगैरह” वाला हिस्सा शायद USB OTG set करके हल हो सकता था
    plug किए गए device से power लेने देना, shell चालू करना और फिर script से handle करना संभव रहा होगा
    तब SSH से mount settings या commands run किए जा सकते थे, और शायद device mount भी संभव होता
    फिर भी अपने device को समझने और kernel पढ़ने की कोशिश को मैं encourage करता हूँ। यह ऐसी चीज़ है जिसमें मैं लगातार बेहतर होना चाहता हूँ, और भावना यही है कि अपना hardware हम खुद ठीक करें

    • इस experiment का core ही USB OTG से जुड़ा है, और Pi में सिर्फ एक OTG port होता है, इसलिए connect करने के लिए कोई दूसरा तरीका चाहिए
      मैंने खुद करके देखा है
  • शुरुआती internet hacker culture की इतनी मजबूत याद दिलाता है कि nostalgia होने लगता है। सचमुच शानदार लेख है
    ESR जब hacker बनने की बात करते थे, Hacker News वाले अर्थ में hacker की बात करते थे, तो उनका मतलब इसी तरह के व्यक्ति से था
    जिज्ञासा, लगन और technical skill का यह मेल बेहद दुर्लभ और बहुत प्रभावशाली है

  • मेरे पास Celeron N3350/Pentium N4200/Atom E3900 based system है, और BIOS में xDCI switch expose है
    enable करने पर कुछ और options भी दिखते हैं, और Linux में boot करने पर PCI device USB controller: Intel Corporation Device 5aaa (rev 0b) दिखता है
    लेकिन UDC device node दिखाई नहीं देता। लगता है original post से hint लेकर थोड़ा और गहराई में देखना पड़ेगा