Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lkl: lkl_add_arp_entry #166

Merged
merged 1 commit into from
Jun 18, 2016
Merged

lkl: lkl_add_arp_entry #166

merged 1 commit into from
Jun 18, 2016

Conversation

liuyuan10
Copy link
Member

@liuyuan10 liuyuan10 commented Jun 9, 2016

Provides API support to add permanent arp entries to lkl so outsiders
don't need to reply arp request.

Signed-off-by: Yuan Liu liuyuan@google.com


This change is Reviewable

@ghost
Copy link

ghost commented Jun 10, 2016

LGTM, I'll wait for Hajime to take a look as well before merging.

@thehajime
Copy link
Member

Reviewed 5 of 5 files at r1.
Review status: all files reviewed at latest revision, 4 unresolved discussions.


Documentation/lkl.txt, line 196 [r1] (raw file):

  Add a list of arp permanent entries in the form of "ip|mac;ip|mac;..."
 $ LKL_HIJACK_NET_ARP="192.168.13.100|12:34:56:78:9a:bc;192.168.13.101|12:34:56:78:9a:be" lkl-hijack.sh ip address show

I think ip neighbor show command would be better in this case, no ?


tools/lkl/include/lkl.h, line 305 [r1] (raw file):

/**
 * lkl_add_arp_entry - add an permanent arp entry

an => a


tools/lkl/lib/net.c, line 164 [r1] (raw file):

struct lkl_arpreq {
  struct lkl_sockaddr_in arp_pa;      /* protocol address */
  struct lkl_sockaddr_in arp_ha;      /* hardware address */

arp_ha should be struct sockaddr, not with struct sockaddr_in ?

http://lxr.free-electrons.com/source/include/uapi/linux/if_arp.h#L113


tools/lkl/lib/net.c, line 167 [r1] (raw file):

  int             arp_flags;   /* flags */
  struct lkl_sockaddr_in arp_netmask; /* netmask of protocol address */
  char            arp_dev[16];

IFNAMSIZ instead of 16 ?


Comments from Reviewable

@thehajime
Copy link
Member

@liuyuan10 thanks for the patch. overall the patch is good and useful and I agree with this if my minor comments are addressed.

@liuyuan10
Copy link
Member Author

Review status: all files reviewed at latest revision, 4 unresolved discussions.


Documentation/lkl.txt, line 196 [r1] (raw file):

Previously, thehajime (Hajime Tazaki) wrote…

I think ip neighbor show command would be better in this case, no ?

Done.

tools/lkl/include/lkl.h, line 305 [r1] (raw file):

Previously, thehajime (Hajime Tazaki) wrote…

an => a

Done.

tools/lkl/lib/net.c, line 164 [r1] (raw file):

Previously, thehajime (Hajime Tazaki) wrote…

arp_ha should be struct sockaddr, not with struct sockaddr_in ?

http://lxr.free-electrons.com/source/include/uapi/linux/if_arp.h#L113

The lkl_sockaddr has size of 128 which is different sockaddr.

asm/syscall.h:
#define lkl_sockaddr __lkl__kernel_sockaddr_storage


tools/lkl/lib/net.c, line 167 [r1] (raw file):

Previously, thehajime (Hajime Tazaki) wrote…

IFNAMSIZ instead of 16 ?

Done.

Comments from Reviewable

@thehajime
Copy link
Member

Reviewed 4 of 4 files at r2.
Review status: all files reviewed at latest revision, 1 unresolved discussion.


tools/lkl/lib/net.c, line 164 [r1] (raw file):

Previously, liuyuan10 (Yuan Liu) wrote…

The lkl_sockaddr has size of 128 which is different sockaddr.

asm/syscall.h:
#define lkl_sockaddr __lkl__kernel_sockaddr_storage

hmm, okay if @opurdila is fine.

Comments from Reviewable

@liuyuan10
Copy link
Member Author

Review status: all files reviewed at latest revision, 1 unresolved discussion.


tools/lkl/lib/net.c, line 164 [r1] (raw file):

Previously, thehajime (Hajime Tazaki) wrote…

hmm, okay if @opurdila is fine.

@opurdila how do you think about it?

Comments from Reviewable

@ghost
Copy link

ghost commented Jun 16, 2016

tools/lkl/lib/net.c, line 164 [r1] (raw file):

Previously, liuyuan10 (Yuan Liu) wrote…

@opurdila how do you think about it?

I am not sure about it, I am trying to figure out why did I use __lkl_kernel_sockaddr_storage. I know I added it to fix a build error after I pulled in 4.6-rc6 but now it seems incompatible with the if_arp stuff.

I am going to need the week-end to figure it out, but if this is urgent I can merge it and log an issue to fix after. Please let me know how do you prefer to proceed.


Comments from Reviewable

@liuyuan10
Copy link
Member Author

Review status: all files reviewed at latest revision, 1 unresolved discussion.


tools/lkl/lib/net.c, line 164 [r1] (raw file):

Previously, opurdila (Octavian Purdila) wrote…

