On 07/31/2014 02:23 PM, Herbert Xu wrote:
On Thu, Jul 31, 2014 at 11:07:26AM +0800, Ming Liu wrote:
And we've figure out a patch as the attached, the basic idea is just
queue the packets if "irq_fpu_usable()" is not usable or if there
are already few packets queued for decryption. Else decrypt t
On Thu, Jul 31, 2014 at 11:07:26AM +0800, Ming Liu wrote:
>
> And we've figure out a patch as the attached, the basic idea is just
> queue the packets if "irq_fpu_usable()" is not usable or if there
> are already few packets queued for decryption. Else decrypt the
> packets.
Yes your description m
On 31 July 2014 00:11, Borislav Petkov wrote:
>
> On Wed, Jul 30, 2014 at 11:28:14PM +0200, Mathias Krause wrote:
> > Gah, CONFIG_AS_CRC32 gets defined as a preprocessor symbol only so
> > cannot be used in makefiles. So crc32c-pcl-intel-asm_64.S needs a
> > "#ifdef CONFIG_AS_CRC32" guard and stil
Hi, all:
I encountered a IPsec packets reordering issue, following is the setup
and scenario
There is a IPSec IKEv1 tunnel between B & C
The traffic is UDP from C to A @ 40 mbps
Packets are coming in order at B but leaving out of order towards A
If IPSec is disabled between B &
One Thousand Gnomes writes:
> On Wed, 30 Jul 2014 11:41:41 -0700
> ebied...@xmission.com (Eric W. Biederman) wrote:
>
>> One Thousand Gnomes writes:
>>
>> >> Andy you seem to be arguing here for two system calls.
>> >> get_urandom() and get_random().
>> >>
>> >> Where get_urandom only blocks i
On Wed 2014-07-30 16:40:52, Bernd Petrovitsch wrote:
> On Mit, 2014-07-30 at 07:56 -0600, Bob Beck wrote:
> > Pavel. I have bit 'ol enterprise daemon running with established file
> > descriptors serving thousands of connections
> > which periodically require entropy. Now I run out of descriptors.
On Wed, Jul 30, 2014 at 11:28:14PM +0200, Mathias Krause wrote:
> Gah, CONFIG_AS_CRC32 gets defined as a preprocessor symbol only so
> cannot be used in makefiles. So crc32c-pcl-intel-asm_64.S needs a
> "#ifdef CONFIG_AS_CRC32" guard and still be compiled for CONFIG_64BIT,
> as it is now. It'll be
On Wed, 30 Jul 2014 11:41:41 -0700
ebied...@xmission.com (Eric W. Biederman) wrote:
> One Thousand Gnomes writes:
>
> >> Andy you seem to be arguing here for two system calls.
> >> get_urandom() and get_random().
> >>
> >> Where get_urandom only blocks if there is not enough starting entropy,
>
On Wed, Jul 30, 2014 at 11:19:37PM +0200, Mathias Krause wrote:
> On Wed, Jul 30, 2014 at 06:47:01PM +0200, Borislav Petkov wrote:
> > [...]
>
> This looks too complicated. We do have as-instr for exactly those kind
> of tests. And, in fact, looking at arch/x86/Makefile we already have one
> for c
On Wed, Jul 30, 2014 at 06:47:01PM +0200, Borislav Petkov wrote:
> Building current kernel with some old toolchain (gcc 4.1.2 and gas 2.17)
> chokes with:
>
> arch/x86/crypto/crc32c-pcl-intel-asm_64.S: Assembler messages:
> arch/x86/crypto/crc32c-pcl-intel-asm_64.S:128: Error: no such instruction:
The CCP hardware interprets all numbers as unsigned numbers, therefore
sign extending input data is not valid. Modify the function calls
for RSA and ECC to not perform sign extending.
This patch is based on the cryptodev-2.6 kernel tree.
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/ccp-o
One Thousand Gnomes writes:
>> Andy you seem to be arguing here for two system calls.
>> get_urandom() and get_random().
>>
>> Where get_urandom only blocks if there is not enough starting entropy,
>> and get_random(GRND_RANDOM) blocks if there is currently not enough
>> entropy.
>>
>> That wou
Am Dienstag, 29. Juli 2014, 15:47:56 schrieb Jarod Wilson:
Hi Jarod,
>There are a few missing spaces in the error text strings for
>drbg_cavs_test, trivial fix.
Thanks a lot.
>
>CC: Stephan Mueller
>CC: Herbert Xu
>CC: "David S. Miller"
>CC: linux-crypto@vger.kernel.org
>Signed-off-by: Jarod
Building current kernel with some old toolchain (gcc 4.1.2 and gas 2.17)
chokes with:
arch/x86/crypto/crc32c-pcl-intel-asm_64.S: Assembler messages:
arch/x86/crypto/crc32c-pcl-intel-asm_64.S:128: Error: no such instruction:
`crc32b %bl,%r8d'
arch/x86/crypto/crc32c-pcl-intel-asm_64.S:204: Error: n
On Mit, 2014-07-30 at 07:56 -0600, Bob Beck wrote:
> Pavel. I have bit 'ol enterprise daemon running with established file
> descriptors serving thousands of connections
> which periodically require entropy. Now I run out of descriptors. I
> can't establish new connections. but I should
> now halt
On Tuesday, July 29, 2014 08:41:09 PM Milan Broz wrote:
> Th AF_ALG socket was missing a security label (e.g. SELinux)
> which means that socket was in "unlabeled" state.
>
> This was recently demonstrated in the cryptsetup package
> (cryptsetup v1.6.5 and later.)
> See https://bugzilla.redhat.com
> > We sort of have one. It's called capable(). Just needs extending to cover
> > anything else you care about, and probably all the numeric constants
> > replacing with textual names.
> >
>
> Except that it's all backwards: these are things that default to *on*,
> and people might want them to tu
> Andy you seem to be arguing here for two system calls.
> get_urandom() and get_random().
>
> Where get_urandom only blocks if there is not enough starting entropy,
> and get_random(GRND_RANDOM) blocks if there is currently not enough
> entropy.
>
> That would allow -ENOSYS to be the right retur
Theodore Ts'o wrote:
It's me again, finding only one issue per cycle :/
> EAGAIN The requested entropy was not available, and
> getentropy(2) would have blocked if GRND_BLOCK flag
> was set.
"if GRND_NONBLOCK flag was not set"
Eike
--
T
Pavel. I have bit 'ol enterprise daemon running with established file
descriptors serving thousands of connections
which periodically require entropy. Now I run out of descriptors. I
can't establish new connections. but I should
now halt all the other ones that require entropy? I should raise
SIG
On Wed 2014-07-23 14:10:16, Hannes Frederic Sowa wrote:
>
>
> On Wed, Jul 23, 2014, at 13:52, George Spelvin wrote:
> > I keep wishing for a more general solution. For example, some way to
> > have a "spare" extra fd that could be accessed with a special O_NOFAIL
> > flag.
> >
> > That would al
Hi!
> The rationale of this system call is to provide resiliance against
> file descriptor exhaustion attacks, where the attacker consumes all
> available file descriptors, forcing the use of the fallback code where
> /dev/[u]random is not available. Since the fallback code is often not
> well-te
On Tue, Jul 29, 2014 at 03:28:25PM -0700, Tim Chen wrote:
> Peter,
>
> Is my explanation adequate or you still have objection to the implementation?
> I'm
> trying to decide here whether to extend our batch processing by
> the crypto daemon (prolong our busy period)
> based on whether there are
23 matches
Mail list logo
