On 1/19/22 14:20, Heiko Carstens wrote: > On Wed, Jan 19, 2022 at 12:02:34PM +0100, Janis Schoetterl-Glausch wrote: >>> That's a lot of code churn... I would have expected that the existing >>> functions will be renamed, get an additional key parameter, and the >>> current API is implemented by defines which map copy_to_user() & >>> friends to the new functions, and add a zero key. >> >> I don't think I understand you. I can implement raw_copy_from/to_user >> in terms of raw_copy_from/to_user_with_key, which does save a few lines, >> but that's it, isn't it? > > Right you are. I only looked at your patch, and forgot about that all > the wrapping is nowadays done in common code. > > So what I really don't like about this approach is that we get an arch > specific copy_to_user() implementation back. This means that all those > extra calls like might_fault(), instrument_copy_to_user(), and friends > now have to be kept in sync by us again, if new instrumentation or > security options are added to common code. > > Given that this is manual work / monitoring I'm sure this will not > work in the mid or long term, like it has been proven several times in > the past for other features. We need something better, which works > out-of-the-box wrt common code changes / enhancements. What are our options? 1. Tooling 1.1 Automatic monitoring 1.2 ? 2. Implementation changes 2.1 Modify common code 2.2 Don't modify common code, pass key argument via well known location 2.3 ? Neither of 2.1 and 2.2 seem great. How might 1.1 work? A build error if they are out of sync?
