On Wed, Dec 05, 2018 at 10:02:44AM +0100, Maxime Villard wrote: > Le 03/12/2018 à 19:35, Manuel Bouyer a écrit : > > On Mon, Dec 03, 2018 at 12:54:26PM +0100, Maxime Villard wrote: > > > In other words, 80% of KASLR is enabled by default, regardless of #ifdef > > > KASLR. Therefore, it is wrong to add an ifdef, because in either case we > > > > 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, it's enabled > very early, and there is no reason for things to go wrong before
There's no reason until you run into one :) I'm also concerned if things go wrong *after*, but before ddb is useable. This is where reproductible boots can be important (I've been there). > (locore.S, which I already largely fixed). The only special case is the PTE > space; but given that it is recursive, even when it's a static location, it > is still very difficult to debug. I know, I've been there :) > > Now that the design is stable and simpler than before, it should be less > complicated to add an option to turn it off; but I still wouldn't want to do > that because it adds complexity for no good reason. Maybe "turn it off" is not the right word, it's more "reproductible boots": two consecutive boots gives identical and predictible memory contents (up to some point, of course). as I understand KASLR (but I didn't look at the code), addresses are choosen at random. So I guess there's a random number generator in the process. Maybe it would be as simple as making the random number generator return a constant value ? -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --