Mailing List Archive

Salvatore,

I'm pretty sure the command simply disables the warning/error that you
do not have properly configured secure memory available - it doesn't fix
the problem, but it doesn't complain about it either.

--
Tony Warren
Prairie Systems, Inc.

<}-:


-----Original Message-----
From: gcrypt-devel-bounces@gnupg.org
[mailto:gcrypt-devel-bounces@gnupg.org] On Behalf Of salvatore
Sent: Sunday, August 01, 2004 10:55 AM
To: gcrypt-devel@gnupg.org
Subject: gcry_control

Hi,

Can someone tell me what the following function does...

gcry_control (GCRYCTL_DISABLE_SECMEM, 0);

I know if i don't include it i get an error... but i don't understand
what it actually does!!

Regards
Salvo

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

At Sun, 1 Aug 2004 17:54:48 +0200, salvatore wrote:

> Can someone tell me what the following function does...
>
> gcry_control (GCRYCTL_DISABLE_SECMEM, 0);

It disables the use of "secure memory", which is memory, that cannot
be swapped out, since it is locked into core. This feature requires
super-user privileges.

moritz

Thanks guys!!!

On Mon, 2 Aug 2004 10:18:15 -0500, Warren, Tony said:

> I'm pretty sure the command simply disables the warning/error that you
> do not have properly configured secure memory available - it doesn't fix
> the problem, but it doesn't complain about it either.

Actually it let libgcrypt not anymore distinguish between secure and
standard memory.

Werner

On Aug 16, 2004, at 2:07 AM, Werner Koch wrote:

> On Mon, 2 Aug 2004 10:18:15 -0500, Warren, Tony said:
>
>> I'm pretty sure the command simply disables the warning/error that you
>> do not have properly configured secure memory available - it doesn't
>> fix
>> the problem, but it doesn't complain about it either.
>
> Actually it let libgcrypt not anymore distinguish between secure and
> standard memory.

So is it the case that I should have my code call either:
gcry_control(GCRYCTL_DISABLE_SECMEM, 0);
or
gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0);
but not both?

Someone asked about the "Secure memory is not locked into core" warning
and I wanted to get rid of it and explain it at the same time...
switching from INIT to DISABLE gets rid of the warning, but I don't
know if I break things when I mess with calls to gcrypt functions.

-neil

On Mon, 16 Aug 2004 09:19:50 -0700, Neil Spring said:

> So is it the case that I should have my code call either:
> gcry_control(GCRYCTL_DISABLE_SECMEM, 0);
> or
> gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0);
> but not both?

Yes. However you should call DISABLE_SECMEM as early as possible;
i.e. before gcry_check_version.

> Someone asked about the "Secure memory is not locked into core"
> warning and I wanted to get rid of it and explain it at the same

Yesterday, I figured out that there is a bug in the way the warning
message is generated. This means the suggested way of doing a
gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN);
before gcry_check_version and later enabling the messages using
gcry_control (GCRYCTL_RESUME_SECMEM_WARN);
does not work reliable. It will be fixed in the next version.

Werner