cradek: you around?
[01:23:53] <jmkasunich> http://pastebin.ca/442151
thats the header for some user space PCI handling code I'm writing
(an offshoot from the 5i20 work)
its not done yet, but close - I'm wondering where in the EMC tree it should go
it's not src/emc, and it's not really src/hal either
will it used by hal? or something else?
it will be used by the user space program that loads the FPGA bitfile into the FPGA
where is the rest of that?
and by any program that we used to twiddle with the FPGAs "config ram"
(the ram block that tells the HAL driver what to export)
ok I see that's hal/utils
today, the loader program is in src/hal/utils, but to be honest I don't like that
I think it should be associated with the 5i20 drivers and/or firmware files
(the loader, not the PCI lib)
I don't think I have any useful input for you
other than: make a new directory if you think that's appropriate
we really don't have any kind of general purpose libs directory
libnml is as close as we get
and it has a lot of non-nml stuff in it, like posemath
probably for the same reason
darn, ran out of daylight, have to go finish some outside stuff
what about emc2/src/lib, for sources of libs that are neither hal, rtapi, nml, nor emc specific
hmm... IIRC jepler copied a few things into our tree, like the togl source, etc
togl is in src/emc/usr_intf/axis/extensions....
thats not a precedent I want to follow ;-)
our copy of bwidget is in lib/python, not relevant for a C thing
I don't like /lib because it has both source and generated/target files
requiring heavy use of .cvsignore
will this actually be built into a library?
probably not, I'm lazy
just linked with whatever programs require it
maybe you should back up and think of where you want things like m5i20cfg to go, and consider this only a (generic) part of it
assuming 'setup' was a good name for that kind of program, you could have setup/m5i20, setup/common
well, if I'm gonna do that, I'd leave it in hal/utils
the new 5i20 driver is gonna be in src/hal/drivers/mesa5i20/foo.c
will this loader be called by hal when the hal driver is loaded?
the 5i20 firmware files (VHDL source and bitfiles, at the moment) are in src/hal/drivers/mesa5i20/firmware/*
it will be a separete loadusr line in the hal file
loadusr 5i20_loader <thebitfile>
src/hal/appropriate/whatever seems fine to me then
I'll probaby stick all the source for the loader in src/hal/drivers/mesa5i20
if somebody someday wants to use the upci stuff elsewhere, they'll have fun...
it'd be easy
even if they are in say src/emc/something?
with nonrecursive make, the directories are only there for the programmer's benefit
cross-directory dependencies are just as easy as any others
it's only odd/confusing for the programmer
hey, I resemble that remark
I sure like this week between snow and mosquitos
the other bit-o-fun is that the loader (and any other util that messes with fpga config) needs to be setuid
we had more snow yesterday/today
it was amazing here
only about an inch on the ground overnight, and it melted today
maybe for you it'll be next week
I hope so
got out my chevy and fixed it up a bit
the old one?
the accelerator pump was sticking (holding the gas pedal down)
gonna drive it to the workshop?
so I took it out, stretched the spring to about twice its original length, and put it back together
it'll need a new one in a few years I'm sure
hey, if it sticks force it...
it's leather (I think) and it's old - they probably only ever lasted a few years
might be a rubber equivalent that would fit, hard to say
the whole rebuild kit has maybe 8 parts - can easily put it in in an hour
ah, the simpler days...
the other day some guy was interested in it - I'd sure drive it to fest to sell it
I saw that
I don't need it, and probably won't fix it up - just will preserve it - so if someone else wants to fix it up, they can have it
nobody "needs" an antique car
it's nothing special except it's a nice survivor
[02:13:44] <cradek> http://www.trademe.co.nz/Trade-Me-Motors/Specialist-cars/Hot-rods/photos/a-95122680/p-36747485.htm
this is the car
the exact car, or the make and model?
except mine has nice original bias-ply wide whitewalls
yes I think so
on the original wheels even
you think so?
when I say exact car, I mean, is that your car for sale in that listing, or just one like it?
the tires are new, but made with the original molds that are still around
no this is someone else's car
mine's the same model, but more original
what are the general rules when writing a setuid program?
be careful, don't write to a file if you don't absolutely need to, drop privs when you don't need them
that 2nd one surprised me
but I guess it makes sense
gotta be setuid to read the ram content that says "heres what this FPGA is capable of"
then interact with the user for a while to let him say "this is the subset of those capabilities I want"
then gotta be setuid again to write it back to the fpga
what do you mean by interact?
the first time - actual interaction, prompts, menus, etc
subsequent times would use saved info
sounds like you want two programs
yeah, I was thinking of a simple one that would read the fpga, write it to a file, exit
then the big one reads the file, interacts, writes a file
and the little one reads the file, writes to the fpga
--what-it-can-dd and --he-wants-this are 1Kbytes each
oh, 1K and binary ;-)
so stdout/commandline is inconvenient
yeah, a little
besides, the code to interpret the binary should be part of the bigger interaction program
so when you add a new function, you change that only, not the setuid part
the reason for avoiding writing a file is that an attack might trick it into overwriting an important file?
temp file handling is especially dangerous
what if I get privilges, read the fpga ram into a 1K buffer, then drop priv and write the buffer to a file?
yes that's what you want to do
this program opens /dev/mem for writing... I bet there are possible attacks thru that as well
I don't know if that's particularly bad
although the region of /dev/mem that it maps is supposed to be only the FPGA, and is determined by reading /proc/bus/pci
I'm not a security programmer, but I read bugtraq...
proc and dev are probably among the safest things to read/write
it's /tmp and . you really have to worry about
well, a write to /dev/mem writes directly to physical memory... use the wrong address and you don't get a segfault, you write into some other process (or the kernel)
I guess the key is to not use the wrong address
that's the "be careful" advice I guess
also, don't trust anything the user gives you
(another important one)
yeah, my open region routine mmaps only the part of /dev/mem that /proc/bus/pci says belongs to my device
and my write routine makes sure the address is within the range that belongs to the device
I will be writing data that the user gives me, but I control where it goes
you just have to make sure what he gives you is sane (the right length etc)
for write to fpga I'll do the same thing - file -> buffer, get priv, buffer -> FPGA, drop priv
the buffer will only be 1K
yes sounds simple enough
/* drop root privs temporarily */
that snipped is from module_helper
/* reinstate root privs */
as is that one
if the user is not root (or the program is not setuid), the 2nd one will fail
but the first one won't, will it?
there's a check earlier to make sure it's setuid
so you don't have to worry about it failing...
I was confused, the drop privs code will never run unless the get privs code already did, at least in this library
in the main program I'll run the drop privs right away
(and I'll test for being root right away)
parts of the lib can be used by non-root, and I didn't want to prevent that
* jmkasunich rambles... but the gist of it is - I figgered it out ;-)
heh, sorry I was away
I'm doing "reference counting", when callers open regions and then close them, so when the close the last io region, I do iopl(0), and when they close the last mem region I do close(/dev/mem), and when both are close, I drop root privs
you may be able to drop privs right after opening - not sure
you mean mmap doesn't need privs? or read/write?
I suppose I should test
mmap probably does
I guess I don't know how it works
if I can get privs, do iopl(3), drop privs, and still be able to do outb, inb, that would be simpler
ditto if I can get privs, do mmap(), drop privs, and still access the mapped memory
I suspect you can do both of those
I guess I'll code it the easy way and try it
heh, I just realised one of the sneaky ways to attack a setuid program
its not good to get privliges, try something, if it fails print an error message and _then_ drop privs
an attacker could do "myprog input-that-will-cause-an-error >importantfile"
no, > is in the user's shell, the setuid doesn't affect it
well, thats good
dropping privs should never fail, right?
so I can do it before printing the error message (just on general principles) and it won't mung errno
I don't know...
the man page says the only error is EPERM
I have uids spinning around in my head
* jmkasunich cops out - first make it work, then make it secure...
time for sleep
SWPadnos_ is now known as SWPadnos