diff for duplicates of <20161108104112.GM1041@n2100.armlinux.org.uk> diff --git a/a/1.txt b/N1/1.txt index 0afbc61..0aa73d5 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -5,35 +5,3 @@ On Tue, Nov 08, 2016 at 10:30:42AM +0100, Heiko Carstens wrote: I don't think it's pointless at all. First, read the LWN article for the userspace side of the interface: https://lwn.net/Articles/689395/ - -From reading this, it seems (at least to me) that these pkey syscalls -are going to be the application level API - which means applications -are probably going to want to make these calls. - -Sure, they'll have to go through glibc, and glibc can provide stubs, -but the problem with that is if we do get hardware pkey support (eg, -due to pressure to increase security) then we're going to end up -needing both kernel changes and glibc changes to add the calls. - -Since one of the design goals of pkeys is to allow them to work when -there is no underlying hardware support, I see no reason not to wire -them up in architecture syscall tables today, so that we have a cross- -architecture kernel version where the pkey syscalls become available. -glibc (and other libcs) don't then have to mess around with per- -architecture recording of which kernel version the pkey syscalls were -added. - -Not wiring up the syscalls doesn't really gain anything: the code -present when !ARCH_HAS_PKEYS will still be part of the kernel image, -it just won't be callable. - -So, on balance, I've decided to wire them up on ARM, even though the -hardware doesn't support them, to avoid unnecessary pain in userspace -from the ARM side of things. - -Obviously what other architectures do is their own business. - --- -RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ -FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up -according to speedtest.net. diff --git a/a/content_digest b/N1/content_digest index 567bc80..5c0c7c0 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -24,38 +24,6 @@ "> bit pointless.\n" "\n" "I don't think it's pointless at all. First, read the LWN article for\n" - "the userspace side of the interface: https://lwn.net/Articles/689395/\n" - "\n" - "From reading this, it seems (at least to me) that these pkey syscalls\n" - "are going to be the application level API - which means applications\n" - "are probably going to want to make these calls.\n" - "\n" - "Sure, they'll have to go through glibc, and glibc can provide stubs,\n" - "but the problem with that is if we do get hardware pkey support (eg,\n" - "due to pressure to increase security) then we're going to end up\n" - "needing both kernel changes and glibc changes to add the calls.\n" - "\n" - "Since one of the design goals of pkeys is to allow them to work when\n" - "there is no underlying hardware support, I see no reason not to wire\n" - "them up in architecture syscall tables today, so that we have a cross-\n" - "architecture kernel version where the pkey syscalls become available.\n" - "glibc (and other libcs) don't then have to mess around with per-\n" - "architecture recording of which kernel version the pkey syscalls were\n" - "added.\n" - "\n" - "Not wiring up the syscalls doesn't really gain anything: the code\n" - "present when !ARCH_HAS_PKEYS will still be part of the kernel image,\n" - "it just won't be callable.\n" - "\n" - "So, on balance, I've decided to wire them up on ARM, even though the\n" - "hardware doesn't support them, to avoid unnecessary pain in userspace\n" - "from the ARM side of things.\n" - "\n" - "Obviously what other architectures do is their own business.\n" - "\n" - "-- \n" - "RMK's Patch system: http://www.armlinux.org.uk/developer/patches/\n" - "FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up\n" - according to speedtest.net. + the userspace side of the interface: https://lwn.net/Articles/689395/ -48f22559c3289e91874d3b5629bdd0bb05faffdd90e85575b33c36c993a1a021 +c8c1cad28fca55d3c72399629789dcaa3b6c316132c89e0d5b8d615a11537916
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox