Re: kernel projects for students

On Mon, Mar 22, 2021 at 11:37 AM Muni Sekhar wrote: > > What are some good Linux projects in kernel space for final year > computer.science engineering students? > Could someone help and share your ideas on this please. Hedging deployed cryptography. Hedging can be used to keep the state of a

Re: [PATCH] x86: ipc: fix x32 version of shmid64_ds and msqid64_ds

Hi Arnd, One comment here: > +#if !defined(__x86_64__) || !defined(__ilp32__) > #include > +#else I understand there's some progress having Clang compile the kernel. Clang treats __ILP32__ and friends differently than GCC. I believe ILP32 shows up just about everywhere there are 32-bit ints,

Re: [PATCH] x86: ipc: fix x32 version of shmid64_ds and msqid64_ds

Hi Arnd, One comment here: > +#if !defined(__x86_64__) || !defined(__ilp32__) > #include > +#else I understand there's some progress having Clang compile the kernel. Clang treats __ILP32__ and friends differently than GCC. I believe ILP32 shows up just about everywhere there are 32-bit ints,

Re: [PATCH RFC 0/3] API for 128-bit IO access

On Wed, Jan 24, 2018 at 4:05 AM, Yury Norov wrote: > > ... > With all that, this example code: > > static int __init 128bit_test(void) > { > __uint128_t v; > __uint128_t addr; > __uint128_t val = (__uint128_t) 0x1234567890abc; > ... In case it

Re: [PATCH RFC 0/3] API for 128-bit IO access

On Wed, Jan 24, 2018 at 4:05 AM, Yury Norov wrote: > > ... > With all that, this example code: > > static int __init 128bit_test(void) > { > __uint128_t v; > __uint128_t addr; > __uint128_t val = (__uint128_t) 0x1234567890abc; > ... In case it matters, you can check for

Re: [lkp-robot] [x86/kconfig] 81d3871900: BUG:unable_to_handle_kernel

On Fri, Oct 13, 2017 at 3:09 PM, Linus Torvalds wrote: > On Fri, Oct 13, 2017 at 6:56 AM, Andrey Ryabinin > wrote: >> >> This could be fixed by s/vmovdqa/vmovdqu change like bellow, but maybe the >> right fix >> would be to align the data

Re: [lkp-robot] [x86/kconfig] 81d3871900: BUG:unable_to_handle_kernel

On Fri, Oct 13, 2017 at 3:09 PM, Linus Torvalds wrote: > On Fri, Oct 13, 2017 at 6:56 AM, Andrey Ryabinin > wrote: >> >> This could be fixed by s/vmovdqa/vmovdqu change like bellow, but maybe the >> right fix >> would be to align the data properly? > > I suspect anything that has the SHA

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Hi Ted, Snipping one comment: > Practically no one uses /dev/random. It's essentially a deprecated > interface; the primary interfaces that have been recommended for well > over a decade is /dev/urandom, and now, getrandom(2). We only need > 384 bits of randomness every 5 minutes to reseed the

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Hi Ted, Snipping one comment: > Practically no one uses /dev/random. It's essentially a deprecated > interface; the primary interfaces that have been recommended for well > over a decade is /dev/urandom, and now, getrandom(2). We only need > 384 bits of randomness every 5 minutes to reseed the

Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 7:38 PM, Theodore Ts'o wrote: > On Tue, Jun 20, 2017 at 11:49:07AM +0200, Jason A. Donenfeld wrote: >> ... >>> I more or less agree with you that we should just turn this on for all >>> users and they'll just have to live with the spam and report odd >>>

Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 7:38 PM, Theodore Ts'o wrote: > On Tue, Jun 20, 2017 at 11:49:07AM +0200, Jason A. Donenfeld wrote: >> ... >>> I more or less agree with you that we should just turn this on for all >>> users and they'll just have to live with the spam and report odd >>> entries, and

Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 5:36 AM, Theodore Ts'o wrote: > On Tue, Jun 20, 2017 at 10:53:35AM +0200, Jason A. Donenfeld wrote: >> > Suppressing all messages for all configurations cast a wider net than >> > necessary. Configurations that could potentially be detected and fixed >> >

Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 5:36 AM, Theodore Ts'o wrote: > On Tue, Jun 20, 2017 at 10:53:35AM +0200, Jason A. Donenfeld wrote: >> > Suppressing all messages for all configurations cast a wider net than >> > necessary. Configurations that could potentially be detected and fixed >> > likely will go

Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 4:14 AM, Jason A. Donenfeld wrote: >... > Specifically, I added `depends on DEBUG_KERNEL`. This means that these > useful warnings will only poke other kernel developers. This is probably > exactly what we want. If the various associated developers see a

Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 4:14 AM, Jason A. Donenfeld wrote: >... > Specifically, I added `depends on DEBUG_KERNEL`. This means that these > useful warnings will only poke other kernel developers. This is probably > exactly what we want. If the various associated developers see a warning > coming

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

On Fri, Jun 16, 2017 at 11:45 PM, Lee Duncan wrote: > On 06/16/2017 05:41 PM, Jason A. Donenfeld wrote: >> Hi Lee, >> >> On Fri, Jun 16, 2017 at 11:58 PM, Lee Duncan wrote: >>> It seems like what you are doing is basically "good", i.e. if there is >>> not

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

On Fri, Jun 16, 2017 at 11:45 PM, Lee Duncan wrote: > On 06/16/2017 05:41 PM, Jason A. Donenfeld wrote: >> Hi Lee, >> >> On Fri, Jun 16, 2017 at 11:58 PM, Lee Duncan wrote: >>> It seems like what you are doing is basically "good", i.e. if there is >>> not enough random data, don't use it. But

Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness

On Tue, Jun 6, 2017 at 1:48 PM, Jason A. Donenfeld wrote: > This enables an important dmesg notification about when drivers have > used the crng without it being seeded first. Prior, these errors would > occur silently, and so there hasn't been a great way of diagnosing these >

Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness

On Tue, Jun 6, 2017 at 1:48 PM, Jason A. Donenfeld wrote: > This enables an important dmesg notification about when drivers have > used the crng without it being seeded first. Prior, these errors would > occur silently, and so there hasn't been a great way of diagnosing these > types of bugs for

Re: [PATCH v3 02/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family

On Mon, Jun 5, 2017 at 8:50 PM, Jason A. Donenfeld wrote: > These functions are simple convenience wrappers that call > wait_for_random_bytes before calling the respective get_random_* > function. It may be advantageous to add a timeout, too. There's been a number of times I

Re: [PATCH v3 02/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family

On Mon, Jun 5, 2017 at 8:50 PM, Jason A. Donenfeld wrote: > These functions are simple convenience wrappers that call > wait_for_random_bytes before calling the respective get_random_* > function. It may be advantageous to add a timeout, too. There's been a number of times I did not want to

Re: get_random_bytes returns bad randomness before seeding is complete

On Sun, Jun 4, 2017 at 1:48 AM, Stephan Müller wrote: > Am Freitag, 2. Juni 2017, 16:59:56 CEST schrieb Jason A. Donenfeld: > >> Alternatively, I'm open to other solutions people might come up with. > > How about stirring in some data from the Jitter RNG that we have in the

Re: get_random_bytes returns bad randomness before seeding is complete

On Sun, Jun 4, 2017 at 1:48 AM, Stephan Müller wrote: > Am Freitag, 2. Juni 2017, 16:59:56 CEST schrieb Jason A. Donenfeld: > >> Alternatively, I'm open to other solutions people might come up with. > > How about stirring in some data from the Jitter RNG that we have in the kernel > already and

Re: get_random_bytes returns bad randomness before seeding is complete

On Sat, Jun 3, 2017 at 5:45 PM, Sandy Harris wrote: > ... > Of course this will fail on systems with no high-res timer. Are there > still some of those? It might be done in about 1000 times as long on a > system that lacks the realtime library's nanosecond timer but has

Re: get_random_bytes returns bad randomness before seeding is complete

On Sat, Jun 3, 2017 at 5:45 PM, Sandy Harris wrote: > ... > Of course this will fail on systems with no high-res timer. Are there > still some of those? It might be done in about 1000 times as long on a > system that lacks the realtime library's nanosecond timer but has the > Posix standard

Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

>> > The design and implementation is driven by a set of goals described in [2] >> > that the LRNG completely implements. Furthermore, [2] includes a >> > comparison with RNG design suggestions such as SP800-90B, SP800-90C, and >> > AIS20/31. >> >> A quick comment about SP800 and the hardware

Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

>> > The design and implementation is driven by a set of goals described in [2] >> > that the LRNG completely implements. Furthermore, [2] includes a >> > comparison with RNG design suggestions such as SP800-90B, SP800-90C, and >> > AIS20/31. >> >> A quick comment about SP800 and the hardware

Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

> The design and implementation is driven by a set of goals described in [2] > that the LRNG completely implements. Furthermore, [2] includes a > comparison with RNG design suggestions such as SP800-90B, SP800-90C, and > AIS20/31. A quick comment about SP800 and the hardware instructions...

Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

> The design and implementation is driven by a set of goals described in [2] > that the LRNG completely implements. Furthermore, [2] includes a > comparison with RNG design suggestions such as SP800-90B, SP800-90C, and > AIS20/31. A quick comment about SP800 and the hardware instructions...

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> As far as half-siphash is concerned, it occurs to me that the main > problem will be those users who need to guarantee that output can't be > guessed over a long period of time. For example, if you have a > long-running process, then the output needs to remain unguessable over > potentially

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> As far as half-siphash is concerned, it occurs to me that the main > problem will be those users who need to guarantee that output can't be > guessed over a long period of time. For example, if you have a > long-running process, then the output needs to remain unguessable over > potentially

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> diff --git a/lib/test_siphash.c b/lib/test_siphash.c > new file mode 100644 > index ..93549e4e22c5 > --- /dev/null > +++ b/lib/test_siphash.c > @@ -0,0 +1,83 @@ > +/* Test cases for siphash.c > + * > + * Copyright (C) 2016 Jason A. Donenfeld . All Rights > Reserved.

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> diff --git a/lib/test_siphash.c b/lib/test_siphash.c > new file mode 100644 > index ..93549e4e22c5 > --- /dev/null > +++ b/lib/test_siphash.c > @@ -0,0 +1,83 @@ > +/* Test cases for siphash.c > + * > + * Copyright (C) 2016 Jason A. Donenfeld . All Rights > Reserved. > + * > + * This

Fast Code and HAVE_EFFICIENT_UNALIGNED_ACCESS (was: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access)

On Wed, Nov 2, 2016 at 5:25 PM, Jason A. Donenfeld wrote: > These architectures select HAVE_EFFICIENT_UNALIGNED_ACCESS: > > s390 arm arm64 powerpc x86 x86_64 > > So, these will use the original old code. > > The architectures that will thus use the new code are: > > alpha arc

Fast Code and HAVE_EFFICIENT_UNALIGNED_ACCESS (was: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access)

On Wed, Nov 2, 2016 at 5:25 PM, Jason A. Donenfeld wrote: > These architectures select HAVE_EFFICIENT_UNALIGNED_ACCESS: > > s390 arm arm64 powerpc x86 x86_64 > > So, these will use the original old code. > > The architectures that will thus use the new code are: > > alpha arc avr32 blackfin c6x

Entropy sources (was: /dev/random - a new approach)

On Fri, Aug 19, 2016 at 1:20 PM, H. Peter Anvin wrote: > On 08/18/16 22:56, Herbert Xu wrote: >> On Thu, Aug 18, 2016 at 10:49:47PM -0400, Theodore Ts'o wrote: >>> >>> That really depends on the system. We can't assume that people are >>> using systems with a 100Hz clock

Entropy sources (was: /dev/random - a new approach)

On Fri, Aug 19, 2016 at 1:20 PM, H. Peter Anvin wrote: > On 08/18/16 22:56, Herbert Xu wrote: >> On Thu, Aug 18, 2016 at 10:49:47PM -0400, Theodore Ts'o wrote: >>> >>> That really depends on the system. We can't assume that people are >>> using systems with a 100Hz clock interrupt. More often

Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver

On Wed, Aug 17, 2016 at 11:35 AM, PrasannaKumar Muralidharan wrote: > This patch adds support for hardware random number generator present in > JZ4780 SoC. > > Signed-off-by: PrasannaKumar Muralidharan > --- > ... > +static int

Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver

On Wed, Aug 17, 2016 at 11:35 AM, PrasannaKumar Muralidharan wrote: > This patch adds support for hardware random number generator present in > JZ4780 SoC. > > Signed-off-by: PrasannaKumar Muralidharan > --- > ... > +static int jz4780_rng_read(struct hwrng *rng, void *buf, size_t max, bool >

Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver

On Wed, Aug 17, 2016 at 11:35 AM, PrasannaKumar Muralidharan wrote: > This patch adds support for hardware random number generator present in > JZ4780 SoC. > > Signed-off-by: PrasannaKumar Muralidharan > --- >

Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver

On Wed, Aug 17, 2016 at 11:35 AM, PrasannaKumar Muralidharan wrote: > This patch adds support for hardware random number generator present in > JZ4780 SoC. > > Signed-off-by: PrasannaKumar Muralidharan > --- > .../devicetree/bindings/rng/ingenic,jz4780-rng.txt | 12 +++ > MAINTAINERS

Re: UB in general ... and linux/bitops.h in particular

>-- Perhaps the compiler guys could be persuaded to support > the needed features explicitly, perhaps via a command-line > option: -std=vanilla > This should be a no-cost option as things stand today, but > it helps to prevent nasty surprises in the future. It looks LLVM has

Re: UB in general ... and linux/bitops.h in particular

>-- Perhaps the compiler guys could be persuaded to support > the needed features explicitly, perhaps via a command-line > option: -std=vanilla > This should be a no-cost option as things stand today, but > it helps to prevent nasty surprises in the future. It looks LLVM has

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: > ... > But instead of arguing over what works and doesn't, let's just create > the the test set and just try it on a wide range of compilers and > architectures, hmmm? What are the requirements? Here's a short list: * No

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: > ... > But instead of arguing over what works and doesn't, let's just create > the the test set and just try it on a wide range of compilers and > architectures, hmmm? What are the requirements? Here's a short list: * No undefined

Re: better patch for linux/bitops.h

>>> So you are actually saying outright that we should sacrifice *actual* >>portability in favor of *theoretical* portability? What kind of >>twilight zone did we just step into?! >> >>I'm not sure what you mean. It will be well defined on all platforms. >>Clang may not recognize the pattern,

Re: better patch for linux/bitops.h

>>> So you are actually saying outright that we should sacrifice *actual* >>portability in favor of *theoretical* portability? What kind of >>twilight zone did we just step into?! >> >>I'm not sure what you mean. It will be well defined on all platforms. >>Clang may not recognize the pattern,

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 10:41 PM, H. Peter Anvin <h...@zytor.com> wrote: > On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton <noloa...@gmail.com> wrote: >>On Wed, May 4, 2016 at 5:52 PM, John Denker <j...@av8n.com> wrote: >>> On 05/04/2016 02:42 PM, I wrote: >&g

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 10:41 PM, H. Peter Anvin wrote: > On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton wrote: >>On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: >>> On 05/04/2016 02:42 PM, I wrote: >>> >>>> I find it very odd that the other seven func

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: > On 05/04/2016 02:42 PM, I wrote: > >> I find it very odd that the other seven functions were not >> upgraded. I suggest the attached fix-others.diff would make >> things more consistent. > > Here's a replacement patch. > ... +1,

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: > On 05/04/2016 02:42 PM, I wrote: > >> I find it very odd that the other seven functions were not >> upgraded. I suggest the attached fix-others.diff would make >> things more consistent. > > Here's a replacement patch. > ... +1, commit it.

Re: linux/bitops.h

On Wed, May 4, 2016 at 7:06 PM, Andi Kleen wrote: > On Wed, May 04, 2016 at 03:06:04PM -0700, John Denker wrote: >> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: >> >> Beware that shifting by an amount >= the number of bits in the >> >> word remains Undefined Behavior. >> >>

Re: linux/bitops.h

On Wed, May 4, 2016 at 7:06 PM, Andi Kleen wrote: > On Wed, May 04, 2016 at 03:06:04PM -0700, John Denker wrote: >> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: >> >> Beware that shifting by an amount >= the number of bits in the >> >> word remains Undefined Behavior. >> >> > This construct has

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On Wed, May 4, 2016 at 1:49 PM, <ty...@mit.edu> wrote: > On Wed, May 04, 2016 at 10:40:20AM -0400, Jeffrey Walton wrote: >> > +static inline u32 rotl32(u32 v, u8 n) >> > +{ >> > + return (v << n) | (v >> (sizeof(v) * 8 - n)); >> &

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On Wed, May 4, 2016 at 1:49 PM, wrote: > On Wed, May 04, 2016 at 10:40:20AM -0400, Jeffrey Walton wrote: >> > +static inline u32 rotl32(u32 v, u8 n) >> > +{ >> > + return (v << n) | (v >> (sizeof(v) * 8 - n)); >> > +} >> >&g

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

>> + chacha20_block(>state[0], out); >> + if (crng->state[12] == 0) >> + crng->state[13]++; > > state[12]++? Or why do you increment the nonce? In Bernstein's Salsa and ChaCha, the counter is 64-bit. It appears ChaCha-TLS uses a 32-bit counter, and the other 32-bits is given

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

>> + chacha20_block(>state[0], out); >> + if (crng->state[12] == 0) >> + crng->state[13]++; > > state[12]++? Or why do you increment the nonce? In Bernstein's Salsa and ChaCha, the counter is 64-bit. It appears ChaCha-TLS uses a 32-bit counter, and the other 32-bits is given

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

> +static inline u32 rotl32(u32 v, u8 n) > +{ > + return (v << n) | (v >> (sizeof(v) * 8 - n)); > +} That's undefined behavior when n=0. I think the portable way to do a rotate that avoids UB is the following. GCC, Clang and ICC recognize the pattern, and emit a rotate instruction.

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

> +static inline u32 rotl32(u32 v, u8 n) > +{ > + return (v << n) | (v >> (sizeof(v) * 8 - n)); > +} That's undefined behavior when n=0. I think the portable way to do a rotate that avoids UB is the following. GCC, Clang and ICC recognize the pattern, and emit a rotate instruction.

Re: [PATCH 3/3] random: add interrupt callback to VMBus IRQ handler

On Mon, May 2, 2016 at 2:26 AM, Theodore Ts'o wrote: > From: Stephan Mueller > > The Hyper-V Linux Integration Services use the VMBus implementation for > communication with the Hypervisor. VMBus registers its own interrupt > handler that completely bypasses

Re: [PATCH 3/3] random: add interrupt callback to VMBus IRQ handler

On Mon, May 2, 2016 at 2:26 AM, Theodore Ts'o wrote: > From: Stephan Mueller > > The Hyper-V Linux Integration Services use the VMBus implementation for > communication with the Hypervisor. VMBus registers its own interrupt > handler that completely bypasses the common Linux interrupt handling.

Re: Undefined Code in .../include/linux.bitops.h

On Wed, Feb 20, 2013 at 11:10 AM, Clemens Ladisch wrote: > Jeffrey Walton wrote: >> http://www.tux.org/lkml/ is a tough read, and Item 4, "I think I found >> a bug, how do I report it?" does not tell me how to report this. > > From that page: > | A bug is when so

Re: Undefined Code in .../include/linux.bitops.h

On Wed, Feb 20, 2013 at 11:10 AM, Clemens Ladisch clem...@ladisch.de wrote: Jeffrey Walton wrote: http://www.tux.org/lkml/ is a tough read, and Item 4, I think I found a bug, how do I report it? does not tell me how to report this. From that page: | A bug is when something (in the kernel