Re: Bug#881830: linux: cherry-pick "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stretch kernel

Re: Bug#881830: linux: cherry-pick "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stretch kernel

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On Wed, 2017-11-15 at 16:50 +0000, James Cowgill wrote:
> Since I was a little puzzled as to why keyutils built previously on
> mips, I found this commit to 4.8 which caused the need for KEYS_COMPAT:
> 
> commit 20f06ed9f61a185c6dabd662c310bed6189470df
> Author: David Howells <dhowells@redhat.com>
> Date:   Wed Jul 27 11:43:37 2016 +0100
> 
>     KEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace
>     
>     MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than
>     calling sys_keyctl.  The latter will work in a lot of cases, thereby hiding
>     the issue.
> 
> Now I'm thinking maybe this can be argued as a bugfix for the above
> commit and put in upstream 4.9?

Greg, please queue up these two for 4.9:

5c2a625937ba arm64: support keyctl() system call in 32-bit mode
47b2c3fff493 security/keys: add CONFIG_KEYS_COMPAT to Kconfig

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of
incompetence.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Bug#881830: linux: cherry-pick "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stretch kernel

[James Cowgill]

[-- Attachment #1.1: Type: text/plain, Size: 1078 bytes --]

Hi,

On 16/11/17 19:04, Ben Hutchings wrote:
> On Wed, 2017-11-15 at 16:50 +0000, James Cowgill wrote:
>> Since I was a little puzzled as to why keyutils built previously on
>> mips, I found this commit to 4.8 which caused the need for KEYS_COMPAT:
>>
>> commit 20f06ed9f61a185c6dabd662c310bed6189470df
>> Author: David Howells <dhowells@redhat.com>
>> Date:   Wed Jul 27 11:43:37 2016 +0100
>>
>>     KEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace
>>     
>>     MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than
>>     calling sys_keyctl.  The latter will work in a lot of cases, thereby hiding
>>     the issue.
>>
>> Now I'm thinking maybe this can be argued as a bugfix for the above
>> commit and put in upstream 4.9?
> 
> Greg, please queue up these two for 4.9:
> 
> 5c2a625937ba arm64: support keyctl() system call in 32-bit mode
> 47b2c3fff493 security/keys: add CONFIG_KEYS_COMPAT to Kconfig

Sorry, I asked for this in two places. I think it's already queued up
for 4.9 now.

Thanks,
James


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Bug#881830: linux: cherry-pick "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stretch kernel

[Greg Kroah-Hartman]

On Thu, Nov 16, 2017 at 08:28:28PM +0000, James Cowgill wrote:
> Hi,
> 
> On 16/11/17 19:04, Ben Hutchings wrote:
> > On Wed, 2017-11-15 at 16:50 +0000, James Cowgill wrote:
> >> Since I was a little puzzled as to why keyutils built previously on
> >> mips, I found this commit to 4.8 which caused the need for KEYS_COMPAT:
> >>
> >> commit 20f06ed9f61a185c6dabd662c310bed6189470df
> >> Author: David Howells <dhowells@redhat.com>
> >> Date:   Wed Jul 27 11:43:37 2016 +0100
> >>
> >>     KEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace
> >>     
> >>     MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than
> >>     calling sys_keyctl.  The latter will work in a lot of cases, thereby hiding
> >>     the issue.
> >>
> >> Now I'm thinking maybe this can be argued as a bugfix for the above
> >> commit and put in upstream 4.9?
> > 
> > Greg, please queue up these two for 4.9:
> > 
> > 5c2a625937ba arm64: support keyctl() system call in 32-bit mode
> > 47b2c3fff493 security/keys: add CONFIG_KEYS_COMPAT to Kconfig
> 
> Sorry, I asked for this in two places. I think it's already queued up
> for 4.9 now.

Well, close, but not quite.  The second patch there reverts the first
patch, and adds the "generic" work.  As I already handled that in the
merge of the second patch, the first one is not needed, and the end
result should be the same.

So all is good.  Or at least I think so, someone verifying I got this
all right would be appreciated :)

thanks,

greg k-h