- 1. Re: [PATCH 03/24] net: add a new sockptr_t type (score: 1)
- Author: Christoph Hellwig <hch@xxxxxx>
- Date: Wed, 22 Jul 2020 09:56:20 +0200
- current mainline has almost no set_fs left, and setsockopt seems pretty much safe. But if we go back a long term stable release or two I bet I'd find one or two.
- /html/lvs-devel/2020-07/msg00081.html (15,552 bytes)
- 2. RE: [PATCH 03/24] net: add a new sockptr_t type (score: 1)
- Author: David Laight <David.Laight@xxxxxxxxxx>
- Date: Tue, 21 Jul 2020 10:14:20 +0000
- ... If you need to do that you might as well make it a struct where either the kernel or user address is defined. Far safer for all architectures. Indeed you could add the length (to save passing an
- /html/lvs-devel/2020-07/msg00075.html (17,405 bytes)
- 3. RE: [PATCH 03/24] net: add a new sockptr_t type (score: 1)
- Author: David Laight <David.Laight@xxxxxxxxxx>
- Date: Tue, 21 Jul 2020 09:55:20 +0000
- ... One thought I've had is that on 64-bit architectures there is almost always some part of the KVA that can never be valid and is larger than the maximum size of a user VA. If the user address is o
- /html/lvs-devel/2020-07/msg00074.html (17,027 bytes)
- 4. Re: [PATCH 03/24] net: add a new sockptr_t type (score: 1)
- Author: Eric Biggers <ebiggers@xxxxxxxxxx>
- Date: Mon, 20 Jul 2020 10:55:43 -0700
- Yes. I thought that eliminating that class of bug is one of the main motivations for your "remove set_fs" work. See commit 128394eff343 ("sg_write()/bsg_write() is not fit to be called under KERNEL_D
- /html/lvs-devel/2020-07/msg00066.html (14,243 bytes)
- 5. Re: [PATCH 03/24] net: add a new sockptr_t type (score: 1)
- Author: Christoph Hellwig <hch@xxxxxx>
- Date: Mon, 20 Jul 2020 19:43:22 +0200
- Yeah, we'll need to validate that before initializing the pointer. But thinking this a little further: doesn't this mean any set_fs(KERNEL_DS) that has other user pointers than the one it is intended
- /html/lvs-devel/2020-07/msg00064.html (14,030 bytes)
- 6. Re: [PATCH 03/24] net: add a new sockptr_t type (score: 1)
- Author: Eric Biggers <ebiggers@xxxxxxxxxx>
- Date: Mon, 20 Jul 2020 09:37:48 -0700
- How does this not introduce a massive security hole when CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE? AFAICS, userspace can pass in a pointer >= TASK_SIZE, and this code makes it be treated as a ke
- /html/lvs-devel/2020-07/msg00062.html (16,667 bytes)
- 7. [PATCH 03/24] net: add a new sockptr_t type (score: 1)
- Author: Christoph Hellwig <hch@xxxxxx>
- Date: Mon, 20 Jul 2020 14:47:16 +0200
- Add a uptr_t type that can hold a pointer to either a user or kernel memory region, and simply helpers to copy to and from it. For architectures like x86 that have non-overlapping user and kernel add
- /html/lvs-devel/2020-07/msg00056.html (16,648 bytes)
This search system is powered by
Namazu