> Date: Wed, 5 Dec 2018 10:02:44 +0100 > From: Maxime Villard <m...@m00nbsd.net> > > Le 03/12/2018 à 19:35, Manuel Bouyer a écrit : > > So there's no way to completely disable KASLR now ? > > Although I admit it's usefull to have it on by default, there should be a > > way > > to turn it off for low-level debugging > > No, I thought about that but in the end there is no way, because I didn't > want to introduce another ton of #ifdefs, there are already too many. In > general, you don't actually need to turn it off for debugging,
Maybe YOU don't feel a need to turn it off for YOUR debugging, but it is sometimes legitimately helpful to diff two debugging output transcripts that include pointer addresses to isolate where a difference happened. I have often done this. Any ASLR breaks this. > Le 03/12/2018 à 23:25, matthew green a écrit : > > i don't care what other platforms do -- i care about netbsd not > > breaking basic functionality. you did that, and christos commited > > my fix to unbreak it. > > > > you're entirely welcome to fix this properly, but you are not welcome > > to break every platform's. fix the sysctls *THEN* enable the security. > > you've broken my ability to debug problems on systems i am not the > > admin on, and i've multiple times failed to diagnose a problem because > > fstat did not work. > > Pure idiocy. > > "You broke my system!" > > No, I committed a set of changes that were agreed upon months ago. It is > fine to reconsider the changes in retrospect, but meanwhile, you need to > quit fucking around with these accusations. If these are `changes that were agreed upon' months ago, then you can cite the agreement from months ago, because it happened on a public mailing list with a public archive, right? Then, you can find out what the nature of the disagreement is: - Were the changes discussed on the right mailing list or not? - Did someone misunderstand what the changes you proposed were? - Did you address all of the issues raised in the thread, or is this the same issue as one that was raised before? - Was this consequence of the proposed changes clear? Once you have identified that, you can work to find a resolution -- not just call people idiots because they don't share your priorities about ASLR. So please try again, maxv. Your last message was incredibly disrespectful to other members of the project who have spent decades with NetBSD doing debugging and diagnostics with tools your changes broke.