[Resending this email after noticing I did not reply-to-all] On Fri, May 12, 2023 at 7:11 PM Gong Ruiqi <gongruiqi1@xxxxxxxxxx> wrote: > > > > On 2023/05/11 2:43, Hyeonggon Yoo wrote: > > I dont think adding a hardening feature by sacrificing one digit > > percent performance > > (and additional complexity) is worth. Heap spraying can only occur > > when the kernel contains > > security vulnerabilities, and if there is no known ways of performing > > such an attack, > > then we would simply be paying a consistent cost. > > > > Any opinions from hardening folks? > > I did a more throughout performance test on the same machine in the same > way, and here are the results: > > sched/ sched/ syscall/ mem/ mem/ > messaging pipe basic memcpy memset > control1 0.019 5.459 0.733 15.258789 51.398026 > control2 0.019 5.439 0.730 16.009221 48.828125 > control3 0.019 5.282 0.735 16.009221 48.828125 > control_avg 0.019 5.393 0.733 15.759077 49.684759 > > exp1 0.019 5.374 0.741 15.500992 46.502976 > exp2 0.019 5.440 0.746 16.276042 51.398026 > exp3 0.019 5.242 0.752 15.258789 51.398026 > exp_avg 0.019 5.352 0.746 15.678608 49.766343 > > I believe the results show only minor differences and normal > fluctuation, and no substantial performance degradation. > > As Pedro points out in his reply, unfortunately there are always > security vulnerabilities in the kernel, which is a fact that we have to > admit. Having a useful mitigation mechanism at the expense of a little > performance loss would be, in my opinion, quite a good deal in many > circumstances. And people can still choose not to have it by setting the > config to n. Okay, now I don't think I need to tackle it from a performance perspective anymore, at least it looks like a good tradeoff. I had few design level concerns (i.e. in ARM64 instructions are 4-byte aligned) before switching to hash_64(^ random sequence), but looks good to me now. > >> +#ifdef CONFIG_RANDOM_KMALLOC_CACHES > >> +# define SLAB_RANDOMSLAB ((slab_flags_t __force)0x01000000U) > >> +#else > >> +# define SLAB_RANDOMSLAB 0 > >> +#endif There is already the SLAB_KMALLOC flag that indicates if a cache is a kmalloc cache. I think that would be enough for preventing merging kmalloc caches?
