From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 71BFA3860C33 for ; Thu, 24 Sep 2020 20:57:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 71BFA3860C33 Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-322-LgpFfnBjNh6MR1pyLcWceA-1; Thu, 24 Sep 2020 16:57:02 -0400 X-MC-Unique: LgpFfnBjNh6MR1pyLcWceA-1 Received: by mail-qk1-f199.google.com with SMTP id a2so503647qkg.19 for ; Thu, 24 Sep 2020 13:57:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=oNQF8krD745u2fmfgHb0s97YlFvxdpTxdenJm2MFynM=; b=VcyHHubLYXA01kgm5kAm2KWmyqnigc4wk25z4kIjgDiTw4yxvqdqpOBD0gQe2AijeY PBqH/S8UduteQfquOg7s0TrjLX+pXyTq/jepi1wrlDPhtxjAvMdRBUmdtuFnGJbtt9oW EALDYr5FU++cZgUegWpeQ7h5A2+bGn/BdHD9q9ERKvSyxIbNcECh0CBsNcMA1JdQDREX ceCq1I6VYj+OYPSl/EIak09/Ndaio6SxOaEoCv7Txf12P30oQF/7aH7EHg0opZRc3yNM gDDkjHuWbrHwu0y61pDXTqF/NI6EWtnBfQ996ZchiOnU6lIuUHpz63Q5QTC6p5lypOEe MGvg== X-Gm-Message-State: AOAM532hw2SZftULXXKJM59ihvz6Y7Z/TqKPCErMaD/slSBf4NUnFuIb pVP5JSp08pvtsAzzG0ubvLmIV+HYVTtdLsnQIIQZ4T1n0ts2mnRxK6fGA9iSm20kezGIlYTih7z KvhrulSM451VbAvWUc2zj X-Received: by 2002:ac8:37b5:: with SMTP id d50mr1154783qtc.228.1600981021546; Thu, 24 Sep 2020 13:57:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzqnPnoIc83RC0wWAMnjO+F/sbQ9mlAAIYKKXj+pXqdGM6/DtlqGbdMgnSiNWa+HIDQtR7wLQ== X-Received: by 2002:ac8:37b5:: with SMTP id d50mr1154757qtc.228.1600981021262; Thu, 24 Sep 2020 13:57:01 -0700 (PDT) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id f33sm519728qtb.45.2020.09.24.13.57.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Sep 2020 13:57:00 -0700 (PDT) To: libc-alpha From: Carlos O'Donell Subject: RFC: malloc and secure memory. Organization: Red Hat Message-ID: <58adb753-aecf-d367-6dbe-bb475c4c4d2c@redhat.com> Date: Thu, 24 Sep 2020 16:56:59 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 20:57:08 -0000 In reviewing this discussion: https://github.com/systemd/systemd/pull/14213 The request is for a way to mark some allocations as "secure" and to give them special properties. I wonder if we can't do this in some generic way: - Make arenas a first class construct. /* Get arena with special properties. */ malloc_arena *secure_arena = NULL; /* Get a handle to an arena that has secure heaps. If glibc can make this kind of arena and heap then it does, otherwise it returns NULL. */ secure_arena = malloc_arena_get (HEAP_SECURE); /* Does this glibc support his kind of arena? */ if (secure_arena == NULL) abort(); - Bind the malloc call site to a specific arena with specific properties. For example: /* malloc_arena takes an opaque arena pointer that is a global variable that the implementation provides, a function pointer the memory allocator routine e.g. malloc, and a size. */ password_storage = malloc_arena (secure_arena, malloc, size); ... /* Completely different TU, or scope... */ free (password_storage); At the call site you bind: * The arena. * The allocator routine. * The paramters. At runtime you can: * Verify if the allocator is one that is part of your own implementation, and if it isn't abort (fixes partial interposition problem). * Call the allocator but with the new arena as active with the given size. - Specific arenas have special properties. For example: - All allocations from a secure arena use mmap. - All frees from the secure unmap the memory. Notes: - Callers must know the memory may container "secure" information and that the eventual user of the memory may place "secure" data in that memory. The alternative is significantly more complex in that the actual chunk will have to carry the arena type information e.g. pointer to an arena or index value. That is to say that the binding of the context happens at the *use* site of the memory in question and spreads to the entire chunk. - This concept that an arena should service specific types of memory is something that DJ and I have been tossing about for a while. Particularly since it might be useful to, at an implementation level actually have the properties be specific to the logical heap. For example an arena could have a heap that services all large requests. So large requests always go via a specific heap in the same arena. This creates size-classes which might help alleviate some of the workload mixing issues we see with size growth. Likewise the arena could have a secure heap that follows these different rules. So while the user requests a HEAP_SECURE arena, they will just get their local arena but pointing to the secure heap within that arena. e.g. struct malloc_arena { heap_info heap; /* Heap selected by the type. */ ... other info ... } - Could be used to specifically request "tagged (coloured) memory" like that being offered by aarch64's MTE, and bound to a specific allocation only e.g. malloc_arena_get (HEAP_TAGGED); and then deal with the consequences of specific chunks that are always MTE-enabled. - I don't want to design a fully pluggable arena interface in C with callbacks, just something where we can extend the existing interface with a new API. - Should we consider reducing the heap size to less than 64MiB on 64-bit processes? -- Cheers, Carlos.