IRC channel logs
2022-12-28.log
back to list of logs
<oriansj>oh these double frees are going to be difficult to untangle <oriansj>but I think I have cleared out the first batch of them <oriansj>and it is still able to successfully unpack itself <stikonas>well, we also need to unpack tcc and make <stikonas>make is optional as it also provides tar.gz <oriansj>stikonas: very true and it is quite unlikely for my requires to break that but if I do, I can certainly fix that <stikonas>well, I doubt that you'll break them, just thought to mention for testing purposes which live-bootstrap packages use it now <oriansj>and starting second round of fuzzing <oriansj>(2 minutes, no results. A much better start) <oriansj>and it looks like I forgot to expand the logic for if it is missing -o options <oriansj>I was thinking of using input file name minus the .bz2 at the end to be the default output filename; unless anyone can think of a better idea <oriansj>(and bail if the filename is something like "a" or ".bz2") <oriansj>8 minutes, no crashes but 3 timeouts <stikonas>that's fine, usually name without .bz2 is what we want <stikonas>though -o might still be useful to put result in another directory <oriansj>well yes, that seemed the reasonable approximate behavior I assumed people would be wanting <oriansj>1 hour no crashes, I call that good progress for my first fuzzing/correcting cycle <stikonas>hmm, something is seriously wrong with memory allocation in M2-Mesoplanet <stikonas>so on amd64 (where we get segfault) I can see that blk->size is 0 but blk->size on x86 is about 7000 <stikonas>I suspect some previous calloc overwrites it... <oriansj>I guess fixing the memory allocation in M2libc is my next problem after I finish getting unbz rock solid <stikonas>possibly... I'll try to see if I can find the issue beforehand <stikonas>so there are still 2 calls not ported to UEFI: fchdir (which does not seem to be used anywhere except for 1 M2-Planet test) and unlink <stikonas>(which was added recently for rm functionality) <stikonas>and then I still need to sort out M2-Mesoplanet stuff <stikonas>including #includes, so that it can find what it needs to include <Hagfish_>is it tempting to skip the 2 calls, if they're not needed / can be worked around? <stikonas>fchdir is not, but it shouldn't be too hard to implement <stikonas>at this point the hardest bit is to figure out why "M2-Mesoplanet --version" segfaults <stikonas>Hagfish_: well, in principle nothing should break <stikonas>but implementation is probably a few lines <Hagfish_>oh, okay, it's probably nicer to just get it out of the way <Hagfish_>i mean implemented properly, rather than leaving loose ends <oriansj>well memory management bugs are by definition the hardest class of bugs in existence. <oriansj>like 98% of the complexity in rust's compiler is just trying to deal with memory bugs <Hagfish_>i thought race conditions are the hardest. although i guess you can avoid them by running a single thread, whereas it's much harder to avoid using memory :) <stikonas[m]>Perhaps it might speed up some things but not too much <oriansj>Hagfish_: race conditions can be solved by simple round robin <oriansj>it isn't super efficient but it will work <Hagfish_>anything non-deterministic seems like a nightmare, but it sounds like this segfault is at least reproducible <oriansj>problem is most people don't like the 10-20% potential performance loss that round robin suffers when priority inversion occurs <Hagfish_>i'm kinda scared how often security loses out to performance, as a goal <oriansj>Hagfish: well it isn't just security <Hagfish_>i've sort of accepted that it loses to UX, but performance isn't always critical for UX <oriansj>it is even harder of an optimization problem; as it isn't UX or performance or even price <oriansj>but rather what produces the highest net profit on the market in a given quarter. <Hagfish_>security bugs are special, because they are the only type of bugs that have human agents actively trying to trigger them <Hagfish_>(although it can sometimes feel like your users are actively trying to find bugs) :) <oriansj>if upping CPU performance results in more money, do it (specture and meltdown as examples) <Hagfish_>yeah, that's the most headline example of performance vs security that i can think of <oriansj>Hagfish: I aggressively fuzz all tools in stage0 that are written in C <Hagfish_>i hear that Linus has been quite resistant to hardening the kernel because of performance concerns, though <oriansj>Hagfish: it is the result of knowing that a 0.5% performance loss is big enough to lose important users <Hagfish_>yeah, i think that fuzzing is starting to become a best practice for most C projects, and it's good to follow that (just as we expect other projects to follow the best practice of caring about bootstrappability) <oriansj>and the community trying to security harden linux seem to be willing to actively break legacy binaries and that is taboo for linux <Hagfish_>fortunately with Free Software, it's possible for other people to make different tradeoffs (if the patchset isn't too difficult to maintain) <oriansj>depends honestly, sometimes the best option is just do a full fork <Hagfish_>i guess it comes down to velocity / community building <Hagfish_>can you attract more people to the full fork (where they have more freedom) than to maintaining a patchset (which needs fewer people) <oriansj>well finding people willing to work on something with you who share common beliefs, taste and goals is an extremely hard problem <Hagfish_>a complete rewrite is maybe one extreme case <Hagfish_>yeah, i don't think there's a general solution to that problem <Hagfish_>i think it requires people with vision, and a problem which is ripe, and a pile of good luck <oriansj>I've gone with, just start creating something and maybe other people who think it is cool might build upon it <Hagfish_>i think that most great creative minds have a back catalogue of works that aren't so widely respected, or even known <oriansj>so the more you explore, the higher the odds one is good <Hagfish_>yeah, even if there were an oracle that could tell you in advance whether an idea would turn out to be a hit, or a flop, it might be better to not ask the oracle, because the ability to generate a hit comes from the knowledge gained while making the flop <oriansj>and if you can get other people to give you ideas, then the odds that you find a neat idea goes up <Hagfish_>and it's okay to make something that only scratches your own itch <oriansj>do things that make you happy and that interest you <oriansj>if it benefits you and/or other people in your life, all the better <stikonas[m]>Well, for some use cases security might be less important than performance <Hagfish_>i can't think of a time when some project or creative work became a huge success, even though the people behind it all hated it <oriansj>weather data calculations comes to mind <stikonas[m]>In my work some people work on networking stack in user space, not secure if you have untrusted users, but if you trust all your apps and users, you can avoid kernel context switching <Hagfish_>stikonas[m]: yeah, i guess. like "denial of service" might be a security concern, but if a user can just restart the program, then that "attack" might not be as costly as a program that's half as fast <Hagfish_>right, sometimes you can design the vulnerability out of the system by putting the guarantees at a different layer <oriansj>stikonas: well rate limiting, protocol restrictions and similiar administrative features could if done right actually address the security concerns <Hagfish_>people sometimes say things like "telnet is perfectly secure, if you run it over a VPN / ipsec tunnel", etc. <Hagfish_>but the assumptions / requirements being made need to be clear to users, rather than just telling them after the fact "you were holding it wrong" <oriansj>Hagfish: well telnet over a dedicated fiber line is secure from all but physical attacks <oriansj>but it ultimately resolves down to who needs to be responsible for x and making sure the responsible party has the authorization to x in a way they want/need <Hagfish_>i think that aligning incentives is important <Hagfish_>the person who stands to lose from a vulnerability has to be the person who is empowered (with resources, including knowledge) to put the necessary defences in place <oriansj>one could say even enough effort to collapse civilization wouldn't solve it <muurkha>yeah, mechanism design is fascinating <oriansj>Hagfish: unfortunately it fails on the hidden knowledge problem <muurkha>it's a lot older than game theory I think <Hagfish_>the wikipedia article says: The 2007 Nobel Memorial Prize in Economic Sciences was awarded to Leonid Hurwicz, Eric Maskin, and Roger Myerson "for having laid the foundations of mechanism design theory".[2] <oriansj>Hagfish: imagine you wanted to discourage the creation of steel <muurkha>Dutch auctions are older than Condorcet <oriansj>So you pass a law to cap the price to $50 a ton <oriansj>I with a secret, know how to make steel at $4/ton <oriansj>price dropped but supply went up; net steel sales explode <Hagfish_>what were your competitors selling it at before the cap?