From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A8CFC04E53 for ; Wed, 15 May 2019 09:33:39 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 17BC62084F for ; Wed, 15 May 2019 09:33:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rmrbdnIx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 17BC62084F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.91) (envelope-from ) id 1hQqHk-0006pj-NV; Wed, 15 May 2019 05:33:16 -0400 Received: from mail-wm1-x342.google.com ([2a00:1450:4864:20::342]) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hQqHj-0006pd-4L for kernelnewbies@kernelnewbies.org; Wed, 15 May 2019 05:33:15 -0400 Received: by mail-wm1-x342.google.com with SMTP id f204so1906547wme.0 for ; Wed, 15 May 2019 02:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I/j++2aE1+Z/N8grhBrIo228Z23rlBsVFHY9s/rakNU=; b=rmrbdnIxZK9qNin3/pKJtIIYr+nmvbEdlhvEJVgAS5icX09QD7pnwBZnbMS7xNAEKg B/oxqY6NIO8J4zfS0L0lhsgCiinNpAlW6oWwbhzcC9KECZNxof8OlVzmoKWhPY2g16q2 3DmZn6XDFJ1Al39BKHUhapjdijkY+6YhoCeiPZYu2MzbjFWQN4EnHY39tC2n2hwm4TyW cEJ8RdAabwpK1/LWYwYUuNq3NgV75+8m9twJIOaDr4JAnicIGH0IGxpOYHcbHfwYrLjE m2yvX56695kycZ8HfitsaaI7s1Hda+ZcVU/a2BMVJGQoZWyDflj1Nilhf+bN0TSFloxt PDcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I/j++2aE1+Z/N8grhBrIo228Z23rlBsVFHY9s/rakNU=; b=HcjkYm+m1MlA1Ukbyhh3mpCsW3F+tr4pQD/qn/o9UVSgWClW+TCKn8q17Frwc6suTJ uv15sEiIgb7L29QrIyX3hd9X6irIyIVAkTTqmeG+UTOgGcD+TlGgV+3e+XxFRekBH0MJ vGrY70LIh1ErY2GaAV/zi8VbDp3r9yT1eqNcMLx2cYf7AcNgjZcFmjdjOcYQ1uT2F86M urfrraa13Q5WCjWFLjSxcbdzaXnJCeQOyn6XsKWsXhninGUF41+tCIPJCz03lPEFBoQ4 gbQsmr1Aw4Y5bYc+ELOIAc4ike/t0P2BkpTnnmTgD5k/SNPqugGpzMZoQqgwFRTS/2Q1 wYQg== X-Gm-Message-State: APjAAAVplv51UIqTCeCPaMjorTHypThwklZdgvXTuLQeK8GsjKlufs6Z nihlxYooLJIEvqm9csPkVWX09YZlo3YELfggACs= X-Google-Smtp-Source: APXvYqxneXO63K1lINJER6Yc/YYay97xdM3Iow/keN64s2V73RSAf05RarLXCBgU/5BVrxt65X2YEkd2jm8IPZMLt1o= X-Received: by 2002:a05:600c:217:: with SMTP id 23mr8462220wmi.115.1557912793489; Wed, 15 May 2019 02:33:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kumar Date: Wed, 15 May 2019 15:03:01 +0530 Message-ID: Subject: Re: Virtual To Physical Address Translation To: Aruna Hewapathirane Cc: kernelnewbies X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On Tue, May 14, 2019 at 5:52 PM Aruna Hewapathirane wrote: > > Hi, > > I am trying to wrap my head around the virtual to physical memory address translation. For example let's say I want to locate the sys_call_table. > > objdump and vmlinux shows me this: > aruna@debian:~/linux-5.1.1$ objdump -t vmlinux | grep -i sys_call_table > ffffffff81c001c0 g O .rodata 0000000000001120 sys_call_table > ffffffff81c01600 g O .rodata 0000000000000d60 ia32_sys_call_table > > and System.map shows me this: > aruna@debian:~/linux-5.1.1$ cat System.map | grep -i sys_call_table > ffffffff81c001c0 R sys_call_table > ffffffff81c01600 R ia32_sys_call_table > > So addresses match. > > And gdb shows me this: > aruna@debian:~/linux-5.1.1$ gdb vmlinux > GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 > Reading symbols from vmlinux...done. > > (gdb) p sys_call_table > $1 = {0xffffffff812317a0 <__x64_sys_read>, > 0xffffffff812318b0 <__x64_sys_write>, 0xffffffff8122d980 <__x64_sys_open>, > 0xffffffff8122bc40 <__x64_sys_close>, > 0xffffffff81236220 <__x64_sys_newstat>, > 0xffffffff812363e0 <__x64_sys_newfstat>, > > > Now if you take the address given by objdump and System.map which is 0xffffffff81c001c0 > and ask gdb to show you I get: > > (gdb) x 0xffffffff81c001c0 > 0xffffffff81c001c0 : 0x812317a0 > > My question is HOW is the address 0xffffffff81c001c0 translated to 0x812317a0 ? At the moment I am unable to provide you a pointer, but I have read somewhere that kernel uses random numbers to relocate addresses for the sake of cracking. I am reading up on page tables and page offsets just can't yet fully understand how it is done. A example that > breaks down the process step by step would really help. > > Thanks - Aruna > Regards, Amit Kumar > > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies