From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 84F286FCB for ; Mon, 17 Apr 2023 14:02:05 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 31C4321A3F; Mon, 17 Apr 2023 14:01:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1681740118; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=U8OluHKc8Dw/IrgZsjhURxbDCGWxp9NjexBQwaudwp4=; b=ogtrEw2bcy5gaw1ADC602eRpbWV7k2SwtzXm74vappvfmpRntO962+SXjbLKJ1gZTv+u9U G6xDULFBBTOGZR2Oc5vriTxCtG1bcxxBFn/iRfSU+gZlyMdXLNa5UrKkcyA1gdwu38i2MM oTKnYp2LWY/OHqFOI9ahJ7kFVtVVzrs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1681740118; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=U8OluHKc8Dw/IrgZsjhURxbDCGWxp9NjexBQwaudwp4=; b=u1Bx+R1519ISkAqLQUhAViShiw7Pfy22mq8NT3PclEjs4luT24sle/tb/yn3dEUhLb/hm8 8AVJT8zR6MThzFBg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 1C28113319; Mon, 17 Apr 2023 14:01:58 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id N2N9BlZRPWTbAwAAMHmgww (envelope-from ); Mon, 17 Apr 2023 14:01:58 +0000 Message-ID: <1b9a7d09-1af6-564a-18db-2a73f27435cd@suse.de> Date: Mon, 17 Apr 2023 16:01:57 +0200 Precedence: bulk X-Mailing-List: kernel-tls-handshake@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH 18/18] nvmet-tcp: add configfs attribute 'param_keyring' Content-Language: en-US To: Sagi Grimberg , Christoph Hellwig Cc: Keith Busch , linux-nvme@lists.infradead.org, Chuck Lever , kernel-tls-handshake@lists.linux.dev References: <20230329135938.46905-1-hare@suse.de> <20230329135938.46905-19-hare@suse.de> <60ff89b4-5d63-a6db-18b1-e0f28055c5d9@grimberg.me> <1b018791-9aa3-b988-7045-40b46bc50989@grimberg.me> <02e4f6eb-32c2-8f3c-872f-831e70da6166@suse.de> From: Hannes Reinecke In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/17/23 15:50, Sagi Grimberg wrote: > >>>>>> Add a configfs attribute to list and change the default keyring. >>>>> >>>>> is the keyring an attribute of a port? or a subsystem? Why the choice >>>>> of making it per port? >>>>> >>>> As per discussion at fmds each port might want to use different >>>> credentials. >>>> We can move it to subsystems if we decide we don't want to support >>>> that use-case. >>> >>> I think we should move it to the subsystem in Linux. >>> >> Easier said than done. >> >> We can only fetch the subsystem once we have the NQN, which we will >> know after the connect command. >> But out of necessity the connect command will only be transferred >> after TLS handshake completed, so there is not subsystem NQN allowing >> us to figure out the correct subsystem. >> >> So we'll have to keep it at the port level, I'm afraid. > > Question, why does nvmet needs to support user defined keyrings? > I understood your argument for the host, but why should the target > support it? Hmm. Originally I implemented it to be similar to the host configuration, but from the implementation we don't _actually_ need it as we select the key from the entire key store. Having it is just a nice way of avoiding having to have a daemon configuration. So if you insist we can drop it for the initial implementation. Cheers, Hannes