<openfpga-github>
Glasgow/master e52160d whitequark: Leave only ADC on Vsense, and connect LDO and FXMA both to Vio.
<awygle>
whitequark: the pins on the FXMA108 have the wrong names >_<
<awygle>
the part counts 0-7 not 1-8
<awygle>
no functional change but dammit i fucked up again lol
digshadow has quit [Ping timeout: 268 seconds]
<whitequark>
ha, I missed this because I was looking at net names, not pin names
pie__ has quit [Ping timeout: 264 seconds]
digshadow has joined ##openfpga
eightdot_ has joined ##openfpga
noobineer has joined ##openfpga
eightdot has quit [Ping timeout: 260 seconds]
<awygle>
whitequark: i think the voltage divider on the LM3880 is not ideal
<whitequark>
awygle: what should it be?
<awygle>
currently it divides 4.8 to 1.2, but the maximum enable threshold is 1.4. it should be a 220k on the top
<awygle>
(or smaller)
<whitequark>
oh
<awygle>
220k gives you 4.5 to 1.4
<awygle>
so min 5V to max EN
<whitequark>
yup sounds good
<awygle>
azonenberg: "Shunt resistors on regulators after, not before, HF output caps" what is the purpose of this rule? specifically, why do you have shunt resistors? or is this just "if you have them put them after the caps"?
<awygle>
whitequark: how do we program the cypress firmware the first time? through the I2C test points?
<whitequark>
awygle: cypress has an usb bootloader
<awygle>
ah, in mask rom or something?
<awygle>
sweet
<whitequark>
well, no
<whitequark>
it's not even in firmware
<whitequark>
if it receives a bRequest==0xA0 it reads or writes RAM
<awygle>
huh
<awygle>
weird
<awygle>
but cool
<whitequark>
so you can put your own code there and then start the CPU by poking a register that has the CPU stop ibt
<whitequark>
in fact
<whitequark>
they use the exact same mechanism for loading from I2C
<awygle>
azonenberg: "Reference resistors correct value and reference rail" what does this mean?
<whitequark>
it's a series of commands "put what where" that ends up with poking the same register
<awygle>
ah, that's fairly elegant
<whitequark>
yeah kinda
<whitequark>
also means it's unbrickable
<whitequark>
the reason I put CYP_MEM on the right is if you ever fuck up the EEPROM, you short pins 1 and 2
<whitequark>
that changes its address, CY7C can't find it anymore, comes up as a generic usb device
<openfpga-github>
Glasgow/master 8190114 Andrew Wygle: DFM tweaks to MSOP paste and thermal vias.
<awygle>
there we go
<whitequark>
oh that's pretty cool
<awygle>
whitequark: i tweaked the paste on the MSOP thermal pad (the paste was right over the vias which is a big no no). i kind of freehanded it a little bit so maybe take a look. i also tented all the thermal vias on the backside. the first will go into the footprint.
<whitequark>
aha thanks I was wondering about that
<whitequark>
so
<whitequark>
let me export gerbers, run them past you, and send to the fab?
<rqou>
awygle: why does your ADC need a capacitor?
<rqou>
(also whitequark i guess?)
<whitequark>
it's a SAR ADC
<whitequark>
and the internal hold capacitor is not enough
<rqou>
not enough? isn't it measuring a dc voltage?
<whitequark>
well, no.
<whitequark>
it continuously samples to raise an alert in case of over/undervoltage
<whitequark>
we're doing it at 1ksps
<rqou>
huh, i can't actually find any document that uses the letter gamma like that
<rqou>
where does that come from?
<rqou>
ah, i see your notation matches TI's SPNA088
<rqou>
whitequark: except you do realize that your chosen ADC has a Csamp of 30 pF right? not 20 pF
<whitequark>
rqou: hm
<rqou>
although tbh i think it'll "work" anyways
<rqou>
the appnote says that you can have poor response time or channel-to-channel crosstalk
<rqou>
but neither of those matter all that much for just an under/overvoltage
<rqou>
also whitequark: "仿欧洲高档机箱" is literally "imitation european high-end machine box (chassis)"
<whitequark>
so it does in fact say "imitation"
<rqou>
which sounds like a typical term of art that got awkwardly translated into chinese
<whitequark>
imitation eurorack
<whitequark>
is that like imitation crab meat
<rqou>
except i don't know what that specifically means :P
<rqou>
if you have a specific type of product you're looking for, maybe i can ask my father what it would be called?
<whitequark>
eurorack.
<whitequark>
specifically a subrack.
<whitequark>
though cheap fullwidth racks are also good.
<whitequark>
rqou: yeah it actually looks like it's literally an imitation eurorack
<whitequark>
looks like one from outside but doesn't have any of the mounting features
<rqou>
ah lol
<rqou>
btw, how fast is dirtypcbs?
<whitequark>
well they already put my order into production
<whitequark>
that was... 25 minutes
<rqou>
wow
<rqou>
and shipping?
<rqou>
also, do they _only_ do up to 10cm x 10cm?
<whitequark>
SF Express delivers in 2-3 days
<whitequark>
but you have to ask, they don't have the option for some reason
<rqou>
also hmm, if you're not doing a "standard" size it suddenly costs $$$
<whitequark>
it would be very funny if Mouser delivers components after I get the PCB
<whitequark>
yes, if you're not doing a protopack it's much more expensive
<rqou>
ok
<whitequark>
but still pretty cheap
<rqou>
not clearly better than OSHPark after weighing all options
<whitequark>
well oshpark doesn't deliver in 2-3 days
<rqou>
true
<rqou>
they've got a 5 day service
<whitequark>
that is very expensive though
<whitequark>
also, dirtypcbs does stencils and laser cutting too
<rqou>
yeah, but quick turn is always expensive
<rqou>
hmm, 6/6 because 5/5 yields were bad lol
<rqou>
hmm, specs are "okay" overall
<rqou>
> not PB free unless special request
<rqou>
lol
<whitequark>
it's a cut-rate chinese fab what do you expect
<rqou>
yeah true
<rqou>
> Hong Kong Post takes 1 to 8+ weeks
<rqou>
lolol
pie__ has joined ##openfpga
<whitequark>
CYA
q3k has quit [Read error: Connection reset by peer]
<rqou>
> Readme.txt & special instructions
<rqou>
> Get the hell out of here. We are an automated conduit to cheap local Chinese fabs. We don't read squat, and at these prices you'd be insane to think we do! Nobody at the board house even speaks English! You need a much more expensive board house if you need this level of service.
<rqou>
i kinda like these guys :P
<rqou>
damn i need to move to china :P
q3k has joined ##openfpga
<whitequark>
lol
<rqou>
ooh, this is done by the dangerous prototypes people
<rqou>
and they're actually physically in china (i guess they kinda have to be in order to make anything like this work)
<whitequark>
yep
* rqou
really needs to move to china and brush up on my chinese
rohitksingh has joined ##openfpga
<rqou>
> Our Chinese company is owned by a Hong Kong company. This is how all the kids do it these days.
<rqou>
whitequark: why doesn't m-labs have this yet? :P
<whitequark>
ENOTIME
<rqou>
aah, this page is also the page where you found the comment about smuggling cash across the border
<rqou>
wait what
<rqou>
whitequark: dirtypcbs exposes everybody who orders from them on twitter?
eduardo has joined ##openfpga
wolfspraul has quit [Quit: leaving]
wolfspraul has joined ##openfpga
<whitequark>
rqou: no
<whitequark>
only those who tick the checkbox
<rqou>
ah ok
<rqou>
still feels like a rather strange feature
<gruetzkopf>
most people get notified of tweets faster than emails
<gruetzkopf>
(not me, email-receive-notify latency is somewhere below 1s, depending on phon reception;)
<rqou>
nah, i'm just used to "electronics/hardware/EDA/etc. people" to be totally clueless about "this social media stuff"
<whitequark>
i actually get emails simultaneously with tweets
<whitequark>
but i can't retweet emails
rohitksingh has quit [Quit: Leaving.]
<azonenberg>
awygle: the shunt resistor thing is saying, if you have one to measure current
<azonenberg>
put the cap closer to the reg than the resistor to minimize ESR in the loop
<azonenberg>
awygle: for reference resistors i'm talking about like ft232's 12K rbias to ground
<azonenberg>
just reminding yo to make sure it actually goes to ground and not something else
rohitksingh_work has joined ##openfpga
<rqou>
azonenberg: do you not turn PCBs into dead tree assembly drawings? (see backlog)
<azonenberg>
rqou: no, i do not
<azonenberg>
I normally have pcbnew open on my laptop as i assemble
<rqou>
ah, so you don't care about Fab layers
<azonenberg>
If i have a part that's not labeled on silk i just double-click the part and see the refdes
<rqou>
hrm, it's really starting to seem like i need to do my own footprints to get what I want
<azonenberg>
lol
<rqou>
i like how yours are board-proven to a high standard but there are some things that i really want done differently
<azonenberg>
right now most of mine are manufacturer reference designs pretty much
<azonenberg>
i want to make at least all 3 IPC footprint densities for passives eventually
<rqou>
but you e.g. don't use IPC's dumb pin 1 marks
<rqou>
or huuuuge courtyards
<azonenberg>
Correct, i jsut mean in terms of pad sizes
<azonenberg>
i *hate* the new ipc pin 1 markers
<rqou>
huge courtyards are dumb too
<azonenberg>
If i can assemble the board a pnp should have no trouble
<rqou>
in general i don't particularly like any of the IPC silkscreen at all
<azonenberg>
yeah
<azonenberg>
My component-level silk is intended to be used as a quick reference during manual assembly
<rqou>
imho the IPC silkscreen is just ugly
<azonenberg>
It is
<rqou>
somehow feels very "bureaucratic and Euro-style" to me
<azonenberg>
lol
<rqou>
btw, i wonder if you can ID which EDA tool was used to design a board
<azonenberg>
very likely, there are some pretty distinctive features of fonts etc
<azonenberg>
As well as stock footprints
<rqou>
oh right fonts
<rqou>
not just footprints
<rqou>
i wonder if you can reliability identify designers
<azonenberg>
If they don't leave a signature on the board like i usually do? lol
<azonenberg>
possible, if you have some hints to narrow the field
<azonenberg>
i have certain components i like using for certain purposes
<azonenberg>
like, if you see an altera fpga on a board it's almost certainly not my design
<azonenberg>
or a broadcom/marvell phy
<azonenberg>
if you see a big xilinx part, a KSZ9031, and a LTC3374 the odds are much higher
<gruetzkopf>
i had a lot of intel stuff with names silkscreened under the TQFPs ;)
<azonenberg>
"this was not a user-serviceable part"?
<azonenberg>
:p
<gruetzkopf>
hehe
<azonenberg>
Also speaking of footprints
<azonenberg>
i am thinking of going with a pin 1 marker, in the future, that i saw on a customer board a while ago
<azonenberg>
a little V-shape near pin 1
<azonenberg>
for ICs/connectors that is
<azonenberg>
it's slightly larger and more visible than the dot i've been using
<azonenberg>
I generally do not use silk on non-polarized passives at all, since there's no point
<azonenberg>
For polarized ones i use a single line on the outside of the part on the negative side
<azonenberg>
Which is pretty close to IPC iirc
<gruetzkopf>
i'm a big fan of actually numbering pins in intervals of 10 or 20
<azonenberg>
gruetzkopf: I do that on my Q-strip connector footprint
<azonenberg>
at the end of each block
<azonenberg>
but not on ICs
<gruetzkopf>
yes
<azonenberg>
Since i generally do fairly high density deisgns i dont want a lot of silk cluttering things
<azonenberg>
my silk is there as a sanity check on polarized parts during assembly, and for labels intended to be read by the end user (board rev, connector names, etc)
rohitksingh has quit [Remote host closed the connection]
<kc8apf>
awygle: I finally have a graph transform design for gaffe that I'm OK with. I've reimplemented xc7 bitstream packet parsing and should have config frame parsing by end-of-day.
<azonenberg>
kc8apf: :D
<rqou>
azonenberg: i just had a thought: can you program an XC2C32A sram only? without programming flash?
<azonenberg>
yes
<azonenberg>
ISC_ENABLE_OTF
<azonenberg>
i dont think jtaghal supports it right now, at least not fully
<rqou>
do you have to send the entire bitstream every time?
<azonenberg>
iirc you can also program the flash without disturbing the sram design
<rqou>
or can you just patch specific rows?
<azonenberg>
So, you're thinking partial reconfiguration?
<rqou>
pretty much
<azonenberg>
I actually have a test case for this in the antikernel repo somewhere
<azonenberg>
It was inconsistent
<azonenberg>
Sometimes worked, sometimes didn't
<azonenberg>
and i didnt have time to debug
<azonenberg>
unsure if bug in my code or silicon issue
<azonenberg>
But at least some of the time, it does work
<rqou>
hmm
<rqou>
but sending everything always works?
<azonenberg>
As far as i can tell, yes
<azonenberg>
i didnt play with it a ton though
<azonenberg>
so dont read too mcuh into it
<azonenberg>
other than, it at least kinda works
<azonenberg>
and might be possible to make reliable
<azonenberg>
I dont remember the problems either, i think it had to do with inconsistent reset of macrocell ff's etc
<azonenberg>
the side effects of the boot process are not super well understood
<azonenberg>
as far as when it does resets and when it doesnt
<azonenberg>
i want to do a config memory write with the design paused (to prevent glitching) but not wipe ff state
<awygle>
kc8apf: great! I have at least three things to deal with before I can spend serious time on that but I'll definitely take a look :-)
<kc8apf>
I know spartan3 and later use a command sequence to disable the interconnect and hold IO state during partial reconfig.
<kc8apf>
I haven't looked to see if that existed for xc2
<azonenberg>
xc2c was not intended to be reconfigured :p
<rqou>
well, xc2 isn't designed for reconfig at all, so
<azonenberg>
this is very much an abuse of the system
<azonenberg>
There is a line to disable the interconnect during boot
<azonenberg>
but i dont know if it can be asserted independently of global reset
<kc8apf>
the same mechanisms are used for full-device reprogramming on xc3 and later
<azonenberg>
i haven't traced it from the core to the macrocell
<rqou>
yeah, idk if ise/impact can do sram-only programming
<kc8apf>
Pretty sure it was learned by doing experiments on xc2
<azonenberg>
kc8apf: well keep in mind
<azonenberg>
xc2c and xc2s are completely different architectures
<azonenberg>
so don't use xc2 to imply one generation of parts
<kc8apf>
rqou: why should ise/impact support limit us?
<rqou>
azonenberg: idcode reflash and readback bypass when? :P
<azonenberg>
rqou: i never got around to testing the "full erase" command
<rqou>
kc8apf: it doesn't, but it shows what's well-tested and what isn't
<kc8apf>
azonenberg: yes. need include letters in those prefixes
<azonenberg>
i should
<rqou>
azonenberg: stm32 full pwn when? :P
<rqou>
azonenberg: your friggin house done when? :P
<azonenberg>
rqou: hey, any time you want to come up from the bay area and spend a weekend doing construction
<azonenberg>
i wont say no :p
<rqou>
so azonenberg, if construction takes X days hiring Y people, will it take X/N days if you hire Y*N people? :P
<rqou>
can 9 women produce one baby in 1 month? :P :P :P
digshadow has left ##openfpga [##openfpga]
digshadow has joined ##openfpga
<azonenberg>
rqou: if you pipeline, yes
<azonenberg>
:p
<rqou>
lol
<rqou>
no pipelining allowed, only death marches :P
<awygle>
That only works if you need at least 9 babies though
<azonenberg>
awygle: hey, do you want throughput or latency? :p
<awygle>
azonenberg: latency, waaay more often than software devs think
<azonenberg>
lol
<azonenberg>
speaking of latency
<azonenberg>
did you see the gnome-calculator bug i tweeted last night?
<awygle>
Yep
<azonenberg>
typing even somewhat fast reliably triggers it
<azonenberg>
rqou: anyway, right now the limiting factor is that I have neither the time to do the work myself nor the money to pay someone else to :p
<rqou>
solution: don't be a super-human :P
<azonenberg>
So i spend a few hours a day after work on it and hope it gets done eventually
<rqou>
(re typing too fast)
<rqou>
btw, iirc macos/ios has the same bug in their calculator
<azonenberg>
how hard is it to make an app that can keep up with typing?
<rqou>
apparently very
<azonenberg>
this is a multi-GHz CPU and i type at maybe 10 Hz absolute worst case
<azonenberg>
realistically a lot less than that, low to mid single digits
<kc8apf>
azonenberg: did you find info on how xc2c bitstreams are loaded over jtag? Everything I find says "play this svf" or "use impact".
<azonenberg>
rqou: i've read that
<azonenberg>
kc8apf: yes
<azonenberg>
the xc2c programmer qualification spec has full details
<rqou>
we've always had that info
<azonenberg>
probably not intended to be public but the pdf was at one point on the xilinx website
<rqou>
ironically we don't have it for 9500(xl)
<azonenberg>
i think its down now but there are mirrors floating around
<kc8apf>
aha
<azonenberg>
kc8apf: tl;dr you do one jtag scan for each of the rows of the memory in physical bit order
<rqou>
the programmer qualification doc for 9500(xl) describes a totally different and obscure high voltage programming mode
<azonenberg>
the fun part is that the jed file is in logical bit order
<azonenberg>
And you have to remap
<azonenberg>
There are human readable ascii text files, tab-separated value format iirc, in the ise install directory that specify the mappin
<azonenberg>
i derived a procedural version of the mapping for the 32a to avoid needing to redistribute those files
<azonenberg>
it's smaller than the ascii file and is faster to execute than parsing it :p
<kc8apf>
"address is indexed with a Gray code count starting from zero and counting sequentially up to a maximum Gray code value"
<kc8apf>
yeah, glad that part is done
<rqou>
although my tool actually doesn't support this yet
<azonenberg>
kc8apf: basically what's left to finish xc2c support for larger devices is figuring out a few tidbits of macrocell configuration
<azonenberg>
and the routing matrix for larger parts
<azonenberg>
the 2c64a should be a straightforward "image the m3-m4 vias" pass
<kc8apf>
I'm catching up on the details
<azonenberg>
The larger ones have a more complex structure that seems like multiple levels of muxes
<rqou>
er, we have all the relevant bits of macrocell configuration already
<azonenberg>
that last i checked is not fully understood
<azonenberg>
rqou: oh ok
<azonenberg>
so it's just routing
<rqou>
the mux config is also available because i blackboxed it from ISE
<azonenberg>
kc8apf: have you read my doc on the bitstream format?
<rqou>
it's definitely a mux tree
<azonenberg>
rqou: yeah but i really want a clean origin for that data
<kc8apf>
nope. I found your slides.
<azonenberg>
kc8apf: the recon talk?
<azonenberg>
that was before me and rqou figured out all the rest
<kc8apf>
I'm less interested in the bitstream format itself right now. More in the programming protocol
<rqou>
imho this is clean enough for the mux tree part
<rqou>
the hardwired part is still missing
<kc8apf>
trying to understand how they evolved programming through generations
<azonenberg>
kc8apf: look at XilinxCoolRunner2Device.cpp in azonenberg/jtaghal
<kc8apf>
yeah, recon talk
<rqou>
kc8apf: note that this architecture came from Phillips
<azonenberg>
Also, re bitstream format. azonenberg/openfpga/doc/coolrunner/xc2c32a-notes.txt
<kc8apf>
yup
<rqou>
it's not a Xilinx original design
<azonenberg>
rqou: coolrunner xpla3 perhaps
<azonenberg>
but xc2c has xilinx mask art on the die
<rqou>
ok
<rqou>
i meant if you trace back far enough
<azonenberg>
actually...
<azonenberg>
XCR3064XL has xilinx mask art on the die too
<azonenberg>
interestnig
<azonenberg>
i doubt they'd edit the mask post tapeout just to change the company logo
<rqou>
azonenberg: anyways, the mux tree part for larger devices is already in released code
<azonenberg>
Which makes me wonder if they bought the IP from philips before it hit production?
<rqou>
only the via-programmed data is stubbed out
<rqou>
azonenberg: there seem to be XPLA2/XPLA that have now been memoryholed
<rqou>
i think _those_ are the phillips parts
<azonenberg>
ah, ok
<azonenberg>
i havent seen any of those but would love to get my hands on one if you can find one
<rqou>
anyways, another missing thing for larger parts is understanding various kinds of UB
<rqou>
actually this is true for all parts
<azonenberg>
ultra beast? :p
<azonenberg>
undefined behavior?
<rqou>
also _exactly_ how global nets are hooked up
<rqou>
undefined behavior
<azonenberg>
well maybe once i get my new lab set up
<azonenberg>
i can spend more time on it
<azonenberg>
waaay too busy right now
<kc8apf>
ok, this is fairly similar
<azonenberg>
kc8apf: similar to what?
<kc8apf>
main difference is using JTAG opcodes directly instead of using it as an interface to a programming port
<rqou>
at some point we need to quickly test things like "if you feed an internal signal into a BUFG, can you set the corresponding io pad to be open-drain? does this wire-and the external and internal signals before feeding the BUFG"
<kc8apf>
xc6, xc7
<kc8apf>
and xc3
<azonenberg>
eh, not exactly
<kc8apf>
the bitstream is totally different but I see how they evolved the programming sequence
<azonenberg>
kinda-sorta?
<azonenberg>
i dont think this is a direct ancestor
<azonenberg>
this is a low level programming algorithm where you directly poke hardware state and address registers etc
<kc8apf>
thats more or less how later protocols work as well
<azonenberg>
i mean with fpgas, from xc3 and up (i havent looked at xc2s/xc2v and older) you can see the whole config state machine is very clearly related
<azonenberg>
And the whole concept of just spamming data to CFG_IN that contains packetized data, etc
<azonenberg>
its a much more complex protocol
<kc8apf>
they just put it in a separate module to allowrunning the same logic from multiple buses
<azonenberg>
coolrunner is literlaly shifting stuff into {addr, data}
<rqou>
azonenberg: re your comment on twitter: you can totally just invoke int 0x80 in a wine PE
<rqou>
nothing special, it just works afaik
<azonenberg>
yeah of coruse
<azonenberg>
it just means you have to write asm
<azonenberg>
the point was more it's a windows PE binary
<azonenberg>
that is meant to run on linux
<azonenberg>
and not windows
<rqou>
i mean, winelib exists
<rqou>
azonenberg: want to write some ransomware that does this? :P
<kc8apf>
looks like ISC_ENABLE_CLAMP could be interesting
<kc8apf>
things to try
<rqou>
azonenberg: are you familiar with linux antidebug?
<rqou>
afaict linux tools tend to be more robust against antidebug tricks, but the kernel gives you far more fun toys
<azonenberg>
rqou: lol
<azonenberg>
i have not done a ton with antidebug stuff, no
<rqou>
e.g. "my malware (which runs as root) is opening /dev/kvm, have fun" :P
<rqou>
or "my malware uses a 16-bit stack segment, enters 16-bit protected mode, and makes 32-bit syscalls. oh but it's a 64-bit binary, nbd"
<genii>
We had some guy trying to execute 64bit binaries on a 32bit box that was compromised
<azonenberg>
lol
<rqou>
oh, you need to be running a 64-bit kernel of course
<rqou>
but afaict you can freely switch between 32/64 bit code in userspace regardless of what architecture you launched with
<rqou>
hmm, i should write a crackme with a bunch of these tricks
<rqou>
linux crackmes tend to be somewhat rare anyways
<pie_>
plese do
<rqou>
unfortunately it'll probably scare people away by requiring root
bitd has quit [Remote host closed the connection]
X-Scale has joined ##openfpga
m_w has joined ##openfpga
<azonenberg>
rqou: can always run in a vm
<rqou>
if your vm supports nested VT-x :P
<rqou>
(this is what the "opens /dev/kvm" part is about)
<azonenberg>
is that really that rare?
<azonenberg>
iirc both vmware and virtualbox can do virtualized vt
<azonenberg>
virtualizing vt-d is less likely imo
<rqou>
hmm TIL
<rqou>
and no, I don't expect to need vt-d
<azonenberg>
5-10 years ago it might have been a viable countermeasure
<azonenberg>
not now
<rqou>
countermeasure?
<azonenberg>
To make sure you're not in a vm
<rqou>
no, the idea was to make a "self-debugging obfuscator" except with even worse tools for attackers to try attacking it
<rqou>
not to detect if you're in a vm
<azonenberg>
lol
<rqou>
see for example Armadillo
<rqou>
anyways, you can't just attach gdb to a kvm guest
<rqou>
azonenberg: you can also be evil like old Themida and hook int1/int3 and do unpacking in kernel mode :P
<rqou>
feel free to borrow this for your new malcode
<rqou>
:P
<q3k>
requiring acedemic credentials makes me sad
<qu1j0t3>
it's only a tweet. the "or equivalent exp" may be implied.
<awygle>
i suspect it's an actual postdoc position, no?
<awygle>
like, in a research lab
<qu1j0t3>
oh right
<q3k>
and my whining was more general than this job in particular :P
Bike has joined ##openfpga
<rqou>
btw azonenberg, people _do_ realize wine isn't a sandbox, right?
<rqou>
(please say yes)
* awygle
does
<jn__>
"people" is a very broad group ;)
* awygle
is a person (most days [after coffee])
* cr1901_modern
doesn't drink coffee
* qu1j0t3
drinks enough for both of us
* awygle
is currently about 60% coffee by volume
<awygle>
usually i drink less but in a life that strives for smoothness the last week has been Not Smooth
Bike has quit [Ping timeout: 240 seconds]
noobineer has quit [Remote host closed the connection]
<azonenberg>
rqou: i would hope so
<azonenberg>
i mean, to be fair
<azonenberg>
it does provide a decent degree of protection against poorly written Windows software
<azonenberg>
that isn't going out of its way to break out
<rqou>
lol
<azonenberg>
if you bother to discover you're on WINE you can trivially just do raw linux calls to escape
Bike has joined ##openfpga
<azonenberg>
But i think if you only ever use the windows API you're actually halfway isolated
<rqou>
i've seen people claim that the (usually somewhat crappy) windows software from ~2000-2010 nowadays tends to run better on wine than actual windows
<azonenberg>
lolol
<jn__>
assuming / isn't "mounted" as a windows drive
<rqou>
it's usually mounted on Z: by default
<jn__>
btw, someone should implement that trivial DOSBOX escape (mount /, overwrite whatever useful file you can) and then implement a mitigation (mount /lock or something that tells dosbox to refuse any mount calls in the future)
<jn__>
i didn't get around to it yet, because i don't care much about dosbox
<rqou>
er, what?
<rqou>
dosbox has mounts?
<jn__>
yes
<rqou>
and escapes?
<jn__>
presumably
<rqou>
does it just work by setting up a 16-bit code segment?
<jn__>
mount Y: /
<jn__>
Y:
<jn__>
dir
<rqou>
or does it run through a cpu emulator?
<rqou>
wait
<cr1901_modern>
emulator
<jn__>
dosbox uses an emulator AFAIK
<rqou>
it has to use emulator
<rqou>
because real mode
<rqou>
thanks DOS
<jn__>
dosemu (?) doesn't
<jn__>
that other one needs the NULL page
<rqou>
wine win16 mode doesn't
<rqou>
but that's protected mode
<rqou>
(which you can still use afaik)
<rqou>
afaik you can even make syscalls from a 16-bit protected mode segment
<jn__>
i kinda like that DOSBOX is an emulator, because that means it'll (presumably) run in non-x86
<rqou>
you can definitely do it from a 16-bit stack (see espfix) :P
<jn__>
ok, i might be wrong about dosemu. i'm not even sure i remember the name correctly ;)
<rqou>
i bet these tricks will break valgrind/strace/gdb even harder
<rqou>
anybody open /dev/kvm to emulate dos? :P
<jn__>
heh
<jn__>
i doubt the "syscall" proxy in DOSBOX supports ioctl, though
Mimoja has quit [Ping timeout: 246 seconds]
<jn__>
(and i haven't seen it; i'm just assuming it's there because it makes sense this way)
Mimoja has joined ##openfpga
<jn__>
IOW, someone plox research dis
felix_ has quit [Ping timeout: 246 seconds]
esden has quit [Ping timeout: 246 seconds]
felix_ has joined ##openfpga
<jn__>
i guess you could do code injection via /proc/<pid>/mem or something…
esden has joined ##openfpga
<awygle>
rqou: yes, win 95 era software runs much better on wine than on any modern windows
<Zorix>
better off using something like pcem for win95 software
<awygle>
hm, interesting. did not come across this when i last had this problem (circa 2011 maybe)