Re: [PATCH v7 13/41] mm: Make pte_mkwrite() take a VMA
On 01.03.23 08:03, Christophe Leroy wrote:
Le 27/02/2023 à 23:29, Rick Edgecombe a écrit :
The x86 Control-flow Enforcement Technology (CET) feature includes a new
type of memory called shadow stack. This shadow stack memory has some
unusual properties, which requires some core mm changes to function
properly.
One of these unusual properties is that shadow stack memory is writable,
but only in limited ways. These limits are applied via a specific PTE
bit combination. Nevertheless, the memory is writable, and core mm code
will need to apply the writable permissions in the typical paths that
call pte_mkwrite().
In addition to VM_WRITE, the shadow stack VMA's will have a flag denoting
that they are special shadow stack flavor of writable memory. So make
pte_mkwrite() take a VMA, so that the x86 implementation of it can know to
create regular writable memory or shadow stack memory.
Apply the same changes for pmd_mkwrite() and huge_pte_mkwrite().
I'm not sure it is a good idea to add a second argument to
pte_mkwrite(). All pte_mk() only take a pte and nothing else.
We touched on this in previous revisions and so far there was no strong
push back. This turned out to be cleaner and easier than the
alternatives we evaluated.
pte_modify(), for example, takes another argument. Sure, we could try
thinking about passing something else than a VMA to identify the
writability type, but I am not convinced that will look particularly better.
I think you should do the same as commit d9ed9faac283 ("mm: add new
arch_make_huge_pte() method for tile support")
We already have 3 architectures intending to support shadow stacks in
one way or the other. Replacing all pte_mkwrite() with
arch_pte_mkwrite() doesn't sound particularly appealing to me.
--
Thanks,
David / dhildenb
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 13/41] mm: Make pte_mkwrite() take a VMA
On Sat, Feb 18, 2023 at 01:14:05PM -0800, Rick Edgecombe wrote: The x86 Control-flow Enforcement Technology (CET) feature includes a new type of memory called shadow stack. This shadow stack memory has some unusual properties, which requires some core mm changes to function properly. One of these unusual properties is that shadow stack memory is writable, but only in limited ways. These limits are applied via a specific PTE bit combination. Nevertheless, the memory is writable, and core mm code will need to apply the writable permissions in the typical paths that call pte_mkwrite(). In addition to VM_WRITE, the shadow stack VMA's will have a flag denoting that they are special shadow stack flavor of writable memory. So make pte_mkwrite() take a VMA, so that the x86 implementation of it can know to create regular writable memory or shadow stack memory. Apply the same changes for pmd_mkwrite() and huge_pte_mkwrite(). No functional change. Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-al...@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-c...@vger.kernel.org Cc: linux-hexa...@vger.kernel.org Cc: linux-i...@vger.kernel.org Cc: loonga...@lists.linux.dev Cc: linux-m...@lists.linux-m68k.org Cc: Michal Simek Cc: Dinh Nguyen Cc: linux-m...@vger.kernel.org Cc: openr...@lists.librecores.org Cc: linux-par...@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-ri...@lists.infradead.org Cc: linux-s...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: sparcli...@vger.kernel.org Cc: linux...@lists.infradead.org Cc: xen-de...@lists.xenproject.org Cc: linux-a...@vger.kernel.org Cc: linux...@kvack.org Tested-by: Pengfei Xu Suggested-by: David Hildenbrand Signed-off-by: Rick Edgecombe Acked-by: Deepak Gupta ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 03/24] arm: Remove COMMAND_LINE_SIZE from uapi
On Thu, 23 Feb 2023 05:09:17 PST (-0800), Arnd Bergmann wrote: On Thu, Feb 23, 2023, at 10:54, Alexandre Ghiti wrote: On Wed, Feb 15, 2023 at 2:05 PM Arnd Bergmann wrote: On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote: > On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote: >> From: Palmer Dabbelt >> >> As far as I can tell this is not used by userspace and thus should not >> be part of the user-visible API. >> >> Signed-off-by: Palmer Dabbelt > > Looks good to me. What's the merge plan for this? The easiest way is probably if I merge it through the whole series through the asm-generic tree. The timing is a bit unfortunate as we're just ahead of the merge window, so unless we really need this in 6.3, I'd suggest that Alexandre resend the series to me in two weeks with the Acks added in and I'll pick it up for 6.4. Sorry for the response delay, I was waiting to see if Palmer would merge my KASAN patchset in 6.3 (which he does): I have to admit that fixing the command line size + the KASAN patchset would allow 6.3 to run on syzkaller, which would be nice. If I don't see this merged in 6.3, I'll send another round as you suggested in 1 week now :) Hi Alexandre, I have no plans to still pick up the series for 6.3. The patches all look fine to me, but it's clearly too late now. What is the actual dependency for KASAN, do you just need a longer command line or something else? If it's just the command line size, I would suggest that Palmer can still pick up a oneline change to increase it and refer to this thread in the changelog as a reference for why it is not an actual UAPI break. Sorry for being slow here, I just queued up the original patch in the RISC-V tree and intend on sending it for 6.3 -- the main worry was that it's a uABi change and we're confident it's not. It's late, but I'd prefer to have this as it should let us start running syzkaller now and that'll probably find more bugs than this is likely to trigger. https://lore.kernel.org/r/mhng-b5f934ff-a9bb-4c2b-9ba6-3ab68312077a@palmer-ri-x1c9a/ ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
On Tue, 14 Feb 2023 01:19:02 PST (-0800), h...@linux.ibm.com wrote:
On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
Hi Heiko,
On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens wrote:
> On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
> > This all came up in the context of increasing COMMAND_LINE_SIZE in the
> > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
> > maximum length of /proc/cmdline and userspace could staticly rely on
> > that to be correct.
> >
> > Usually I wouldn't mess around with changing this sort of thing, but
> > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
> > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
> > increasing, but they're from before the UAPI split so I'm not quite sure
> > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
> > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
> > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
> > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
> > asm-generic/setup.h.").
> >
> > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
> > part of the uapi to begin with, and userspace should be able to handle
> > /proc/cmdline of whatever length it turns out to be. I don't see any
> > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
> > search, but that's not really enough to consider it unused on my end.
> >
> > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
> > shouldn't be part of uapi, so this now touches all the ports. I've
> > tried to split this all out and leave it bisectable, but I haven't
> > tested it all that aggressively.
>
> Just to confirm this assumption a bit more: that's actually the same
> conclusion that we ended up with when commit 3da0243f906a ("s390: make
> command line configurable") went upstream.
Thanks, I guess I'd missed that one. At some point I think there was
some discussion of making this a Kconfig for everyone, which seems
reasonable to me -- our use case for this being extended is syzkaller,
but we're sort of just picking a value that's big enough for now and
running with it.
Probably best to get it out of uapi first, though, as that way at least
it's clear that it's not uABI.
Commit 622021cd6c560ce7 ("s390: make command line configurable"),
I assume?
Yes, sorry for that. I got distracted while writing and used the wrong
branch to look this up.
Alex: Probably worth adding that to the list in the cover letter as it
looks like you were planning on a v4 anyway (which I guess you now have
to do, given that I just added the issue to RISC-V).
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
