From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gardel.0pointer.net (gardel.0pointer.net [85.214.157.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5CD6F3717F; Thu, 25 Apr 2024 13:36:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=85.214.157.71 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714052198; cv=none; b=D7PSJj7UZfavbV3HyENWgHS74f1BQgmtPUc/OWPysKYTKVmt81t+7TqR/HHVt6pOpTWmHoYWQT+3Is+Rrp4vn6KWPXXNBsMP0llk7gXDf/FiSe9tF58WaEnIuBeXYlbflj6oNzxOSyIzf4nvbECElLb+UMe/iVLlRmxnHNl2Dns= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714052198; c=relaxed/simple; bh=WIHy+O7SQ3pXn8pbT1UfZprqhJH5m5djH0Bwidq4l50=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UPWllPNRuNO6lBDuqu8hHzOMbUIHXkodDf4/F4g0ohK/7ObyV4fyIPW/zk5SnhcjsD2IqIl/sev1BN5oO0ztB5trCBybhdsWG84CeAvPneOKPqCrgnRL5YSxgDFEzCdygcmLXaFz5c8/NJak08Jj5WQDQoJLc8R6r9n4neVS9L8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=0pointer.de; spf=pass smtp.mailfrom=0pointer.de; arc=none smtp.client-ip=85.214.157.71 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=0pointer.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=0pointer.de Received: from gardel-login.0pointer.net (gardel-mail [IPv6:2a01:238:43ed:c300:10c3:bcf3:3266:da74]) by gardel.0pointer.net (Postfix) with ESMTP id 06EDAE80EF2; Thu, 25 Apr 2024 15:36:31 +0200 (CEST) Received: by gardel-login.0pointer.net (Postfix, from userid 1000) id 802E2160029; Thu, 25 Apr 2024 15:36:30 +0200 (CEST) Date: Thu, 25 Apr 2024 15:36:30 +0200 From: Lennart Poettering To: Ilias Apalodimas Cc: Ard Biesheuvel , James Bottomley , Mikko Rapeli , linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org Subject: Re: [PATCH] efi: expose TPM event log to userspace via sysfs Message-ID: References: Precedence: bulk X-Mailing-List: linux-integrity@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Do, 25.04.24 14:47, Ilias Apalodimas (ilias.apalodimas@linaro.org) wrote: > > Yeah, the physical address is of no interest to us. We just need to > > know the existance, and that independently of any actualy tpm device > > having shown up. i.e. existance of > > /sys/kernel/security/tpm0/binary_bios_measurements would be good > > enough for is if it was available without "tpm0" actually being > > around... > > IIRC 'binary_bios_measurements' is only created after the TPM drivers > probe the device, so that wouldn't work. > Ard is right though the TPMEventLog is an EFI stub construct, so > exposing this is Linux-specific (and stub-specific). > The TPMFinalLog OTOH is described by the TCG spec so exposing that > even using the address address would work for systemd Hmm, let me ask explicitly: is there any good reason for 'binary_bios_measurements' being tied to specific TPM devices? i mean it just exposes some firmware-provided memory area, no? So, if the answer to that question is "no", maybe we can just move the file to some generic place that is not tied to "tpm0" being around, and then make the current file a symlink to that new place for compat? i.e. /sys/kernel/security/tpm0/binary_bios_measurements could be a symlink to → /sys/kernel/security/binary_bios_measurements and the latter could be something the kernel always exposes, before any tpm drivers are loaded? Lennart -- Lennart Poettering, Berlin