From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by sourceware.org (Postfix) with ESMTPS id 483F43889805 for ; Wed, 4 Oct 2023 17:01:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 483F43889805 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-2773f776f49so39235a91.1 for ; Wed, 04 Oct 2023 10:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696438905; x=1697043705; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=X09Exmb655YFRlFoojsLxlgxCUTerYtczEOUOSPcFQ4=; b=mKWE7O3k293HpEGVe1w0eVtvpdYr/SzvJvJFjEWi1NA0Ive1gamlo1W4/3TL3kyHt5 4b6aLJ5U8tISsidk2X5R5bdi9S+OV3PL08yPHegO8kWRZW5GxGa7albtXdCSTPkXVy2z yMTU8mvyUlFslJGAqn4ks48+9M1Zny1R9/aP3WFrl3qTbTW33zL8AHEQx1fj1ry4Kn3f CWT2w2ux9UCCDdiWqQmjISpGfmwBLUtCXWsftwb9iunnlMt9j3NmotH3OOu7B7kZihns ugF6vROoColeb+oQ5YmJHkJBvbAugpBDKZeKQrovqjfEfuh+RVfL1DEXN0+K4BDuEv2T wwuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696438905; x=1697043705; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=X09Exmb655YFRlFoojsLxlgxCUTerYtczEOUOSPcFQ4=; b=GaVzSCoErUCTvsGGKKQQGcJ4Sg80ipeonhQPisTDCF3ZAWtwWT8C47bE8agFLe1bcc JdBW1XwHnCJnO27aaDgu5pnaS5s9ZdoZP1YcHEE7lrRnwqS6XxyYxnBXW0Lo78mVyjCm QeHjq/HfZr4Ixt286kBU2K7+I01IVBWedVUggKGy5TrYXX4jRk64MqTe4qZAaGQkN63P DXYgwhu0hg2b6pch3XJqx/iRa3SATlMXUE/fuuKWIY3+NmlWj2FhkwOs9lUj3eNb1B+n K6H6fpZpyLzg+Q2miKqlwN/zkV4s9vq+H6eAMLrLpZN/laojAs0UrF7Y77a4q40jOQif Ao8Q== X-Gm-Message-State: AOJu0YzcYOwgjuOweUhAY7gpHAeibjD2VddeTT9QonRcVWB76pFQIjFe svA7uqrRW6PWXvx8Gzy2UTdGfA== X-Google-Smtp-Source: AGHT+IGSFHxpldSjLjymFn+zT2x7eWehUwicYWaxzE3Or1A3gCuU+bfSXGOTh8aPBm+2LcvtL+JB4A== X-Received: by 2002:a17:90b:78e:b0:276:78f2:5d31 with SMTP id l14-20020a17090b078e00b0027678f25d31mr257701pjz.21.1696438905032; Wed, 04 Oct 2023 10:01:45 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:feaf:b959:23ff:3a18:c5dc? ([2804:1b3:a7c1:feaf:b959:23ff:3a18:c5dc]) by smtp.gmail.com with ESMTPSA id p3-20020a17090ac00300b002790ded9c6dsm1804026pjt.31.2023.10.04.10.01.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Oct 2023 10:01:44 -0700 (PDT) Message-ID: Date: Wed, 4 Oct 2023 14:01:42 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] aarch64: Make glibc.mem.tagging SXID_ERASE Content-Language: en-US To: Szabolcs Nagy , Siddhesh Poyarekar , libc-alpha@sourceware.org Cc: fweimer@redhat.com, carlos@redhat.com References: From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 04/10/23 11:51, Szabolcs Nagy wrote: > The 10/04/2023 10:23, Siddhesh Poyarekar wrote: >> The actual problem I'm trying to solve is to get rid of SXID_IGNORE and >> SXID_NONE and the first step is to drop users of those levels. Supporting >> those levels requires additional processing in __libc_enable_secure, which >> is a source of bugs like CVE-2023-4911. I'm not convinced that we really >> *need* to have tunables go across sxid boundaries, so I want to flip the >> question around: do you think it is *necessary* for memory tagging tunables >> to percolate sxid boundaries? If not, then they should stay at SXID_ERASE. > > ... > >> The end goal here is to drop everything but SXID_ERASE so that we don't have >> to do string twiddling under __libc_enable_secure. >> >> The other alternative to achieve the same effect (i.e. not twiddle strings >> in __libc_enable_secure) could be to make *everything* SXID_IGNORE, which >> would then leave GLIBC_TUNABLES untouched for non-setuid children to do what >> they please with it. > > personally i think setuid binaries should not touch the > env, just ignore it, so everything SXID_IGNORE. Do you mean just drop unsecvars and not filter out glibc environment variables for AT_SECURE? > > it's not just the string twiddling but tunables_strdup > is a problem too (it can fail, needs early alloc,..). > ideally tunables_init would be a nop with AT_SECURE and > otherwise parsed the env var without malloc and touching > the env[] array passed by the kernel. I complete agree, tunables_strdup was a source of headache due its allocation requirement and, now, for parsing tunables.