On Thu, Oct 28, 2021 at 02:39:52PM -0300, Martin Fernandez wrote: > Because it's not convenient to parse dmesg. And about /proc/cpuinfo, > it tells you about TME, as a feature of the cpu but it doesn't tell > you if it is activated, We can make "tme" or whatever string we decide upon, visible only when the feature is activated - not a problem. Just like we do on AMD. > and even if it is activated you will need to be sure that you are > storing your data in a region flagged with this new attribute. Can you have a system where some of the memory is crypto-capable and some of it is not? I've never heard about such a system. At least, on AMD SME, all your memory gets encrypted... > Here we discussed about it some time ago: > http://lkml.iu.edu/hypermail/linux/kernel/2006.2/06753.html . That > comment is what triggered this patch. ... or maybe dhansen knows more. So, you folks feeding us piecemeal all these "requirements" won't get you very far. So please sit down and write a detailed use case about which customers, when and what exactly they need extracted from the system and why. Because this is not all - there's TDX and SEV and SEV-ES and SEV-SNP and all those partition and encrypt the system or part of it in a different way. And I'm sure customers will wanna know about that too. Are they running in an encrypted guest in a public cloud, what security they have, blabla, everything you can imagine. And so we won't be adding a different reporting method for each type of encryption that happens. But we don't know what we need to report unless we know the use case. Which is not in the least clear to me. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
