On Wed, Jan 25, 2023 at 03:29:07PM +0000, Reshetova, Elena wrote: > > Again, as our documentation states, when you submit patches based on > > these tools, you HAVE TO document that. Otherwise we think you all are > > crazy and will get your patches rejected. You all know this, why ignore > > it? > > Sorry, I didn’t know that for every bug that is found in linux kernel when > we are submitting a fix that we have to list the way how it has been found. > We will fix this in the future submissions, but some bugs we have are found by > plain code audit, so 'human' is the tool. So the concern is that *you* may think it is a bug, but other people may not agree. Perhaps what is needed is a full description of the goals of Confidential Computing, and what is in scope, and what is deliberately *not* in scope. I predict that when you do this, that people will come out of the wood work and say, no wait, "CoCo ala S/390 means FOO", and "CoCo ala AMD means BAR", and "CoCo ala RISC V means QUUX". Others may end up objecting, "no wait, doing this is going to mean ***insane*** changes to the entire kernel, and this will be a performance / maintenance nightmare and unless you fix your hardware in future chips, we wlil consider this a hardware bug and reject all of your patches". But it's better to figure this out now, then after you get hundreds of patches into the upstream kernel, we discover that this is only 5% of the necessary changes, and then the rest of your patches are rejected, and you have to end up fixing the hardware anyway, with the patches upstreamed so far being wasted effort. :-) If we get consensus on that document, then that can get checked into Documentation, and that can represent general consensus on the problem early on. - Ted
