whitequark changed the topic of #glasgow to: glasgow debug tool · code https://github.com/GlasgowEmbedded/Glasgow · logs https://freenode.irclog.whitequark.org/glasgow
bgamari has quit [Ping timeout: 252 seconds]
bgamari has joined #glasgow
<sorear> revB: dim LEDs; added USB current limiter; level shifter series resistors // revC0: no more autosensing; LVDS and AUX ports; HX8K; serial#; user LEDs // revC1: dim LEDs; power filters; different voltage regulators; ESD diodes; SYNC 5V tolerance; pulls no longer use an I2C level shifter; Vio LEDs and discharge resistor
<sorear> the one thing that is different between every pair of board revs is the SYNC series resistor :)
<sorear> revA is more recognizable than I expected
<sorear> only just realized that the ESD diodes are all zeners
gsuberland has quit [Ping timeout: 245 seconds]
scott has quit [Ping timeout: 258 seconds]
scott has joined #glasgow
<marcan> sorear: they aren't zeners, they're TVS diodes
<marcan> which are similar (and use the same symbol) but not the same
jn___ has joined #glasgow
jn__ has quit [Ping timeout: 246 seconds]
futarisIRCcloud has joined #glasgow
oeuf has quit [Read error: Connection reset by peer]
oeuf has joined #glasgow
modrobert has quit [Ping timeout: 245 seconds]
modrobert has joined #glasgow
_whitelogger has joined #glasgow
mehar_ has joined #glasgow
mehar has quit [Ping timeout: 258 seconds]
m4ssi has joined #glasgow
<whitequark> serial# was there on revAB
_whitelogger has joined #glasgow
jn___ is now known as jn__
_whitelogger has joined #glasgow
emily has quit [Remote host closed the connection]
emily has joined #glasgow
<electronic_eel> whitequark: re pic programming - a lot of the prog algos require higher voltage on at least one pin to enter programming mode
<whitequark> um, yes, i've read some of those docs
<electronic_eel> so you'd need some high voltage addon for Glasgow
<whitequark> yeah, i'm thinking capacitive charge pump
<electronic_eel> unfortunately the pin for the hv isn't fixed
<whitequark> and a slow analog mux
<electronic_eel> so you can't make one addon with a zif socket
<electronic_eel> analog mux that allows more than 5v?
<electronic_eel> and voltage > it's vcc?
<whitequark> uh well, i can find maxim chips that can do that
<whitequark> cheap but no maxim
<electronic_eel> can you post a part no?
<whitequark> max14777
<electronic_eel> hmm, could work
<ali_as> Might be a dumb question, but can that be made safe? 12v glitches could fry some chips.
<electronic_eel> but I highly suggest charging a bigger cap and sensing the voltage with vsense than some fixed charge pump circuit
<whitequark> ali_as: possibly
<whitequark> i'm not sure what's the input buffer on MCLR like
<electronic_eel> but why not a regular stepup regulator to create the voltage
<electronic_eel> and then a dac controlling an opamp
<electronic_eel> then you can set any voltage you like for the output
<whitequark> it feels wrong to use a switcher to generate a few microamps of current
<electronic_eel> some OTP µcs require specific voltages
<whitequark> you'd probably have to load it to get the output stable
<electronic_eel> the switcher?
<whitequark> switching stepup regulator
<whitequark> or do you just mean use a charge pump with feedback
<ali_as> You could potentially just toggle a pin into a CW multiplier.
<electronic_eel> I mean a regular stepup regulator with inductance
<whitequark> so a switcher, yes
<electronic_eel> if it is not a completely cheap ass model than it will be stable without load
<ali_as> If you only need microamps.
<whitequark> well maybe
<electronic_eel> you like ti stuff, their stepups are stable without load
<electronic_eel> and even if it is not that stable, i suggest to use an opamp+dac for the actual output
<whitequark> ok
<electronic_eel> so the actual output is really stable and you have fine grained control
<whitequark> wtf, microchip
<ali_as> Why do you need that for say a 12v EEPROM erase?
<whitequark> the minimum MCLR voltage is 8V
<whitequark> and the absolute maximum is 9V
<electronic_eel> yeah, as I said, you need fine grained control
<whitequark> i guess in this case a regualtor with feedback makes sense
<electronic_eel> for these kind of µCs
<whitequark> do you wanna design this addon?
<electronic_eel> for the fun of it I've been playing with some 0.03 US$ microcontrollers
<electronic_eel> and here for a programmer hardware: https://github.com/free-pdk/easy-pdk-programmer-hardware
<whitequark> hmm, the programming process uses 1 mA on MCLR
<electronic_eel> these controllers require two higher voltages with fine grained control
<electronic_eel> see the schematics of the programmer hardware how it is done there
<electronic_eel> this is a circuit that would also work well with the pics
<electronic_eel> so I'd suggest something like it if you want a Glasgow addon
<electronic_eel> then it could also be used for these cheap Padauk µCs
<whitequark> is there any actual explanation of how the padauk protocol works?
<whitequark> the forums are mostly useless rants...
<electronic_eel> you'd have to read the whole thread, there is some useful info in there, but lot's of crap too
<electronic_eel> it's a forum after all..
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<electronic_eel> there is also pc software and stm32 firmware to implement the protocols:
<electronic_eel> unfortunately the author chose to code all that in c...
<whitequark> it's not a huge problem to reimplement programming algorithms ime
<electronic_eel> yes, not that difficult.
<electronic_eel> If we create a hv addon it would make sense to just have one and cover most applications with it
<electronic_eel> old eproms, pals, gals and the like often also need hv
<whitequark> true...
<whitequark> needs some kind of muxing though, maybe just a huge pfet array?
futarisIRCcloud has joined #glasgow
<whitequark> also the problem with old eproms, pals and gals is that they're all horribly parallel
<electronic_eel> perfect for a fpga
<whitequark> not perfect for our 16 pins
<electronic_eel> fair point
<electronic_eel> and we don't have 16 pins
<whitequark> and no FPGA can drive 5V pins on those devices anwyay
<electronic_eel> since we don't have a dedicated addon interface
<electronic_eel> we need something to control the addon
<whitequark> i'm thinking it should use a set of fast shift registers
<electronic_eel> ok, that could work
<electronic_eel> I haven't worked with these on a programming interface level
<whitequark> it's really annoying
<electronic_eel> what are the voltages on the data pins?
<whitequark> you can easily have 20 address bits
<whitequark> and they're all in random locations interspersed with strobes
<whitequark> usually 5V
<whitequark> there are some parallel 3V3 devices
<electronic_eel> so the high voltages and negative voltages and so on are only on special pins
<whitequark> yes
<electronic_eel> how should the addon work physically?
<whitequark> no idea
<whitequark> it's a really hard problem
<electronic_eel> pin headers and wires? or a zif socket
<whitequark> for something like a PIC it would be pin headers and wires since you want ICSP
<electronic_eel> zif socket means you need something to cater for different pinouts
<whitequark> well in circuit
<electronic_eel> hv in circuit?
<whitequark> sure
<whitequark> just don't connect MCLR to anything else
<electronic_eel> am I happy that I don't have to support something like that on the boards I design now...
<electronic_eel> maybe we should leave out eproms, pals and gals for the beginning
<electronic_eel> then we just need hv on dedicated pins and the user can connect these to his circuit
<whitequark> yep
<electronic_eel> whitequark: are you eager to do pic soon?
<electronic_eel> wouldn't it be better to start with the stuff that doesn't require addons?
<whitequark> well i wanted to do it like right now
<whitequark> pic has low voltage programming
<whitequark> on.. many? most? chips
<electronic_eel> I hate pics.
<electronic_eel> I thought you need hv on a lot of them
<whitequark> i utterly resent pics
<electronic_eel> I though just the newer series work without
<whitequark> shit architecture
<electronic_eel> then why not finish the avr stuff first (except hv of course)?
<whitequark> finish?
<electronic_eel> or do you have a bad day and want to complement it with a arch you resent?
<electronic_eel> I mean the rest of the avr protocols
<electronic_eel> updi, pdi,...
<whitequark> i have no intention of sitting down and implementing each avr protocol in series
<electronic_eel> ok
<whitequark> the avr spi protocol is done
<whitequark> but it needs a full database
<electronic_eel> can't you re-use the model table with the ids and so on from avrdude?
<whitequark> avrdude is GPLv2
<electronic_eel> ok, so you can't copy the table straight into glasgow
<whitequark> yes, it could be processed
<electronic_eel> but you could write a converter
<electronic_eel> it's not just about recreating the table once
<electronic_eel> it's also about maintaining it
<electronic_eel> there are new models released every few months, avrdude usually has them in their table after some short time
<electronic_eel> would be nice to not having to replicate this work again and again
<whitequark> i'm not really a fan of their database format
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<electronic_eel> maybe a converter + a patch to fix the known shortcomings?
<whitequark> it's the design
<electronic_eel> I understand
<electronic_eel> but do you really want to re-do all this work and maintain it over the years?
<whitequark> if i can't do it well i would rather not have it at all
<electronic_eel> I fully understand you
<whitequark> for example it is not really possible to use HVSP data from avrdude
<whitequark> since it is stk500-only
<electronic_eel> I'm lazy. And recreating this looks like tedious and work and not fun.
<electronic_eel> So I'd perfer to put lot's of effort into designing a nice importer/converter/whatever and a matching format
<whitequark> you can't do a nice importer for a format that's broken by design
<whitequark> what *is* possible is to parse their tables and *categorize* the microcontrollers according to the actual algorithm used
<whitequark> that would be very useful indeed
<electronic_eel> reading out the memory sections and their addresses & sizes should also be possible
<whitequark> sure
<whitequark> but i don't want each device to set up its own algorithm for reading out signature bytes
<whitequark> when chances are it's the same for every one of them
<electronic_eel> you mean you don't want the user to select a model on the commandline?
<whitequark> no, i mean i don't want a 14000 line database in glasgow for no other reason than someone being lazy
<electronic_eel> so you want to group the devices more intelligently than one big table
<whitequark> yup
<whitequark> and btw i just checked
<whitequark> the command for reading the signature is always identical but they have 3 or 4 ways to specify it in the database
<electronic_eel> but wouldn't some categorization script be possible to do that?
<whitequark> differing in indentation, spacing, and don't care bits
<electronic_eel> I mean from the avrdude table
<whitequark> sure
<whitequark> 13:05 <@whitequark> what *is* possible is to parse their tables and *categorize* the microcontrollers according to the actual algorithm used
<whitequark> that's what i was talking about
<whitequark> if you wrote that it'd be excellent
<whitequark> and yes, i don't think specifying the part number on the command line should be necessary
<electronic_eel> hmm. I'd prefer to work on the voltage protection board first
<electronic_eel> and there are also some projects of my own battling for my attention
<whitequark> sure
<whitequark> it's not like there's any rush
<electronic_eel> I'm still not sure if it isn't a better route to somehow integrate with avrdude than rewriting it
<electronic_eel> it isn't as elegant
<electronic_eel> or fast
<electronic_eel> but it would allow to use the development time to be used for implementing more interfaces to other stuff
<electronic_eel> but on the other hand all development is voluntary
<whitequark> i feel like maintaining the *avrdude* database is a huge waste of time
<whitequark> almost every single chip there has its own complete protocol definition
<whitequark> they seem to have caught on with xmega
<electronic_eel> I think their idea was to make it as flat as possible
<electronic_eel> and put as many stuff in their as possible
<whitequark> it's one of those things where months of maintenance save hours of planning
<electronic_eel> so that a user could add a new chip without having to change the code
<whitequark> it's not entirely bad
<whitequark> but it's seriously lacking in planning
<electronic_eel> probably it slowly grew over the years
<whitequark> yes
<whitequark> i understand well how these things happen
<whitequark> that's why i refuse to repeat them
<electronic_eel> without any review breaks and re-evaluation in between
emily has quit [Quit: Updating details, brb]
emily has joined #glasgow
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+2/-2/±1] https://git.io/fjnLn
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark eb54e9d - database.atmel→database.microchip
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjnLR
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark b569ce3 - applet.program.avr.spi: use SPI interface delays, not host delays.
carl0s has joined #glasgow
m4ssi has quit [Remote host closed the connection]
jevinskie has joined #glasgow
bgamari has quit [Ping timeout: 276 seconds]
bgamari has joined #glasgow
carl0s has quit [Ping timeout: 256 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
carl0s has joined #glasgow
ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow
carl0s has quit [Ping timeout: 256 seconds]
<_whitenotifier-3> [Glasgow] whitequark created branch wip-applet.program.pic.lv - https://git.io/fhhGp
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to wip-applet.program.pic.lv [+0/-0/±1] https://git.io/fjn3t
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 5d174d6 - gateware.clockgen: avoid spurious stb_r/stb_f pulses.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to wip-applet.program.pic.lv [+2/-0/±2] https://git.io/fjn3q
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark dc9eb08 - applet.program.pic.lv: WIP
<whitequark> marcan: electronic_eel: ^
<whitequark> well that answers the question of whether the clockgen change i made was sound
<electronic_eel> ok, so you really want to do pic
<electronic_eel> how many low voltage variants of the prog algo are there?
<electronic_eel> do you need something like the avr database?
<tnt> Does the swd applet allow some link to openocd or something ? I'm not sure how/if I can use it to flash fw on a target.
<whitequark> electronic_eel: 1) no more than 69 by the latest estimate, 2) yes
<whitequark> tnt: the swd applet doesn't work
<whitequark> you can't really do anything with it
<electronic_eel> 69 different low voltage algos?
<tnt> Oh, that's unfortunate.
<electronic_eel> are they totally crazy?
<whitequark> electronic_eel: there are 69 PDFs from Microchip i found describing programming algorithms
<whitequark> some of those are HV-only
<whitequark> some of those only differ in memory sizes and locations
<whitequark> so it's an upper bound
<whitequark> also, marcan found that pickit has 250 actual algorithms in it
<electronic_eel> I already said i hate pic. before knowing about that
<electronic_eel> they really do all they can to make this platform as ugly as possible
<whitequark> i mean
<whitequark> avr has the programming algorithm described invidiually in each pdf
<whitequark> but i think it actually *is* just 9 of them parameterized by memory sizes
<whitequark> at least, i've had no reason to think to contrary
<whitequark> also, atmel gave them different names
<whitequark> e.g. i've definitely seen PIC ICSP algorithms that differ as much as e.g. PDI vs UPDI
<whitequark> but they're just called ICSP
<electronic_eel> i think i understand why there is so few open source software for pics
<electronic_eel> everyone sane enough using open source keeps away from pic
<electronic_eel> one of the lead developers for sdcc worked on the Padauk stuff i mentioned
<whitequark> well the architecture is like that too
<electronic_eel> he said that there are a lot of people wanting to use sdcc for pic
<electronic_eel> but noone wants to touch the code and fix it
<electronic_eel> because it requires all kind of ugly quirks
<whitequark> oh yes, i have no intent of ever programming a pic
<whitequark> only reading them out
<electronic_eel> I just settled on buying one of these pickit clones for 7 bucks
<electronic_eel> i have it lieing around here somewhere should i ever need to read out a pic
<whitequark> marcan wants to extract the pickit database and figure out what the algorithms actually are
<whitequark> or something like that
<whitequark> ie what i suggested for arm
<electronic_eel> i think arm stuff is much more interesting
<whitequark> for avr*
<whitequark> arm is extremely easy
<electronic_eel> yes, but doing debugging *fast* isn't that easy
<whitequark> well i have some thoughts on it
<whitequark> the good thing is that debugging doesn't have to be fast to be useful
<electronic_eel> hmm, I beg to differ
<electronic_eel> if you need to single step over a lot of code
<electronic_eel> or want the debugger to watch some registers change and break on that
<electronic_eel> then a slow speed really annoys you
<electronic_eel> the commercial segger stuff is nice in this regard
<whitequark> ah yes, j-link
<whitequark> i tried to run it once and it immediately bricked itself
<electronic_eel> there are even more expensive ones available that claim to be even faster
<whitequark> because the distributor sold me a clone, apparently
<whitequark> i put it into trash.
<electronic_eel> i have one and it works really nice for debugging
<electronic_eel> but it is closed source
<electronic_eel> with all its downsides
<whitequark> my main interest in arm is flashing anyway
<whitequark> less so debugging
<whitequark> there will be a debugger, of course
<electronic_eel> flashing can be tricky too
<electronic_eel> because of all the different register dances you have to do for each model
<whitequark> sure
<whitequark> i worked on the original linux stlink tool
<electronic_eel> you mean the texane stuff?
<whitequark> i think it still uses my gdbserver
<whitequark> yes
<electronic_eel> i never liked the original stlink
<whitequark> i was annoyed one day a long time ago and wrote the gdbserver for it
<electronic_eel> because it keeps you away from what is actually happening
<whitequark> well that's what was on the discovery devboard
<whitequark> which i got for free
<electronic_eel> i reflashed it to black magic probe
<whitequark> bmp didn't exist then
<electronic_eel> yes, you are right, they came later
<electronic_eel> bmp is nice, but doesn't support such a large range of targets as openocd
<whitequark> bmp started in 2012
<whitequark> i wrote that gdbserver in 2011
<whitequark> anyway, openocd support for glasgow *has* to happen
<electronic_eel> I still used mostly avr back then
<electronic_eel> just began to play a bit with arm
<whitequark> yeah, same
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjns1
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 3 commits to master [+2/-1/±3] https://git.io/fjnsD
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark a4b5c4a - applet.debug.arm_swd: remove debug code.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark def16b7 - applet.debug.arm_swd: require revC0+.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 6b8eb1f - applet.debug.{arm_swd→arm.swd}
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/fjnsQ
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark a277290 - applet.display.pdi: unflag as preview.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark eb20d0a - applet.interface.spi_master: adapt to ClockGen changes in 5d174d6f.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to wip-applet.program.pic.lv [+2/-0/±2] https://git.io/fjns7
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 640e812 - applet.program.pic.lv: WIP
futarisIRCcloud has joined #glasgow
<whitequark> electronic_eel: also thinking out loud re: chip support
<whitequark> devices like BMP are still quite successful even if they don't support the entire lineup of one developer's ICs
<electronic_eel> yes
<electronic_eel> but takes quite a lot of maintenance to add & test all the new ics
<electronic_eel> bmp doesn't have many developers
<whitequark> sure
<electronic_eel> and it shows, there is quite a backlog of patches
<electronic_eel> openocd has quite a wide range of supported interfaces
<electronic_eel> so i guess their internal interface isn't that bad
<whitequark> a backlog of patches isn't necessarily representative
<whitequark> most patches made by people for tools are quite bad, because most people are, thankfully, not toolmakers
<whitequark> e.g. solvespace suffers from it badly
<electronic_eel> fair point
<whitequark> i somewhat dread general availability of glasgow because such patches are my worst nightmare
<whitequark> i expect to spend a lot of time writing guidelines and best practices
<electronic_eel> but still there is some influx of patches and if the project wants to appeal to a wide audience, it has to deal somehow with it
<whitequark> for example, compare the situation to yosys
<whitequark> yosys has quite a few people behind it that are very active
<whitequark> yet there is a backlog of PRs that are incomplete, not up to standard or just kind of incoherent
<electronic_eel> and i don't know if it is best to use these developer resources with handling this id of that new ic
<whitequark> adding this id of that new ic is not hard at all.
<electronic_eel> if we get an interface into openocd to work, most of this is handled by openocd
<whitequark> well, it should not be hard.
<electronic_eel> and everyone else using openocd will also profit from it
<whitequark> except now all the programming algorithms are trapped in gplv2-land
<whitequark> and databases
<sorear> seems like the exciting stuff is the part where we don't collectively know yet if it's in scope
<electronic_eel> don't underestimate it, it's not just the ids, but some individual quirks needed
<whitequark> i am well aware
<whitequark> i implemented mips ejtag support, for example
<electronic_eel> is gplv2 that bad?
<whitequark> i'm opposed to all intellectual property
<whitequark> and gpl can't exist without it
<whitequark> so yes
<whitequark> that's enough reason for me to reimplement algorithms
<electronic_eel> if there were no ip, gpl wouldn't have to be invented
<whitequark> gpl was invented because one guy got really pissed off
<whitequark> everything else is mostly coincidental
nrossi has quit [*.net *.split]
StM has quit [*.net *.split]
<electronic_eel> i mostly care if the stuff is open source or not
<electronic_eel> true open source, not some shit like agpl
<whitequark> well, i consider anything short of public domain "not true open source"
<electronic_eel> if it is that is good enough for me
<whitequark> to make an analogy
<whitequark> of course, i still use, contribute to, and maintain gpl'd projects. i also run nvidia's blob
<whitequark> that doesn't mean i will willingly make things worse when i have a good option not to
<electronic_eel> i just run intel me and hate that i have to do it
<whitequark> intel me is shit but like
<whitequark> linux already falls over if anyone fuzzes it for five miuntes
<electronic_eel> on which interface?
<whitequark> we have a long way before intel me becomes a more accessible target than all the other junk i run on this system
<electronic_eel> usb drivers?
<whitequark> anything that parses untrusted input in c tends to fall over regularly
<whitequark> i mean linux broadly
<whitequark> as in "this debian desktop"
<electronic_eel> ok, so not the kernel, but whole desktop. yeah
<sorear> i will never understand the philosophy that believes an infinite amount of IP is fine, as long as it's not software you have to handle
<whitequark> i'm completely certain the wifi firmware is remotely exploitable and i also know for sure the current gen iommu linux drivers wouldn't prevent anything
Stary has quit [*.net *.split]
<sorear> secret sauce in silicon? great. microcode in ROM? great. microcode updates in /lib/firmware? Suddenly I Mind
<electronic_eel> iommu is not worth much unfortunately
<whitequark> sorear: i mean, FSF is *also* incoherent but that's kind of a given
<electronic_eel> that is why i think this whole thunderbolt thing is immature
<whitequark> electronic_eel: i think thunderbolt is excellent
<whitequark> well, other than the 98% of it that is shit
<whitequark> but when it works and if i pretend i don't know how it works, it's excellent
<electronic_eel> giving remote dma to some external device?
<whitequark> yes
<whitequark> i specifically want that
<electronic_eel> but then iommu has to be really really really good
<electronic_eel> and it isn't
<whitequark> there's no meaningful protection from malicious devices in today's desktop architecture
<whitequark> consider this
<whitequark> a far easier and more reliable way to do a malicious device thing is to make a HID thing that installs a keylogger on your machine
<whitequark> or just exploit autorun bugs in systemd or whatever
<electronic_eel> not when my machine is locked, that is what i mostly care about
<whitequark> wait
<whitequark> do you think thunderbolt blindly grands dma to anything that's plugged in?
<electronic_eel> if some driver is loaded i guess
<whitequark> nope
<whitequark> i mean, you could set it up like that if you wanted, but by default it's a device whitelist and a challenge-response auth mechanism
<whitequark> (so it's even replay-safe, in theory at least; i don't know if it's horribly broken in reality)
<electronic_eel> do you need to ack plugging in any device?
<whitequark> by default, yes
<electronic_eel> only the first time or always?
<whitequark> however your OS does it
<whitequark> there's three modes
<whitequark> "instantly set up anything that's plugged in", "ask the user", "ask the user first time and pair devices"
<whitequark> the OS can select between those and you can also configure it in the firmware
<electronic_eel> how good is the pairing stuff done?
<whitequark> because if the former one is selected the firmware will enumerate whatever's on the other side of the bus and *run option ROMs off it*
<whitequark> none of the thunderbolt guts are public currently
<whitequark> (i'm also not a cryptographer)
<whitequark> i only know it uses some kind of crypto and challenge response auth
<electronic_eel> ok, so then there is probably a lot of holes in it
<electronic_eel> like plugging in a man-in-the-middle between your paired device and the pc
<whitequark> good luck making that work
<electronic_eel> most crypto stuff that is developed behind closed doors is leaky as a sieve
<whitequark> no i just mean implementing thunderbolt is a nightmare
<electronic_eel> currently, because its all closed intel chipsets
<electronic_eel> but once it becomes usb 4 and open
<whitequark> here's the thing
<electronic_eel> wait a few years and you get all kinds of interfaces
<whitequark> you can fuzz usb drivers in linux right now and
<whitequark> i mean
<whitequark> if you're developing an usb device it's harder to *not* crash the host stack sometimes
<whitequark> and it's not like that's gonna change
<whitequark> what we need is to stop treating correctness like an afterthought and once you have that, getting iommu to work properly is straightforward
<whitequark> because you're already not putting pointers into device-writable memory
<electronic_eel> i better go back to the board i was soldering, won't get anywhere with it today otherwise
<whitequark> oh btw
<whitequark> i've never heard anyone complain like this about expresscard
<whitequark> even though it was far easier to exploit
<electronic_eel> was a non-starter, nobody needed it
<whitequark> oh?
<electronic_eel> so you could easily epoxy it closed
<whitequark> that's a nonsequitur
<electronic_eel> can't do that with usb
<whitequark> you can just turn off thunderbolt
<electronic_eel> not if there are lots of devices that need it
<electronic_eel> or are designed with the premise that you can use it
<whitequark> so what does thunderbolt make worse over usb exactly
<electronic_eel> once you get around the iommu, which isn't that hard today, you have the whole ram
<electronic_eel> with usb you need to find a vulnerable driver and write an exploit
<whitequark> so
<whitequark> what's the problem with never enumerating new thunderbolt devices when the screen is locked
<electronic_eel> and the driver is easily fixed, iommu hardware is only fixed in >3 years in next gen
<whitequark> since if the screen is unlocked the solution is to use a fake HID
<whitequark> actually fake Ethernet still gives you a lot even with a locked screen
carl0s has joined #glasgow
<electronic_eel> yeah, a lot of distros do auto dhcp
<electronic_eel> that is really bad practice
<whitequark> also, if you use most x11 screen lockers they are bypassable with user input
<whitequark> so it's more like step 0: move to wayland
<electronic_eel> bypassable?
<whitequark> yes
<whitequark> x11 doesn't have the concept of a screen locker
nrossi has joined #glasgow
<whitequark> so it's a program that just tries to grab the display really hard, usually using some complex toolkit
<whitequark> this pretty much always fails in some stupid way
<whitequark> e.g. i remember a bug where you could type a password, ctrlc, ctrlv, repeat several times
<whitequark> it crashed with OOM
<whitequark> screen lock gone
JJJollyjim has joined #glasgow
JJJollyjim has joined #glasgow
JJJollyjim has quit [Ping timeout: 250 seconds]
<whitequark> often you have some things like assistive technologies interfering with focus grabs
<whitequark> or menus
StM has joined #glasgow
<whitequark> or some keybinding someone forgot to sanitize
Stary has joined #glasgow
<electronic_eel> just killed my screen locker
<electronic_eel> it was automatically restarted and re-locked
<electronic_eel> kscreenlocker
JJJollyjim is now known as Guest96158
<whitequark> do that but get a popup menu while it's crashed
<whitequark> there has been a race condition in the past
<whitequark> since only one application can do focus grab at a time
<whitequark> what i'm saying is, yes they fix those bugs, no the x11 screen locking is broken by design
<whitequark> it's like writing kernels in c
<whitequark> don't do it
<electronic_eel> yes, i understand
<sorear> does wayland let you switch vts or use magic sysrq while locked
<electronic_eel> but wayland is just missing lot's of stuff users are accustomed to
<whitequark> magic sysrq is disabled on default on many distros these days
<whitequark> which is fucking obnoxious
<electronic_eel> won't take the world by storm this way
<whitequark> your piece of shit kernel can't deal with OOM, i *need* alt+sysrq+k
<whitequark> as for switch vts, i thought that's a kernel thing?
<sorear> you must mean something I'm not quite understanding because they're both kernel things as I use the term
<sorear> the kernel reacts to at least two classes of user input (VT switch sequences, magic sysrq) before userspace sees them
<whitequark> yes
<whitequark> magic sysrq is disabled by default though
<whitequark> it might've been an upstream change?
<sorear> there's a sysctl to disable sysrq at runtime, and an ioctl for intercepting VT switching*, so theoretically wayland could make this work, but it's not "correct by design" and it'll break the next time linux adds a new magic key
<sorear> *this part of my knowledge hasn't really been updated to reflect drm/kms, it's _really_ dated
<sorear> xfree86 circa 2003 was cursed as hell
<sorear> I'd like to be able to use magic sysrq while logged in, but have it do nothing while locked, do you follow my desire?
<whitequark> sorear: i mean, "kernel adding new magic keys" is outside the threat model of a display manager
<whitequark> if you want things like disabling usb/thunderbolt enumeration the kernel has to explicitly cooperate
<whitequark> this rules out scenarios where the kernel is oblivious or malicious
<whitequark> anyway
<whitequark> that's reasonable, yes
carl0s has quit [Ping timeout: 256 seconds]