lkml.org 
[lkml]   [2022]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFCv2 00/10] Linear Address Masking enabling
    On Thu, May 12, 2022 at 11:51 PM Dave Hansen <dave.hansen@intel.com> wrote:
    >
    > On 5/12/22 12:39, Thomas Gleixner wrote:
    > >> It's OK for a debugging build that runs on one kind of hardware. But,
    > >> if we want LAM-using binaries to be portable, we have to do something
    > >> different.
    > >>
    > >> One of the stated reasons for adding LAM hardware is that folks want to
    > >> use sanitizers outside of debugging environments. To me, that means
    > >> that LAM is something that the same binary might run with or without.
    > > On/off yes, but is there an actual use case where such a mechanism would
    > > at start time dynamically chose the number of bits?
    >
    > I'd love to hear from folks doing the userspace side of this. Will
    > userspace be saying: "Give me all the bits you can!". Or, will it
    > really just be looking for 6 bits only, and it doesn't care whether it
    > gets 6 or 15, it will use only 6?

    (speaking more or less on behalf of the userspace folks here)
    I think it is safe to assume that in the upcoming year or two HWASan
    will be fine having just 6 bits for the tags on x86 machines.
    We are interested in running it on kernels with and without
    CONFIG_X86_5LEVEL=y, so U48 is not an option in some cases anyway.

    > Do the sanitizers have more overhead with more bits? Or *less* overhead
    > because they can store more metadata in the pointers?
    Once we have the possibility to store tags in the pointers, we don't
    need redzones for heap/stack objects anymore, which saves quite a bit
    of memory.
    Also, HWASan doesn't use quarantine and has smaller shadow memory size
    (see https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
    for more details).
    Having more bits increases the probability to detect a UAF or buffer
    overflow and reduces the shadow memory size further, but that one is
    small enough already.

    > Will anyone care about the difference about potentially missing 1/64
    > issues with U57 versus 1/32768 with U48?
    I don't think anyone will.

    Having said that, I agree with Dave that it would be nice to have an
    interface that would just request the mask from the system.
    That way we could have support for U57 in the kernel now and keep the
    possibility to add U48 in the future without breaking existing users.

    I also may be missing something obvious, but I can't come up with a
    case where different apps in the system may request U48 and U57 at the
    same time.
    It seems natural to me to let the OS decide which of the modes is
    supported and give the app the freedom to use it or lose it.

    --
    Alexander Potapenko
    Software Engineer

    Google Germany GmbH
    Erika-Mann-Straße, 33
    80636 München

    Geschäftsführer: Paul Manicle, Liana Sebastian
    Registergericht und -nummer: Hamburg, HRB 86891
    Sitz der Gesellschaft: Hamburg

    Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise
    erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes
    weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich
    bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.


    This e-mail is confidential. If you received this communication by
    mistake, please don't forward it to anyone else, please erase all
    copies and attachments, and please let me know that it has gone to the
    wrong person.

    \
     
     \ /
      Last update: 2022-05-13 13:09    [W:4.255 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site