I am not sure about it, I am trying to figure out why did I use __lkl_kernel_sockaddr_storage. I know I added it to fix a build error after I pulled in 4.6-rc6 but now it seems incompatible with the if_arp stuff.

I am going to need the week-end to figure it out, but if this is urgent I can merge it and log an issue to fix after. Please let me know how do you prefer to proceed.

Didn't realize there might be problem behind. I can wait. thanks

Comments from Reviewable

Provides API support to add permanent arp entries to lkl so outsiders
don't need to reply arp request.

Signed-off-by: Yuan Liu <liuyuan@google.com>
@liuyuan10
Copy link
Member Author

Fixed after merging of #168

@tavip tavip merged commit e2a4010 into lkl:master Jun 18, 2016
tavip pushed a commit that referenced this pull request Jun 18, 2016
lkl: lkl_add_arp_entry
@ghost
Copy link

ghost commented Jun 18, 2016

Resolved conflict and merged. Thanks @liuyuan10 !

@liuyuan10 liuyuan10 deleted the arp branch July 9, 2016 21:58
phhusson pushed a commit to phhusson/linux that referenced this pull request Feb 14, 2023
If a relocatable kernel is loaded at an address that is not 2MB aligned
and told not to relocate to zero, the kernel can crash due to
mark_rodata_ro() incorrectly changing some read-write data to read-only.

Scenarios where the misalignment can occur are when the kernel is
loaded by kdump or using the RELOCATABLE_TEST config option.

Example crash with the kernel loaded at 5MB:

  Run /sbin/init as init process
  BUG: Unable to handle kernel data access on write at 0xc000000000452000
  Faulting instruction address: 0xc0000000005b6730
  Oops: Kernel access of bad area, sig: 11 [#1]
  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
  CPU: 1 PID: 1 Comm: init Not tainted 6.2.0-rc1-00011-g349188be4841 lkl#166
  Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,git-5b4c5a hv:linux,kvm pSeries
  NIP:  c0000000005b6730 LR: c000000000ae9ab8 CTR: 0000000000000380
  REGS: c000000004503250 TRAP: 0300   Not tainted  (6.2.0-rc1-00011-g349188be4841)
  MSR:  8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 44288480  XER: 00000000
  CFAR: c0000000005b66ec DAR: c000000000452000 DSISR: 0a000000 IRQMASK: 0
  ...
  NIP memset+0x68/0x104
  LR  zero_user_segments.constprop.0+0xa8/0xf0
  Call Trace:
    ext4_mpage_readpages+0x7f8/0x830
    ext4_readahead+0x48/0x60
    read_pages+0xb8/0x380
    page_cache_ra_unbounded+0x19c/0x250
    filemap_fault+0x58c/0xae0
    __do_fault+0x60/0x100
    __handle_mm_fault+0x1230/0x1a40
    handle_mm_fault+0x120/0x300
    ___do_page_fault+0x20c/0xa80
    do_page_fault+0x30/0xc0
    data_access_common_virt+0x210/0x220

This happens because mark_rodata_ro() tries to change permissions on the
range _stext..__end_rodata, but _stext sits in the middle of the 2MB
page from 4MB to 6MB:

  radix-mmu: Mapped 0x0000000000000000-0x0000000000200000 with 2.00 MiB pages (exec)
  radix-mmu: Mapped 0x0000000000200000-0x0000000000400000 with 2.00 MiB pages
  radix-mmu: Mapped 0x0000000000400000-0x0000000002400000 with 2.00 MiB pages (exec)

The logic that changes the permissions assumes the linear mapping was
split correctly at boot, so it marks the entire 2MB page read-only. That
leads to the write fault above.

To fix it, the boot time mapping logic needs to consider that if the
kernel is running at a non-zero address then _stext is a boundary where
it must split the mapping.

That leads to the mapping being split correctly, allowing the rodata
permission change to take happen correctly, with no spillover:

  radix-mmu: Mapped 0x0000000000000000-0x0000000000200000 with 2.00 MiB pages (exec)
  radix-mmu: Mapped 0x0000000000200000-0x0000000000400000 with 2.00 MiB pages
  radix-mmu: Mapped 0x0000000000400000-0x0000000000500000 with 64.0 KiB pages
  radix-mmu: Mapped 0x0000000000500000-0x0000000000600000 with 64.0 KiB pages (exec)
  radix-mmu: Mapped 0x0000000000600000-0x0000000002400000 with 2.00 MiB pages (exec)

If the kernel is loaded at a 2MB aligned address, the mapping continues
to use 2MB pages as before:

  radix-mmu: Mapped 0x0000000000000000-0x0000000000200000 with 2.00 MiB pages (exec)
  radix-mmu: Mapped 0x0000000000200000-0x0000000000400000 with 2.00 MiB pages
  radix-mmu: Mapped 0x0000000000400000-0x0000000002c00000 with 2.00 MiB pages (exec)
  radix-mmu: Mapped 0x0000000002c00000-0x0000000100000000 with 2.00 MiB pages

Fixes: c55d7b5 ("powerpc: Remove STRICT_KERNEL_RWX incompatibility with RELOCATABLE")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230110124753.1325426-1-mpe@ellerman.id.au
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants