Re: [PATCH] remove AND operation in choose_random_kstack_offset()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 18, 2024, at 01:31, Kees Cook wrote:
> On Mon, Jun 17, 2024 at 10:33:08PM +0200, Arnd Bergmann wrote:
>> On Mon, Jun 17, 2024, at 20:22, Kees Cook wrote:
>
> I'm all for more entropy, but arch maintainers had wanted specific
> control over this value, and given the years of bikeshedding over the
> feature, I'm not inclined dive back into that debate, but okay.
>
> FWIW, the here's the actual entropy (due to stack alignment enforced by
> the compiler for the given arch ABI).
>
> standard cap is 0x3FF (10 bits).
>
> arm64: capped at 0x1FF (9 bits), 5 bits effective
> powerpc: uncapped (10 bits), 6 or 7 bits effective
> riscv: uncapped (10 bits), 6 bits effective
> x86: capped at 0xFF (8 bits), 5 (x86_64) or 6 (ia32) bits effective
> s390: capped at 0xFF (8 bits), undocumented effective entropy

Thanks for the summary. 

Right now of course we need to fix the bug from 9c573cd31343
("randomize_kstack: Improve entropy diffusion") that has led to
using full 10 bits after diffusion but put fewer bits in than
possible on some architectures. Unless you want to revert that
patch, we should ensure that any truncation is only done in
KSTACK_OFFSET_MAX() rather than passed into
choose_random_kstack_offset().

     Arnd




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux